UNC5174

CVE-2026-21962: an unauthenticated request bypasses access control in the Oracle WebLogic Server Proxy Plug-in, CISA KEV-listed on 24 August with exploitation running since January

CISA added CVE-2026-21962 to the Known Exploited Vulnerabilities catalog on 2026-08-24, with a CVSS 3.1 base score of 10.0. The flaw is in the request-handling logic of the Oracle WebLogic Server Proxy Plug-in for Apache HTTP Server and Microsoft IIS, and in Oracle HTTP Server, which bundles the same component. It is reachable over HTTP with no authentication, no privileges and no user interaction, and it yields unauthorized read and write access to the data the proxy handles plus a route into the backend WebLogic clusters the proxy fronts: "this vulnerability allows an unauthenticated remote attacker to bypass security controls and potentially gain unauthorized access to backend WebLogic systems. Because these proxy plugins often sit in DMZ environments, the exposure is significant" (NetSPI, 2026-01-22).

That last point is the whole finding. The proxy plug-in is not an application server; it is the component an estate deploys specifically to be the trusted boundary in front of one, which means the flaw does not sit behind the perimeter, it is the perimeter. Confirmed affected: Oracle HTTP Server and its proxy plug-in at 12.2.1.4.0, 14.1.1.0.0 and 14.1.2.0.0, and the WebLogic Server Proxy Plug-in for Microsoft IIS at 12.2.1.4.0 (same source). Oracle shipped the fix in its January 2026 Critical Patch Update.

Exploitation is not new, only the listing is. CloudSEK's honeypots recorded exploitation attempts from 22 January 2026, immediately after a public proof-of-concept appeared, and CISA has not said what prompted the August listing: "the vulnerability has been exploited since January", and "it’s unclear which attacks triggered CISA’s alert for CVE-2026-21962" (SecurityWeek, 2026-08-25). For a defender that inverts the usual reading of a KEV addition: this is not a newly weaponised flaw to get ahead of, it is confirmation that anything still unpatched has been reachable by a public exploit for seven months.

There is a targeting signal, and it is worth stating precisely, because it is one vendor's characterisation of a different dataset rather than an authority's account of this exploitation. SOCRadar's July analysis of an exposed staging server belonging to a China-nexus operator tracked as UNC5174 and UNC6586, associated with the SNOWLIGHT malware family, lists CVE-2026-21962 among the vulnerabilities weaponised in a campaign whose reconnaissance list SOCRadar says resolved overwhelmingly to government domains across more than a hundred countries (SOCRadar, 2026-07-31). SOCRadar's victimology table is more specific than that summary suggests, and it cuts both ways: against 119 raw list entries and 91 unique hosts for the WebLogic-class campaign, it records exactly one confirmed compromise, with the confirmation method given as "Blind RCE via DNS/HTTP out-of-band callback" (same report). So this operator did use the exploit and got in once that SOCRadar can prove, on a target list that is overwhelmingly governmental, but it converted only about one host in ninety, against 80 of 80 for the same operator's Confluence campaign in that table. The cPanel campaign sits at a comparable per-host rate (16 of 1,563) on a far larger footprint, so the honest reading is that WebLogic was a low-yield line of effort by confirmed-compromise count, not that the exploit failed. Its six-week staging-server window is also a different dataset from CloudSEK's seven months of honeypot telemetry, so the exploitation observed since January is not established to be this operator's.

Where the activity surfaces. Exploitation is HTTP traffic to a proxy tier, so the telemetry is the proxy's own request logs rather than anything on the WebLogic host. Look for malformed or structurally anomalous requests aimed at the plug-in's forwarding path, and for forwarded requests reaching backend WebLogic contexts that the proxy's own routing rules should never produce. Because the flaw grants unauthorized read and write access at the proxy rather than code execution on the origin, backend application logs may show requests that are individually well-formed and correctly authenticated from the backend's point of view: the discriminator is the mismatch between what the front-end received and what the back-end was asked to do, not a malformed request arriving at the application.

Triage: a benign lookalike is a misconfigured client or scanner producing malformed forwarding requests against the same path, which is common on an internet-facing proxy. What separates the two is what follows: a benign malformed request produces an error and stops, while exploitation is followed by backend access to data the requesting session was never entitled to. Correlate the proxy log with the backend access it produced rather than triaging the proxy log alone.

Builds on: 2026-08-05/cve-2026-34486-tomcat-encryptinterceptor-fail-open-kev

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: 2026-07-31/unit42-autonomous-deepseek-hermes-netscaler-cve-2026-3055