CVE-2026-128424: Kroxylicious-authorizer-acl: kroxylicious: acl rule file regex escapes are stripped, broadening 'matching' authorization rules
A flaw was found in Kroxylicious. The ACL authorizer's rules-file parser unquotes matching /…/ regular-expression literals using the string unquoting rules, which strips every backslash escape. An allow rule such as matching /orders\.v1/ is compiled as the regex orders.v1, which also matches unintended names such as ordersXv1, and character classes such as \d and \w lose their special meaning. Depending on the ACL configuration, this may allow an authenticated Kafka client to access a resource that should have been denied.
Originally reported upstream in the open: https://github.com/kroxylicious/kroxylicious/issues/5236 (public since 2026-10-28). Draft advisory: GHSA-x5xx-3j9w-x63g. Formal CVE request: PSIRTSUPT-30443. Distinct from CVE-2026-118952 (ACL prefix-matching bypass in the same component).
Other sources
A flaw was found in Kroxylicious. The ACL authorizer's rules-file parser unquotes matching /…/ regular-expression literals using the string unquoting rules, which strips every backslash escape. As a result, an allow rule such as matching /orders\.v1/ is compiled as the regex orders.v1, which also matches unintended names such as ordersXv1, and character classes such as \d and \w lose their special meaning. Allow rules written with regex escapes can therefore apply to more resources than the author intended. Depending on the ACL configuration, this may allow an authenticated Kafka client to access a resource (such as read or write a topic) that should have been denied.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments using the Kroxylicious ACL authorizer with rules files containing matching /…/ regular-expression allow rules are exposed. The practical impact depends on whether stripped escapes broaden a rule so that unintended Kafka resource names match.
What does an attacker need to exploit it?
An attacker needs to be an authenticated Kafka client with the low-level privileges reflected in the CVSS vector. They must request access to a resource name that matches the broadened regular expression but should not match the administrator's intended escaped expression.
Are all ACL rules affected?
The issue affects regular-expression literals written as matching /…/ when they rely on backslash escapes. For example, an escaped dot in orders\.v1 is stripped and becomes a wildcard dot; escapes used for character classes, such as \d and \w, also lose their intended meaning.
How can administrators assess whether their rules are vulnerable?
Review ACL authorizer rule files for matching /…/ allow rules containing backslashes. Determine the regex after every backslash escape is removed, then check whether that resulting expression matches resource names that the original rule was intended to deny.