Most recent entries from all

fkie_cve-2026-55225

2026-09-30T12:15:28.995161+00:00

Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. In Strimzi 1.0.0 and earlier, an attacker who can create a Kafka custom resource can set Kafka.spec.entityOperator watchedNamespace to a target namespace, causing the Cluster Operator to create a Role with full Secret CRUD permissions there and bind it to the Entity Operator ServiceAccount in the attacker's namespace. The attacker can mint a token for that ServiceAccount and read or write Secrets in any target namespace where the Cluster Operator has been granted permissions, regardless of STRIMZI_NAMESPACE. This issue is fixed in versions 1.0.1 and 1.1.0.

GHSA-mw9r-p8xp-wx96 — Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator`

2026-09-30T12:15:28.995230+00:00

Affected: Maven: io.strimzi:strimzi

### Impact

Having the Topic and User operators to watch different namespaces than the one where the Kafka cluster is deployed, is a fully documented feature.

When the `watchedNamespace` field is used within the Topic or User operator (as part of the `Kafka.spec.entityOperator` field), the Cluster Operator creates a Role granting full CRUD on Secrets into the specified namespace. It also creates a RoleBinding to bind such Role to the entity operator ServiceAccount within the namespace where the Kafka cluster runs.

An attacker can craft a Kafka custom resource (in an attacker's namespace) with the `watchedNamespace` field set to a target namespace and then they can mint a token for the ServiceAccount (in the attacker's namespace) to read/write Secrets in that target. This is valid with any target namespace for which the Cluster Operator has the rights (regardless the value of the `STRIMZI_NAMESPACE` environment variable). The at-risk target namespaces are the namespaces which the user has given permissions to the Cluster Operator for, by creating related RoleBinding(s).

### Patches

The issue is fixed in Strimzi 1.0.1 and 1.1.0 by adding a control to enable the watched namespace feature through a dedicated environment variable within the Cluster Operator deployment. The watched namespaces feature is disabled by default.

### Workarounds

A possible workaround for this issue is about using a policy agent like Kyverno or OPA to prevent the usage of the `watchedNamespace` a…

RHSA-2026:54435 — Red Hat Security Advisory: Streams for Apache Kafka 3.2.1 release and security update

2026-09-30T12:15:28.995288+00:00

eclipse-vertx/vert.x: eclipse-vertx/vert.x: Denial of Service via TLS handshake with wildcard server name jetty: Eclipse Jetty: Information disclosure due to retained HTTP/1.1 trailers across connections vertx-core: Eclipse Vert.x: Information disclosure via improper handling of HTTP 30x redirects io.vertx/vertx-web: Eclipse Vert.x Web Client: Information disclosure via improper cookie domain validation io.quarkus/quarkus-rest: io.quarkus/quarkus-vertx-http: io.quarkus.resteasy.reactive/resteasy-reactive: Quarkus REST - Unbounded multipart MIME part-header accumulation allows remote OOM denial of service crypto/x509: golang: golang crypto/x509: Denial of Service via excessive processing of DNS SAN entries crypto/tls: golang: Go crypto/tls: Denial of Service via multiple TLS 1.3 key update messages net: golang: Go net package: Denial of Service via long CNAME response in LookupCNAME org.apache.logging.log4j/log4j-core: Apache Log4j Core: Log injection via CRLF sequences due to configuration attribute renames org.apache.logging.log4j/log4j-core: Apache Log4j Core: Invalid XML output causes denial of service in logging org.apache.logging.log4j: Apache Log4j JsonTemplateLayout: Denial of Service via invalid JSON output Apache Kafka Clients: Apache Kafka Clients: Information disclosure and data corruption due to race condition in producer buffer management golang.org/x/net/idna: golang: net/http: golang.org/x/net/idna: Privilege escalation via incorrect Punycode label processing…