<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 22:24:56 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-55225</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-55225</link>
      <description>&lt;p&gt;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&amp;#39;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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&amp;#39;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-55225</guid>
    </item>
    <item>
      <title>GHSA-mw9r-p8xp-wx96 — Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator`</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-mw9r-p8xp-wx96</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: io.strimzi:strimzi&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Having the Topic and User operators to watch different namespaces than the one where the Kafka cluster is deployed, is a fully documented feature.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;An attacker can craft a Kafka custom resource (in an attacker&amp;#39;s namespace) with the `watchedNamespace` field set to a target namespace and then they can mint a token for the ServiceAccount (in the attacker&amp;#39;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).&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;A possible workaround for this issue is about using a policy agent like Kyverno or OPA to prevent the usage of the `watchedNamespace` a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: io.strimzi:strimzi&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Having the Topic and User operators to watch different namespaces than the one where the Kafka cluster is deployed, is a fully documented feature.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;An attacker can craft a Kafka custom resource (in an attacker&amp;#39;s namespace) with the `watchedNamespace` field set to a target namespace and then they can mint a token for the ServiceAccount (in the attacker&amp;#39;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).&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;A possible workaround for this issue is about using a policy agent like Kyverno or OPA to prevent the usage of the `watchedNamespace` a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-mw9r-p8xp-wx96</guid>
    </item>
    <item>
      <title>RHSA-2026:54435 — Red Hat Security Advisory: Streams for Apache Kafka 3.2.1 release and security update</title>
      <link>https://vulnerability.circl.lu/vuln/rhsa-2026:54435</link>
      <description>&lt;p&gt;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…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/rhsa-2026:54435</guid>
    </item>
  </channel>
</rss>
