Apache Tomcat

ReliaQuest: LLM-driven agents run most of an intrusion through one unauthenticated Spring Batch job-submission feature on Apache Tomcat, from in-process JavaScript to SYSTEM in under 24 hours

ReliaQuest says the attacker needed no zero-day and no new malware: an internet-facing Apache Tomcat application used Spring Batch, in which a task definition names the code to run, and accepted and ran task descriptions without a login (ReliaQuest, 2026-10-07). The decisive step was submitting tasks that invoked Nashorn, the JavaScript engine in the application's Java environment, so the code ran inside the application with its account privileges and created no child process until a shell was spawned later; results came back through deliberately triggered error messages, in fixed 1,800-byte chunks reassembled over hundreds of requests (ReliaQuest, 2026-10-07). The application's configuration files held plaintext credentials with SQL Server sysadmin rights; the attacker enabled xp_cmdshell, found SeImpersonatePrivilege, uploaded PrintSpoofer and GodPotato in base64 fragments through the same channel and reached SYSTEM when the first tool failed on file permissions and the second worked (ReliaQuest, 2026-10-07). With SYSTEM it saved the SAM, SYSTEM and SECURITY registry hives for offline extraction, created two local administrator accounts and deleted only one, and removed artifacts after the actions that produced them (ReliaQuest, 2026-10-07).

The agent-driven reading rests on a live, unauthenticated Cairn agent-orchestration dashboard (an open-source platform for coordinating AI agents; no source says whether it is the Cairn exploitation engine of Gambit Security's reporting, and it is not Talos' CAIRN toolkit) on the address that sent the opening requests, on command timing (roughly half the gaps five seconds or less), on job names that tracked read offsets and upload parts without a gap, on machine-readable pipe-delimited output, and on payloads whose next version repaired the fault the previous one returned; ReliaQuest says no single indicator establishes it and that it could not determine how many agents ran, which model drove them or how much a person approved (ReliaQuest, 2026-10-07). Submission and collection ran from different addresses, so blocking the submitting address alone would not have stopped retrieval, and the tool assembly is not a fingerprint for any group (ReliaQuest, 2026-10-07).

Builds on: Three off-the-shelf AI agents ran almost the entire card-theft campaign, from discovery to…

Unit 42 recovers a live autonomous-AI attack operation after it exposed its own home directory, the confirmed compromises came from manual exploitation of Citrix NetScaler (CVE-2026-3055) and Marimo notebooks, not the agent

Palo Alto Unit 42 published an unusually complete reconstruction of a live offensive operation on 2026-07-30, made possible by the operator's own mistake: its agent framework, acting on a command sent over Telegram, started an HTTP file server from the operator's home directory rather than an isolated staging path, exposing AI tool configurations, API keys, exploit scripts, target lists, shell history and the agent's own session logs (Unit 42, 2026-07-30). Unit 42 notes this was out of character; the same operator had emptied exploit directories after use and disabled conversation logging in one of its tools.

The operator, who uses the handles knaithe and KnYuan and describes themselves as a Zhuhai-based binary-security researcher, ran DeepSeek as the reasoning engine behind the open-source Hermes Agent, extended with three capabilities: a framework-bundled jailbreak skill, a custom module for attacking unauthenticated WebSocket endpoints, and a custom procedure that drives internet-wide asset enumeration through a scanning service, wired to a natural-language-to-search-query translator exposed to the agent as a tool.

The result is the part worth reading carefully. Every compromise Unit 42 confirms came from the operator's manual work: data exfiltration from three Citrix NetScaler targets and command execution on 11 Marimo notebook endpoints. Both fully autonomous exploitation attempts failed. Against Langflow, the agent needed either a login-bypass setting enabled or a public flow identifier and found neither; against n8n (which its scanning put at 647,017 instances globally and 25,209 in China) it worked the Chinese slice, sampled about a hundred, probed roughly forty, found three candidates, and was stopped because the unauthenticated form endpoint the exploit chain required was behind authentication on every one. Unit 42's own reading is that the failures were target-side configuration, not defensive detection, and that targets with weaker defaults would have been compromised, a hardening finding rather than a ceiling on the capability. The agent's decision-making is visible in the recovered logs: it abandoned the Langflow target set after assessing the deployment population as too small to be worth the effort and pivoted to a more widely deployed product on its own.

What actually worked was hand-driven. Using CVE-2026-3055, an out-of-bounds memory read in Citrix NetScaler ADC and Gateway, the operator exfiltrated appliance memory from three organisations and searched the recovered bytes for NetScaler authentication cookies, which Unit 42 reads as session-hijacking intent. It describes persistent multi-day targeting of a Malaysian government entity using memory-grooming parameters and maximum read attempts, with the operator returning behind proxy anonymisation on later attempts, behaviour it contrasts with the autonomous campaigns, which hit Chinese domestic infrastructure indiscriminately. Other manual activity included command execution against Marimo notebook instances, deserialization reverse-shell attempts against Tomcat servers and callbacks against Windows IKE VPN endpoints; a cloned PAN-OS exploit was non-functional, carrying placeholder values that cannot achieve code execution, with no evidence of modification or execution found.

The CVE itself deserves separate attention from the AI story, because it is the element with direct constituency exposure. It affects NetScaler ADC and Gateway only when the appliance is configured as a SAML Identity Provider; a precondition Unit 42 does not mention and which comes from the vulnerability record and the vendor's bulletin (Citrix, 2026-03-23). It is KEV-listed, and watchTowr's honeypot network observed exploitation from known threat-actor addresses as of 2026-03-27, months before and unrelated to this operator (watchTowr Labs, 2026-03-29). watchTowr also documents a second overread path under the same CVE reachable through a different endpoint, so an operator validating exposure should not assume a single request signature covers it.

