CVE-2026-118952 in Streams for Apache Kafka
Summary
by MITRE • 10/30/2026
A flaw was found in the Kroxylicious ACL authorizer. Its prefix-matching logic may apply a rule to a principal of a different type, or fail to check a broader matching rule when prefixes overlap. Depending on the ACL configuration, this may allow an authenticated Kafka client to access a resource (such as read a topic) that should be denied.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Kroxylicious represents a critical logic flaw within its Access Control List authorizer component, specifically affecting how prefix-based matching rules are evaluated against principal identities and resource paths. As an intermediary proxy for Apache Kafka, Kroxylicious relies on strict authorization policies to enforce security boundaries between clients and broker resources. The core technical deficiency lies in the implementation of the prefix-matching algorithm used by the ACL engine. This logic is designed to determine whether a specific rule applies to a given principal or resource based on string prefixes. However, the flaw introduces ambiguity when dealing with overlapping prefixes or mixed principal types. Specifically, the system may incorrectly apply an allow rule intended for one type of principal to another distinct type due to insufficient validation of identity attributes before applying prefix matches. Alternatively, in scenarios where multiple rules have overlapping prefix patterns, the authorizer fails to prioritize or correctly evaluate broader matching rules that should take precedence over more specific ones. This breakdown in logical evaluation means that the security decision is not derived from a comprehensive assessment of all applicable policies but rather from a flawed subset of them.
The operational impact of this vulnerability is significant for any organization relying on Kroxylicious to secure their Kafka infrastructure. An authenticated client, which might otherwise be restricted by broader deny rules or different allow rules based on its identity type, can exploit this logic error to bypass access controls. For instance, a user account configured with limited permissions could potentially gain read access to sensitive topics if the prefix matching incorrectly associates it with a rule granting such privileges to a different principal category. This effectively nullifies the intended security posture defined in the ACL configuration. The ability of an authenticated attacker to escalate their privileges or access unauthorized data constitutes a direct compromise of confidentiality and integrity within the messaging system. Since Kafka is often used for high-volume, critical business data flows, this vulnerability could lead to substantial data leakage or operational disruption depending on the sensitivity of the accessed topics.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation as it involves incorrect interpretation of input parameters (principal types and prefix strings) leading to an authorization bypass. It also maps closely to CWE-862 Missing Authorization, where the software does not perform the necessary checks before allowing access to restricted resources. In terms of offensive security frameworks, this vulnerability facilitates techniques associated with MITRE ATT&CK T1078 Valid Accounts, as it allows legitimate but improperly authorized accounts to gain unauthorized access. It also relates to privilege escalation vectors found in identity management systems where logical flaws allow users to assume roles or permissions they were not explicitly granted. The root cause is a design flaw in the rule evaluation engine rather than a simple buffer overflow or injection attack, highlighting the importance of rigorous logic testing in security-critical components like proxies and gateways.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary solution involves upgrading Kroxylicious to a version that includes patches for this specific ACL authorizer flaw, ensuring that the prefix-matching logic correctly validates principal types and handles overlapping rules according to established precedence policies. Administrators should review their current ACL configurations to identify any rules with overlapping prefixes or mixed principal type definitions that might be susceptible to exploitation under the old logic. In environments where upgrading is not immediately feasible, implementing additional network-level controls such as mutual TLS authentication combined with strict IP whitelisting can provide a compensating control layer. Furthermore, organizations should adopt a principle of least privilege by ensuring that ACL rules are as specific as possible and avoiding broad prefix matches whenever alternatives exist. Regular security audits of authorization policies and automated testing of rule precedence logic during the CI/CD pipeline can help detect similar logical flaws before they reach production environments.