LiteLLM MCP Recon in 66 Seconds: A Scripted Client That Tests for Honeypots

TLP:CLEAR. Cleared for public release. Captured by the Kinryū Labs honeypot sensor network. Indicators below are defanged.

Executive summary

• 42shell commands pushed through MCP tools
• 66 sfrom first command to last
• 7honeypot checks in the final 20 seconds
• 1source of this activity, 5 to 12 September

CVE-2026-42271 is a command-injection flaw in LiteLLM’s MCP test endpoints (1.74.2 to 1.83.6, CVSS 8.7, on the CISA KEV list since 8 June 2026), and on 6 September one client abused LiteLLM’s MCP tool surface on a Kinryū Labs LiteLLM decoy. From a Hong Kong VPS address it listed the decoy’s MCP tools, then pushed 42 shell commands through them in 66 seconds: who am I, am I in a container, are root’s SSH keys readable, what network is this. It spent the last 20 seconds checking whether the host was real, with a marker file, a clock read, a pull from /dev/urandom and three timed sleeps, then stopped; nothing further came from it through 12 September. If you run LiteLLM below 1.83.7 with port 4000 reachable, upgrade; the Detection section has a rule for the request shape and one for the honeypot test.

The requests went to tools/call on /mcp. The advisory describes the flaw in the /mcp-rest/test/* endpoints, which this client did not touch, so we describe the activity as abuse of LiteLLM’s MCP tool surface rather than as that CVE.

Key judgments

Timeline

• 01:24:44 UTCFirst contact: HTTP POST to /mcp on TCP/4000, Mozilla/5.0, MCP tool-surface enumeration.
• 01:25:46 UTCSecond enumeration probe, same client profile.
• 01:27:30 UTCClient switches to curl/8.20.0 with a new HTTP client fingerprint and re-enumerates the tool surface.
• 01:27:35 UTCFirst command injection: bash tool with command 'id'; immediately followed by read_file of /etc/hostname.
• 01:27:44 UTCComposite recon one-liner: hostname; uname -a; listing of the root key directory; cat /proc/1/cgroup.
• 01:27:55 UTCSecond composite: pwd; whoami; /proc/1/cgroup; ip a | grep inet; ls /.
• 01:28:21 UTCPivot to decoy detection: stderr redirection, sh -c and bash -c wrapper handling, ls -la /etc/passwd.
• 01:28:31 UTCError-path and statefulness tests: non-existent path and file, touch then cat of /tmp/marker_uniq_93817.
• 01:28:32 UTCClock and entropy tests: date +%s, head -c 50 /dev/urandom | base64.
• 01:28:41 UTCTiming tests sleep 0 / 5 / 8, then session ends. No further activity from this address through 12 September.

The session, in order

01:27:35  id
01:27:44  hostname; uname -a | cut -c1-120; ls -la [root key directory] 2>&1 | head -5; cat /proc/1/cgroup 2>/dev/null | head -3
01:27:55  pwd; whoami; cat /proc/1/cgroup | head -2; ip a | grep inet | head -3; ls / | head -15
01:28:21  echo hi 1>&2
01:28:32  date +%s
01:28:32  head -c 50 /dev/urandom | base64
01:28:41  sleep 8

The recon goes straight for root’s keys and the container boundary

The client presented two different identities within the first three minutes. It sent two tool-surface enumeration probes from 01:24:44 under a Mozilla/5.0 user agent. Just under three minutes later it changed to curl/8.20.0, with a correspondingly different HTTP client fingerprint, and began invoking tools via tools/call.

It first ran identity checks, id, hostname, then read_file against /etc/hostname, then the two composite one-liners shown in the session above.

The script listed the root account’s private-key directory twice and ran ip a | grep inet. A proof-of-concept check does not need key-directory listings or network enumeration, so we read this recon as preparation for moving off the proxy host. The /proc/1/cgroup and /proc/1/cmdline reads establish whether the shell is inside a container.

At 01:28:21 the client stops asking about the host and starts testing it

For twenty seconds the client tested whether it was talking to a real host. It ran echo hi 1>&2 to see whether stderr came back on its own channel; sh -c and bash -c wrappers to check shell-invocation handling; ls and cat against deliberately non-existent paths for error-path fidelity; touch followed by a cat of the same marker file in /tmp, to see whether the filesystem held state between invocations; date +%s for clock advance; head -c 50 /dev/urandom | base64 for entropy; and sleep 0, sleep 5 and sleep 8 for timing fidelity.

The last command was sleep 8 at 01:28:41. Nothing further arrived from this address through 12 September. Why it stopped is not known. The order of events is what supports reading this as a honeypot test followed by a decision to stop, at moderate confidence.

An operator who tests LLM proxy endpoints for honeypots before trusting them is not new here: our keyHunter report describes one whose verifier was built to recognise them. We have no indicator linking the two.

Attribution

The timing settles one thing: this was a script. Forty-two invocations in 66 seconds, fired in bursts, with 130 to 250 ms between commands inside a burst and pauses of 9 to 26 seconds between bursts, is tooling that exploits, looks for keys and the container boundary, fingerprints the host and exits. That fits a targeted operator’s toolkit or a red-team framework with a burn-avoidance prefilter. It does not fit commodity mass exploitation, which replays one fixed payload and returns repeatedly; this client varied 37 command strings, visited once, and was the only source of this activity between 5 and 12 September. A security-research survey is not fully excluded, because fidelity batteries are also how honeypot-detection research works, but the source is a commercial Hong Kong VPS range, the client advertises no research identity, and the session listed root’s key directory and read /etc/passwd, which reputable surveys do not do.

We take attribution no further. The address sits in AS140227 (Hong Kong Communications International, 177.4.0[.]0/20), which is commercial hosting. VirusTotal shows two malicious and two suspicious engine verdicts with no vendor naming, and the flaw is KEV-listed with public proof-of-concept code, so capability says nothing about who.

Indicators of compromise

The one network indicator below is defanged; fingerprints and paths are given as observed.

Network

Indicator	Context
177.4.12[.]11	Only source of this activity between 5 and 12 September; every request went to /mcp on TCP/4000; AS140227, Hong Kong

Host artefacts

Indicator	Context
/tmp/marker_uniq_<digits>	Marker file written then read back by the honeypot test; the suffix was 93817 in this session, so hunt the pattern

Behavioural

Indicator	Context
po11nn050000_6e4c6fcb1a9b	JA4H-style HTTP client fingerprint of the curl/8.20.0 command phase
po11nn070000_39fa8e08ab4c	JA4H-style HTTP client fingerprint of the initial Mozilla/5.0 enumeration phase

Detection

Sigma

MCP tools/call carrying a shell command to a LiteLLM proxy (candidate).

title: MCP tools/call Carrying A Shell Command To A LiteLLM Proxy
id: 5b0f6c1e-2f0a-4d0e-9a53-6b1d0f7a42c1
status: experimental
description: POST to a LiteLLM MCP endpoint whose JSON body invokes a tool with a command argument. Needs request-body logging at the reverse proxy; the body field name is a placeholder for whatever your proxy calls it. Any hit on LiteLLM below 1.83.7 should be treated as exploitation.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-42271
logsource:
  category: webserver
detection:
  selection_request:
    cs-method: POST
    cs-uri-stem:
      - /mcp
      - /mcp-rest/test/connection
      - /mcp-rest/test/tools/list
  selection_call:
    request_body|contains: '"method": "tools/call"'
  selection_command:
    request_body|re: '"(command|args)"\s*:'
  condition: all of selection_*
falsepositives:
  - An MCP shell tool you expose on purpose to trusted clients
level: high

Honeypot fidelity checks spawned by an LLM proxy process (candidate).

title: Honeypot Fidelity Checks Spawned By An LLM Proxy Process
id: 0c9a7e52-8d1b-4a38-b0f4-3e5f2a9d7c10
status: experimental
description: A proxy process spawning the checks a client uses to decide whether the host is emulated. Seen immediately before the client abandoned the session. Works from ordinary process telemetry on the proxy host.
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - /python
      - /python3
      - /litellm
  selection_checks:
    CommandLine|contains:
      - /dev/urandom
      - date +%s
      - /proc/1/cgroup
      - marker_uniq_
  condition: selection_parent and selection_checks
falsepositives:
  - Container entrypoint or health-check scripts that read /proc/1/cgroup
level: high

Detection logic

• Fidelity battery from one source (behavioural, candidate). Within 120 seconds from a single source, count distinct commands matching /dev/urandom, ‘date +%s’, ‘^sleep [0-9]+$’, ‘echo .* 1>&2’, ’^(sh|bash) -c ’, and a touch then cat of the same /tmp path. Three or more categories means a client is deciding whether the target is real; keep the full session capture.
• Unauthenticated POST to /mcp on the LiteLLM default port (network, candidate). Destination port 4000, method POST, path /mcp, no authorisation header. Pair it with the curl phase fingerprint po11nn050000_6e4c6fcb1a9b.

Remediation

• Upgrade LiteLLM to 1.83.7 or later; the fix adds a command allowlist and a PROXY_ADMIN role check on the MCP test endpoints.
• If upgrade is not immediate, block POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at the reverse proxy, and do not expose TCP/4000 to the internet.
• Patch the Starlette Host-header bypass CVE-2026-48710 on the same stack. Chained, the two give unauthenticated remote code execution.
• Inventory every MCP server the proxy is configured to call and review its command and args for second-order injection.
• Rotate any provider API keys, LITELLM_MASTER_KEY values and virtual keys reachable from the proxy process environment or mounted credential files.
• Hunt hosts for /tmp/marker_uniq_ and for proxy-process children executing id, whoami, uname, getent or listings of the root account’s key directory.

MITRE ATT&CK mapping

Tactic	Technique	Observed
Initial access	T1190 Exploit Public-Facing Application	42 MCP tools/call invocations against an exposed LLM proxy on TCP/4000, abusing its MCP tool surface.
Execution	T1059.004 Command and Scripting Interpreter: Unix Shell	MCP bash tool driven with shell one-liners including sh -c and bash -c wrappers.
Discovery	T1082 System Information Discovery	uname -a, cat /etc/os-release, uname -r, hostname -f, ls -la /, cat /proc/1/cmdline.
Discovery	T1033 System Owner/User Discovery	id, id -u, whoami, getent passwd root, cat /etc/passwd | head -3.
Credential access	T1552.004 Unsecured Credentials: Private Keys	Two listings of the root account’s private-key directory in the first recon burst.
Defence evasion	T1497 Virtualization/Sandbox Evasion	The /proc/1/cgroup container check, then the seven-check battery in the final 20 seconds.
Collection	T1005 Data from Local System	MCP read_file tool invoked against /etc/hostname.

References

• NVD: CVE-2026-42271
• CISA Known Exploited Vulnerabilities catalogue
• Kinryū Labs: keyHunter, an LLM-proxy key operation that leaked its own toolkit

Methodology and analyst notes

This report rests on 1 source address and 10 timed observations, read from sensor telemetry, checked against public threat-intelligence feeds and enrichment lookups, covering activity on 6 September 2026 and pivots from 5 to 12 September. The activity stopped at discovery: no payload retrieval, persistence or outbound C2 was attempted before the session ended.

Still open:

• What 177.4.12[.]11 did before 6 September.
• Where the operator went after it stopped.
• Is the marker suffix 93817 fixed in the tool or generated per run?
• Does the battery match any published exploit or honeypot-detection tool?
• Was a proxy key needed, or did the request ride the Host-header bypass CVE-2026-48710?

Questions or corrections: [email protected].