What is the CVSS score of CVE-2026-27134?

CVE-2026-27134 has a CVSS 3.1 base score of 8.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Kubernetes are affected by CVE-2026-27134?

A high-severity vulnerability (CVE-2026-27134) affects Strimzi, the Kubernetes-based Apache Kafka deployment platform, with a CVSS score of 8.1.

How to fix or mitigate CVE-2026-27134?

Within 24 hours: Inventory all Strimzi deployments across Kubernetes and OpenShift clusters and assess which are internet-facing or contain sensitive data; establish incident response readiness. Within 7 days: Implement network segmentation to restrict Kafka cluster access and apply compensating controls; conduct threat modeling for affected systems. Within 30 days: Monitor for vendor patch release; evaluate alternative deployment architectures or temporary Kafka cluster isolation; document all mitigation steps and risk acceptance decisions.

Kubernetes CVE-2026-27134

HIGH

Improper Authentication (CWE-287)

2026-02-21 security-advisories@github.com

Authentication Bypass Apache Kubernetes Strimzi Kafka Operator Linuxfoundation

8.1

CVSS 3.1 · Vendor: github

Severity by source

Vendor (github) PRIMARY

8.1 HIGH

AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Red Hat

8.1 HIGH

qualitative

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Mar 12, 2026 - 22:04 vuln.today

CVE Published

Feb 21, 2026 - 00:16 nvd

HIGH 8.1

DescriptionCVE.org

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.

AnalysisAI

Strimzi Kafka Operator versions 0.49.0-0.50.0 incorrectly trusts all intermediate CAs in a multistage certificate chain for mTLS authentication, allowing any user with a certificate signed by any CA in the chain to authenticate to Kafka listeners. This authentication bypass affects only deployments using custom Cluster or Clients CA with multi-level CA chains. No patch is currently available.

Technical ContextAI

Classified as CWE-287 (Improper Authentication). Affects Strimzi Kafka Operator. 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