CISA added two vulnerabilities to the Known Exploited Vulnerabilities catalog on 24 September, both with a 27 September remediation deadline. That three-day window is not special urgency; it is the standard shape under BOD 26-04.

One of the two entries is wrong about what the vulnerability is.

The WSO2 entry describes the wrong bug

The KEV entry for CVE-2026-5430 is titled “WSO2 Multiple Products Path Traversal Vulnerability”, and its description says the flaw allows unrestricted file upload leading to remote code execution.

It is not a path traversal. There is no file upload.

WSO2’s own advisory says: “JWT authentication can be bypassed when a token is signed using an unsupported algorithm, allowing unauthorized access.” NVD says the mechanism accepts tokens signed with algorithms other than those configured or supported. The impact is authentication bypass producing forged admin tokens — not a web shell on disk.

The strangest part is that CISA is contradicting itself inside a single record. The same KEV entry carries CWE-347, Improper Verification of Cryptographic Signature — which is exactly right, assigned by WSO2 as CNA and carried through NVD. The CWE field and the prose field disagree.

A plausible explanation, offered as observation rather than fact: the wording closely tracks CISA’s 2022 entry for CVE-2022-29464, “WSO2 Multiple Products Unrestrictive Upload of File Vulnerability” — a genuine WSO2 path traversal and file upload, CWE-22, added in April 2022. The 2026 entry reads like the 2022 template with a new CVE number. I could not find a correction or erratum.

Why this matters operationally

Because a lot of triage starts and ends at the KEV description.

If you read “path traversal, unrestricted file upload, remote code execution”, you will go looking for new files in upload directories, unexpected .jsp artefacts, and a web server spawning shells. You will find nothing, and you may conclude you were not hit.

The actual artefact is a JWT with an unexpected alg value, and an administrator-scoped session with no corresponding authentication event behind it. A forged token produces authorisation without authentication, so the tell is a missing login record correlated with a privileged action — the exact opposite of a file that appeared.

The bad description is already propagating to aggregator sites. If your vulnerability management process ingests KEV text, this one needs a manual override.

What to actually do about the WSO2 flaw

WSO2 remediates by update level, not version number:

ProductVersionFixed at update level
WSO2 API Control Plane4.6.0 / 4.5.022 / 58
WSO2 API Manager4.6.0 / 4.5.0 / 4.4.021 / 57 / 72
WSO2 API Manager4.3.0 / 4.2.0 / 4.1.0108 / 197 / 257
WSO2 Traffic Manager4.6.0 / 4.5.021 / 56
WSO2 Universal Gateway4.6.0 / 4.5.021 / 57

Note that API Manager is affected across six release lines while the other three products are only affected at 4.5.0 and 4.6.0.

Two things the vendor advisory does not tell you.

First, updates ship through WSO2’s update mechanism to subscription holders. If you run a community build, you cannot pull the update level at all — the remediation is a migration, not a patch. For a lot of organisations that, not the patching itself, is the real blocker.

Second, and more important: patching does not evict an attacker who already used this. A forged admin token grants access to API backend endpoints and to the stored consumer keys and secrets for every registered application. Those credentials remain valid after you upgrade. Rotate API keys, consumer secrets, application credentials and service-account passwords, and revoke outstanding tokens. Preserve evidence before you patch — the upgrade will not reveal what happened beforehand.

Hunting for it

No IOCs have been published. None. Nobody has released IPs, user agents or hashes, so this has to be behavioural:

  • Unsupported or unexpected alg values in JWT headers, wherever you log them. This is the direct artefact of the flaw and the highest-value signal you have.
  • Admin-scoped activity with no matching authentication event. The absent login is the detection.
  • Privilege claims in a token that do not match the asserted identity.
  • Mass export or reuse of consumer keys and secrets shortly after an anomalous authentication event.
  • Unexpected changes to registered applications, routing policies or backend connections.
  • WSO2 Carbon Server or API Manager banners on hosts you did not know were running them — shadow inventory is how these stay unpatched for months.

Log sources worth pointing at this: WSO2 Gateway and Carbon access logs, Carbon authentication logs, API Manager audit history, and any WAF or reverse proxy that captures authorisation headers.

The timeline is the uncomfortable part

  • 3 May 2026 — WSO2 publishes the advisory and the fix
  • 6 August — NVD publishes the record
  • 13 September — watchTowr observes the first exploitation attempt against its honeypots, using a forged JWT
  • 16 September — public reporting
  • 24 September — KEV listing, three-day deadline

Four and a half months of available patch before anyone started shooting. The window was not the problem; the patching was.

A sourcing note: watchTowr’s finding was published on X, not as a research writeup. There is no watchTowr Labs blog post on this to link to, which is why the references below point at the reporting rather than the source.

The other one: Adobe Commerce session switching

CVE-2026-71362 is unrelated to the WSO2 flaw and unrelated to the Magento zero-day we covered earlier this month.

CWE-863, incorrect authorization, CVSS 9.1, unauthenticated. It lets a customer session be switched to a different customer’s account, because the platform does not correctly bind a customer identity to a session. The result is customer account takeover — personal data, order history. It is not remote code execution, and availability is unaffected.

Patched in APSB26-92 on 11 August, Adobe priority 2. Affected: Adobe Commerce 2.4.4 through 2.4.9-2026-jul, B2B 1.3.3 through 1.5.3-2026-jul, Magento Open Source 2.4.6 through 2.4.9-2026-jul. The August releases fix it.

Unlike StyleSmuggler, this was not a zero-day. It was patched in August and attacked afterwards — Sansec reported blocking the first attempts within days of the bulletin.

Volume is low, and the post would be dishonest not to say so. Previdian’s public data shows three exploitation attempts from three IPs — Australia, Netherlands, Sweden — across 10 to 25 September, on a single sensor. This is opportunistic probing, not a mass campaign. It is in KEV because it is confirmed exploited, not because it is everywhere.

The remediation step people skip: invalidate every active customer session after patching. The fix stops new session switching; it does not terminate a session an attacker already pivoted into.

Detection is behavioural here too — session tokens moving between customer account contexts without re-authentication, or a session authenticated as one customer reaching another’s data. And inventory all your Magento hosts, including staging and campaign sites. Those are the ones that never get patched.

One caveat I could not resolve: several outlets report that Adobe’s patch ships as an isolated patch file requiring the store to already be on the latest point release — a two-step remediation. Adobe’s own knowledge base page for APSB26-92 returns 404, so I could not confirm that against a primary source. Budget for two steps and verify before you schedule the window.

EPSS moved, a lot, in one day

We keep coming back to this, and this week gives the sharpest example yet.

CVEEPSS 24 SepEPSS 25 Sep
CVE-2026-54300.00374 (28.6th pct)0.0058 (45.4th pct)
CVE-2026-713620.02335 (82.8th pct)0.89616 (99.78th pct)

The Adobe score moved by a factor of thirty-eight overnight, and it is not even monotonic — it sat around 0.25 through August and early September, dropped to 0.023 on the 24th, then jumped to 0.896 on the 25th.

If you had screenshotted EPSS on the day these hit KEV, you would have recorded both as unremarkable. Any EPSS figure you put in a ticket needs a date stamp next to it, and a single reading is not a risk assessment.

References