Hunt the JWT that should have been rejected

An API manager sits between your clients and the backends that hold keys, secrets and internal services, which makes it one of the few systems whose whole job is deciding who to trust. When it accepts a token it should have rejected, the question is not only whether you are patched. It is whether someone already walked in with administrative authority, what they could reach, and what evidence you would need before trusting the gateway again.

CVE-2026-5430 is how that happens in WSO2. In API Manager, API Control Plane, Traffic Manager and Universal Gateway, a JWT signed with an unsupported algorithm gets accepted when it should be refused, so a forged token can become a trusted admin session. WSO2 rates it critical, 10.0 on multi-tenant deployments and 9.8 on single-tenant, and published the fix in advisory WSO2-2026-5328 on May 3, 2026. Four months later, on September 13, watchTowr told SecurityWeek and Cyber Daily that its honeypots were catching forged JWTs carrying administrator privileges, and that replaying the payload against the real product worked. That gap between the fix and the first attacks is the part worth sitting with.

One caution before the practical questions. Some coverage names companies that use WSO2, Telstra and Vodafone among them. That is a customer list, not a victim list. The evidence so far is honeypot attempts and successful replay research, not named production breaches. For a WSO2 estate, the questions that matter are these:

• Which internet- or partner-facing API Manager, Control Plane, Traffic Manager, and Universal Gateway nodes still run below the fixed update level?

• Do gateway, Carbon, WAF, or proxy auth logs show sudden admin-scoped sessions without a matching IdP login?

• Where JWT headers are logged, do alg values look rejected-worthy?

• Do consumer keys, secrets, or apps show reuse, mass export, or unexpected change after anomalous auth?

How the attack works

A JWT is only as good as the verifier that checks it, and a verifier has to refuse any token signed with an algorithm it does not support. CVE-2026-5430 skips that refusal, so a forged token is treated as a legitimate session. This post deliberately does not reconstruct token bodies or algorithm tricks. What matters for an investigation is simpler: authority that exists without any legitimate path that issued it.

The tokens watchTowr captured carried administrator privileges and were aimed at the things an API gateway guards: backend endpoints and credentials, consumer keys and secrets, and the API traffic flowing to internal systems. A successful replay proves the flaw is exploitable. It does not prove anyone in particular was compromised, which is exactly why the hunting below matters.

Risk: what a forged admin JWT means for the company

The risk is that an API gateway is effectively the brain of your integration layer. It holds keys, secrets, backend credentials and registered applications, and an attacker with admin on it also gets a route into your internal APIs. Multi-tenant deployments widen that blast radius, which is why WSO2 scores them higher. Start by inventorying every internet-facing or partner-facing WSO2 node, then work out who administers the estate, which apps and backends hang off it, which keys it stores, and whether your WAF or proxy logs kept any auth context from before you patched. If your auth logs are empty because nothing decodes the JWT, that is a gap in what you can see, not a clean bill of health.

Mitigate WSO2 JWT auth bypass risk

Remediation starts with an honest inventory, including older branches, OEM and partner builds, and any route through a proxy or load balancer. Record version, exposure, owner and update history for each. Support subscribers apply the fixed update levels through WSO2 Updates, and open-source installs should move to unaffected builds. These are the fixed levels from WSO2-2026-5328:

Product	Fixed update levels
API Manager	4.6.0.21 / 4.5.0.57 / 4.4.0.72 / 4.3.0.108 / 4.2.0.197 / 4.1.0.257
API Control Plane	4.6.0.22 / 4.5.0.58
Traffic Manager	4.6.0.21 / 4.5.0.56
Universal Gateway	4.6.0.21 / 4.5.0.57

If the supported path is blocked, community installs can use the public fixes linked from the advisory in the carbon-apimgt and product-apim repositories, though a supported unaffected version is the better answer where one exists. While you remediate, pull management and gateway interfaces off the public internet if they do not need to be there.

Before you change anything, preserve the evidence: gateway and Carbon HTTP access and auth logs, any WAF or reverse-proxy Custom Logs that carry JWT or auth-header fields, the audit history for applications and consumer keys, and host telemetry from the gateway nodes. Resist the urge to switch on full Authorization-header logging everywhere without a plan for handling what it captures, because those headers are credentials.

If you suspect compromise, rotate consumer keys, secrets and admin credentials, review every registered app and backend, and treat the gateway as untrusted until you rebuild it from a known-good baseline. Upgrading fixes the software. It says nothing about what happened between May and the day you patched, and that window is what the investigation has to cover. Write down the exposure window, the fixed level you applied, the identities and keys you reviewed, what you found, and where your logging fell short.

