{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2026-27134 in the wild and no public exploit code.","fix":"No fix has been published for CVE-2026-27134 yet. Limit exposure of the affected software until one is available.","what":"CVE-2026-27134 is a high-severity authentication bypass vulnerability in strimzi-kafka-operator, published on 20 Feb 2026. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-27134 and fix it if it is affected.\n\nWhat it is: CVE-2026-27134 is a high-severity authentication bypass vulnerability in strimzi-kafka-operator, published on 20 Feb 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-27134 in the wild and no public exploit code.\n\nAffected product: strimzi-kafka-operator. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-27134/ (Markdown: https://insights.sbomify.com/CVE-2026-27134/index.md)","id":"CVE-2026-27134","markdown":"https://insights.sbomify.com/CVE-2026-27134/index.md","name":"CVE-2026-27134","record":{"aliases":["GHSA-2qwx-rq6j-8r6j"],"analysis":{"component_type":"container_or_infrastructure","fix_type":"upgrade","impacts":["security_bypass"],"network_reachable":"yes","non_default_config":true,"product_category":"Kafka operator","requires_auth":"none","summary":"Strimzi incorrectly trusts all CAs in a multi-stage custom CA chain, allowing unauthorized users with certificates from any chain CA to authenticate via mTLS.","user_interaction":"not_required","vuln_class":"auth_bypass"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"GitHub_M","cpe":[{"product":"strimzi_kafka_operator","vendor":"linuxfoundation"}],"cvss":{"score":8.1,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[{"id":"CWE-296","name":"Improper Following of a Certificate's Chain of Trust"},{"id":"CWE-295","name":"Improper Certificate Validation"},{"id":"CWE-287","name":"Improper Authentication"}],"description":"Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. In versions  0.49.0 through 0.50.0, when using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs, Strimzi incorrectly configures the trusted certificates for mTLS authentication on the internal as well as user-configured listeners. All CAs from the CA chain will be trusted. And users with certificates signed by any of the CAs in the chain will be able to authenticate. This issue affects only users using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs. It does not affect users using the Strimzi-managed Cluster and Clients CAs. It also does not affect users using custom Cluster or Clients CA with only a single CA (i.e., no CA chain with multiple CAs). This issue has been fixed in version 0.50.1. To workaround this issue, instead of providing the full CA chain as the custom CA, users can provide only the single CA that should be used.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":false,"headline":"Strimzi: All CAs from a custom CA chain consisting of multiple CAs are trusted for mTLS user autentication","id":"CVE-2026-27134","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"auth_bypass","year":"2026"},"n_packages":0,"n_references":2,"next":{"headline":"nghttp2 Denial of service: Assertion failure due to the missing state validation","id":"CVE-2026-27135"},"packages":[],"prev":{"headline":"Strimzi All CAs from CA chain will be trusted in Kafka Connect and Kafka MirrorMaker 2 target clusters","id":"CVE-2026-27133"},"products":["strimzi-kafka-operator"],"published":"2026-02-20","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"total"},"state":"PUBLISHED","updated":"2026-07-15","vendors":["strimzi"]},"summary":"Strimzi incorrectly trusts all CAs in a multi-stage custom CA chain, allowing unauthorized users with certificates from any chain CA to authenticate via mTLS.","url":"https://insights.sbomify.com/CVE-2026-27134/"}