Unit 42 also reports that the operator routed two Western tools, Claude Code and Codex, through a third-party proxy with attribution headers disabled and response storage turned off. It says Claude Code was used only for connectivity testing and proxy validation, its session history holding model checks, connectivity tests and one package-install request across three sessions, and that there were signs of Codex use in exploit-development directories though those chat logs were not preserved, and it relays OpenAI's confirmation that its provider-side safeguards refused the policy-violating requests and that its safety systems flagged and disabled the linked account before Unit 42 shared intelligence. Unit 42's inference is that the operator chose the model with the fewest controls for the autonomous engine precisely because provider-side controls limited the alternatives.

Detection. For the NetScaler exposure the observable is in the appliance's own web logs: repeated requests to the SAML identity-provider endpoints from a single source, returning responses whose length varies request to request, with no corresponding completed authentication; memory-overread harvesting looks like a failing login loop that never fails cleanly. Follow it with authentication telemetry: a session cookie presented from an address or client fingerprint that never performed the sign-in that minted it is the downstream consequence the operator was working toward. More broadly, the enumeration behaviour Unit 42 describes leaves an approach signature worth hunting on any exposed application, high-volume version-fingerprinting requests from a narrow address set, followed within a short window by a small number of precisely-targeted exploit attempts against just the instances whose version replied in scope.

Triage: scanning noise against edge appliances is constant, so volume alone discriminates nothing. Two things separate this from background scanning: the requests target the specific identity-provider paths rather than sweeping the whole surface, and successful reads produce responses that are neither errors nor valid authentication outcomes. On the enumeration side, ordinary vulnerability scanners announce themselves through breadth and user-agent consistency; what Unit 42 describes is narrow, sequenced and selective, a fingerprint pass followed by exploitation of only the matching subset.

CVE-2026-34486, Apache Tomcat: the fix for an earlier EncryptInterceptor flaw reintroduced a bypass, and CISA's KEV listing lands months after a China-nexus campaign was already exploiting it

CISA added CVE-2026-34486 to its Known Exploited Vulnerabilities catalog on 2026-08-04, listing it as an Apache Tomcat missing-encryption-of-sensitive-data vulnerability (CISA, 2026-08-04). The defect is a regression in a security fix: the Tomcat security team records that an error in the fix for CVE-2026-29146 allowed the EncryptInterceptor to be bypassed (Apache Software Foundation, 2026-04-09). That is the whole of the vendor's description, and it carries an important consequence for scoping; only the three releases that shipped the defective fix are affected: 9.0.116, 10.1.53 and 11.0.20. An estate on an older release never received the broken fix and is not exposed to this flaw. The corrected builds are 9.0.117, 10.1.54 and 11.0.21, released 2026-04-04 and public from 2026-04-09.

The exploitation is not new, and that is the finding. SOCRadar's analysis of an exposed adversary staging server places this CVE in an active China-nexus campaign months before the catalog entry, recording it as a Java deserialization path using a CommonsCollections6 gadget, Taiwan-focused, delivering the SNOWLIGHT loader (SOCRadar, 2026-07-31). SOCRadar's own timeline puts that exploitation in late April 2026 (within weeks of the 9 April public disclosure) and its per-CVE table records confirmed live command execution against targets. SOCRadar attributes the SNOWLIGHT family, tracked by Google's threat-intelligence group, to China-nexus access brokers UNC5174 and UNC6586, and describes a campaign whose targeting centres on government infrastructure.

So the honest reading of the KEV addition is not "attackers have started". It is that a defender relying on the catalog as their exploitation signal was, for this flaw, more than three months behind an actor already using it against government targets. That is worth internalising beyond this CVE: KEV records exploitation the catalog has confirmed, not exploitation that exists, and a KEV-driven patch queue inherits that lag.

Note also the scoring tension. Apache's own CNA entry rates the flaw only as 'important' in words; the numeric 7.5 and its confidentiality-only vector come from the CISA and Red Hat enrichment containers on the CVE record, and CISA's alert title frames the flaw as missing encryption of sensitive data; both consistent with "the encrypted cluster channel stopped being encrypted". SOCRadar reports command execution. A team triaging on the CVSS vector alone would have ranked this well below its demonstrated impact.

The exposure profile is narrow, and inverted from the usual instinct. Three conditions must hold: clustering enabled, EncryptInterceptor configured, and the Tribes receiver reachable. The middle one is the uncomfortable part; the exposed population is the operators who turned encryption on for session replication rather than leaving the channel in the clear.

Detection concepts, telemetry class first. Network-flow and firewall telemetry is the cleanest surface, because Tribes membership is normally a fixed, small mesh of known peers: a session to the configured receiver port from any source outside the declared membership has no legitimate explanation. On the host, process-creation telemetry with parent lineage showing a Tomcat or Catalina JVM spawning a shell or a command interpreter is the deserialization payoff, and SOCRadar's recorded operator behaviour (command-execution oracles such as id and whoami run per host) is what the reconnaissance stage looks like. In application logs, an EncryptInterceptor decryption-failure entry followed by successful message processing rather than a discard is the mechanism itself firing.

Triage: a decryption-failure log line alone is not the signal, clock skew, a rolling upgrade with mismatched keys, or a misconfigured new node all produce them, and in those cases the message is dropped and the peer is a known member. The discriminators are whether processing continued after the failure, and whether the source address belongs to the declared membership list.

Builds on: The autonomous agent landed nothing; the operator's hand-driven work took data from three…