How to hunt the activity

The chain to reconstruct runs in order: the gateway accepts a forged or anomalous JWT, an admin-scoped session appears with no matching login at the identity provider, and then keys, apps or backends get used with that authority. Start at September 13, 2026, and only reach earlier if you can say why. Keep timestamps, host, client, method, path, status, actor claims where they are logged, and version inventory. If you need to find WSO2 nodes you have forgotten about, IONIX notes the Server: WSO2 Carbon Server header and API Manager body strings as discovery aids, and anything below the fixed levels above is in scope.

Hunt in KQL

The first query looks for anomalous auth and admin-scoped sessions in WSO2, Carbon and gateway logs. Swap in the table and field names your parsers actually use.

let StartTime = datetime(2026-09-13);
Syslog
| where TimeGenerated >= StartTime
| where ProcessName has_any ("wso2", "carbon", "api-manager", "gateway")
    or SyslogMessage has_any ("WSO2", "Carbon", "API Manager", "apimgt")
| where SyslogMessage has_any ("JWT", "Bearer", "admin", "authenticate", "oauth", "token")
| project TimeGenerated, Computer, HostName, ProcessName, SyslogMessage
| order by TimeGenerated asc

The second works against WAF or proxy Custom Logs that carry JWT or auth-header fields. Only hunt for unexpected alg values if your pipeline already decodes or logs JWT headers, and never paste a working forged token into a query to test it.

let StartTime = datetime(2026-09-13);
let Wso2Hosts = dynamic(["apim.example.com", "gateway.example.com"]); // replace
CommonSecurityLog
| where TimeGenerated >= StartTime
| where DestinationHostName in (Wso2Hosts)
    or RequestURL has_any ("/api/", "/oauth2/", "/token", "/carbon", "/services/")
| where RequestURL has_any ("Authorization", "Bearer")
    or AdditionalExtensions has_any ("alg", "JWT", "Bearer", "kid")
    or Message has_any ("alg", "JWT", "Bearer")
| project TimeGenerated, DestinationHostName, SourceIP, RequestMethod, RequestURL,
    DeviceAction, AdditionalExtensions, Message
| order by TimeGenerated asc

The third is the inventory question: list every API Manager, Control Plane, Traffic Manager and Universal Gateway node below the fixed level for its branch, whether that comes from the CMDB, banners, or an admin UI or CLI export. Include the partner-facing nodes and the lab box everyone forgot.

Hunt in Falcon CQL

Point the first query at the repo holding WSO2, Carbon or gateway syslog and HTTP forwards, and the second at the repo holding WAF or proxy events, over the same window. Endpoint telemetry on the gateway hosts is where you pivot after an HTTP auth anomaly turns up. It is not a substitute for the HTTP logs.

(#repo=YOUR_WSO2_SYSLOG_REPO)
| @rawstring=/(?i)(wso2|carbon|apimgt|api.?manager)/
| @rawstring=/(?i)(JWT|Bearer|admin|oauth|token|authenticate)/
| table([@timestamp, @rawstring], limit=1000)

(#repo=YOUR_WAF_OR_PROXY_REPO)
| (@rawstring=/(?i)(apim|gateway|wso2|carbon)/ AND @rawstring=/(?i)(Bearer|JWT|\balg\b)/)
| table([@timestamp, @rawstring], limit=1000)

Hunt in Splunk

Swap in your own indexes and hostnames, and set the time picker to September 13, 2026, reaching further back only if you have a reason.

index=YOUR_WSO2_ACCESS_INDEX earliest=09/13/2026:00:00:00
| eval raw=coalesce(_raw, message, syslog_message)
| eval host_dest=coalesce(dest, dest_host, hostname, host)
| where match(raw, "(?i)(wso2|carbon|apimgt|api.?manager|gateway)")
    AND match(raw, "(?i)(JWT|Bearer|admin|oauth|token|authenticate)")
| table _time host_dest sourcetype raw
| sort 0 _time

index=YOUR_WAF_OR_PROXY_INDEX earliest=09/13/2026:00:00:00
| eval path=coalesce(uri_path, uri, url, http_uri)
| eval client=coalesce(src_ip, src, clientip, client_ip)
| eval http_status=tonumber(coalesce(status, http_status, status_code))
| where match(path, "(?i)(oauth2|/token|/carbon|/services/|/api/)")
    OR match(_raw, "(?i)(Bearer|JWT|\\balg\\b)")
| table _time host client path http_status _raw
| sort 0 _time

Hunt in Kibana

Set the Discover time range to September 13, 2026, tightening or widening it only for a reason you can state:

(message: (*WSO2* OR *Carbon* OR *apimgt* OR "API Manager") OR host.name: (*wso2* OR *apim* OR *gateway*))
AND (message: (*JWT* OR *Bearer* OR *oauth* OR *admin* OR *token* OR *authenticate*) OR url.path: (*oauth2* OR *token* OR *carbon*))

(url.path: (*oauth2* OR /token* OR *carbon* OR *services*) OR http.request.headers.authorization: *Bearer*)
AND (server.domain: (*apim* OR *gateway* OR *wso2*) OR destination.domain: (*apim* OR *gateway* OR *wso2*))

Useful columns are @timestamp, host.name, source.ip, url.path, http.response.status_code, user.name and message. If your pipeline extracts JWT header fields such as the decoded alg, add that column and look for values that should never have been accepted.

Field mapping, false positives, and empty results

Field mapping: check your fields against a known-good gateway auth line before you trust a negative result, and make sure your coalesce and parser targets line up so an auth anomaly and the consumer-key activity that follows it land in the same view.

False positives: an admin session that follows a planned login at the identity provider, an algorithm change that traces back to a documented config update, and the steady scanner noise every /carbon and /oauth2 endpoint attracts.

Empty results: missing forwarders, short retention, no JWT field extraction and hosts that were never onboarded all look exactly like a clean result. If nothing logs the JWT, you have a visibility gap, not clearance, and Falcon endpoint sensors on their own will not give you JWT visibility.

Interpret the results before escalating

A matching auth string only tells you the gateway or proxy processed something. What it means depends on everything around it.

Finding	Next investigative step
Sudden admin-scoped session without matching IdP login	Identify subject, client, adjacent requests; preserve evidence; check key and app changes.
Unexpected JWT alg where headers are logged	Confirm against allowlist and config changes; require session or key follow-on.
Consumer-key / secret reuse or mass export after anomalous auth	Rotate with owners; review apps and backends.
WSO2 product below fixed update level for its branch	Patch or migrate per the advisory table; hunt the pre-upgrade window from 2026-09-13.
Server: WSO2 Carbon Server or API Manager banners on unexpected hosts	Add to inventory; determine exposure and version
Empty SIEM searches	Validate forwarding, JWT field extraction, retention, and node coverage.

Do not escalate on an old version number alone, a lone Bearer string, or ordinary OAuth activity after a planned change. Escalate when an admin session has no login behind it and something privileged happened next.

Sources

• WSO2 Security Advisory WSO2-2026-5328 / CVE-2026-5430 (advisory May 2026; fixed update levels as cited)

• SecurityWeek: Enterprises Warned of Attacks Exploiting WSO2 Vulnerability (2026-09-16)

• Cyber Daily: Vulnerability in open-source API manager under active exploitation (2026-09-16; amplify; honeypot attempts, not named production breaches)

• IONIX: CVE-2026-5430 build matrix / discovery signals (optional inventory aid)

• CVE Record: CVE-2026-5430

What This Means for Your Team

The lesson that outlives this CVE is simple to state. A gateway accepted a token it should have refused, an admin session appeared with no login behind it, and consumer keys, backends and internal API traffic started moving in ways an upgrade does not explain. That pattern is what to hunt, whatever the next flaw is called.

So work out what your API manager is allowed to mint and proxy, compare it with the auth and application actions it actually performed, and investigate wherever the two disagree. Then follow the consequences into credentials, registered applications, host activity and every system that trusted the gateway.

Most teams cannot answer those questions for the window between May and the day they patched, usually because the gateway logs were never forwarded, retention ran out, or nothing decodes the JWT. If you run Microsoft Sentinel and Defender, Inception Security can connect these questions to telemetry you already pay for, and an Inception Foresight M365 Assessment will show you which of those gaps you actually have.

Inception Protection

Inception Protection is Inception Security's MDR on the Defender and Sentinel stack you already pay for. For WSO2 cases we help connect gateway and WAF auth hunts to version inventory across every node, consumer-key and application review, and the containment steps that restore trust in the API plane.

Inception Foresight

Want a clearer view of visibility and detection gaps on the Microsoft stack that affect investigations like this? Grab our free Inception Foresight M365 Assessment. No strings. Follow Inception Security on LinkedIn and @inceptionsec on X.