CVE-2026-5430 (WSO2 API Manager JWT Signature Verification Bypass) analysis

01개요

CVE-2026-5430 is a flaw in the JWT (JSON Web Token) authentication used by WSO2 API Manager's REST APIs (Admin/Publisher/DevPortal, etc.): when a token is signed with an unsupported algorithm, the resulting exception never gets turned into a rejected request — the authentication interceptor lets it through instead. WSO2's own advisory number for this issue is WSO2-2026-5328, a vendor-internal identifier distinct from the CVE number (CVE-2026-5430).

An attacker needs no account and no login. Using any algorithm other than RS256/RS384/RS512, they can self-sign a forged JWT carrying an admin claim. Once that token slides past authentication, the reachable surface — in watchTowr's words — includes "every API backend endpoint and its credentials, consumer keys, and secrets."

The flaw was found by Hacktron Team; WSO2 published its advisory on 2026-05-03. On 2026-09-13, threat-intel firm watchTowr's honeypot network captured forged JWTs carrying admin privileges arriving in the wild, confirming active in-the-wild exploitation.

CVSS: 9.8 (single-tenant, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) / 10.0 (multi-tenant, Scope Changed — S:C)

WSO2's own advisory does not list a CWE. Most press coverage classifies it as CWE-347 (Improper Verification of Cryptographic Signature). The more precise root cause this piece derives directly from the source — CWE-703, improper handling of an exceptional condition — is covered in §04 below.

02영향받는 버전

03Background — the CXF interceptor chain, and a default of "unless told to block, let it through"

WSO2 API Manager's administrative REST APIs (Admin, Publisher, DevPortal, etc.) run on Apache CXF's JAX-RS implementation. Before invoking the actual resource method (e.g. the implementation behind a "create user" endpoint), CXF walks the request through a series of interceptors registered at different phases — authentication is handled by OAuthAuthenticationInterceptor, registered at the PRE_INVOKE phase.

This interceptor extends AbstractPhaseInterceptor, and how that base class behaves is the load-bearing assumption behind this vulnerability: unless handleMessage() explicitly throws or aborts the chain, CXF treats the interceptor as having passed and proceeds to the next stage — ultimately, the actual resource method call. In other words, this design is not "block when in doubt" (fail-closed); it is "let it through unless told to block" (fail-open).

Authentication itself works like this: OAuthJwtAuthenticatorImpl.authenticate() reads the request's Authorization: Bearer <JWT> header and delegates signature verification to JWTValidatorImpl.validateSignature(), which calls JWTUtil.verifyTokenSignature(). A JWT's header self-declares the signing algorithm (alg); WSO2 only trusts RSA-family signatures (RS256/RS384/RS512) — anything else (symmetric HS256, unsigned none, etc.) is supposed to be rejected.

Put together, this API's safety hinges on exactly one thing: when the algorithm check fails, does that failure actually stop the CXF chain? The next section shows where that link breaks.

04취약점 발생 원인

This vulnerability isn't caused by a sloppy signature check — it's caused by mishandling what happens when that check fails. Three weaknesses interlock in sequence: the verification logic (W1) genuinely rejects a bad algorithm, but the interceptor receiving that rejection (W2) erases the signal, and that erasure turns into a full bypass only because of how the CXF interceptor chain is designed by default (W3).

1"Reject anything that isn't RSA" — the signature check itself genuinely rejects a bad algorithm

Before it ever checks a cryptographic signature, this method looks up a certificate from the truststore and inspects the JWT header's algorithm. If it isn't RSA-family, it never even reaches verifyTokenSignature(jwt, publicKey) (the actual cryptographic check) — it throws an APIManagementException right there. On its own, this is correct defensive behavior.

Actual wso2/carbon-apimgt source (pre-patch) — JWTUtil.java:107-131 · verifyTokenSignature(SignedJWT, String) (parent commit 52ae133).

왜 이렇게 됐나Taken in isolation, this method is fine — anything outside RSA-family algorithms is rejected before real cryptographic verification even starts. The highlighted lines (122-125) are exactly that rejection point. The next section's question is: does whoever catches this exception actually stop the request?

2"An exception was thrown, so it must have been rejected" — the interceptor catches it and moves on

W1's exception doesn't reach this interceptor directly — OAuthJwtAuthenticatorImpl.authenticate() calls JWTValidatorImpl.validateSignature(), which calls JWTUtil.verifyTokenSignature(), and none of the methods along that call path absorb the APIManagementException; it propagates upward untouched. The first place that actually catches it is this interceptor's handleMessage().

Actual wso2/carbon-apimgt source (pre-patch) — OAuthAuthenticationInterceptor.java:98-111 · handleMessage() (parent commit 52ae133).

왜 이렇게 됐나The branch right above (line 106), throw new AuthenticationException(...), is correctly mapped to HTTP 401 by GlobalThrowableMapper (next section). But the catch block right below it (lines 108-110) — handling the exact same underlying situation, "authentication failed" — only logs and swallows it. When handleMessage() returns normally without throwing anything, CXF's PRE_INVOKE interceptor chain treats this interceptor as having passed and proceeds. Worth noting: the same file has a second authentication path used when authenticator == null (around lines 147-149, the default JWT/opaque path through authenticatorMap — the actual vulnerable path for this CVE), and it carried the identical pattern (log only, never re-throw). The patch fixes both catch blocks.

3"Unless blocked, let it through" — the safety net existed, but the signal never reached it

In CXF's JAX-RS layer, when an exception is actually thrown — whether during resource method invocation or, as here, during interceptor processing — the ExceptionMapper GlobalThrowableMapper.toResponse() catches it and converts it into the right HTTP status. Below is the branch that maps authentication failure to 401 — this code was not touched by the patch (it already worked correctly).

Actual wso2/carbon-apimgt source (identical pre- and post-patch — this branch was not changed in this commit) — GlobalThrowableMapper.java:128-139.

왜 이렇게 됐나This mapping logic was correct from the start — anything that reached this code as an AuthenticationException or APIManagementException would have gotten a clean 401. But because the PRE_INVOKE interceptor chain defaults to fail-open ("let it through unless explicitly told to block"), the moment W2 fails to re-throw anything, this safety net never gets a chance to fire. The net wasn't missing — the switch that turns it on was never flipped.

05공격 과정

5.1 공격 과정 요약

공격 흐름도 (직접 작성)

• Without registering or logging in, the attacker offline-signs a forged JWT carrying an admin claim, using any algorithm other than RS256/RS384/RS512.
• The forged token is sent in the Authorization: Bearer header to a WSO2 REST API endpoint (Admin/Publisher/DevPortal, etc.).
• OAuthJwtAuthenticatorImpl → JWTValidatorImpl.validateSignature() → JWTUtil.verifyTokenSignature() checks the algorithm and throws an APIManagementException because it isn't RSA-family.
• That exception propagates without being absorbed, all the way up to the catch(APIManagementException) block in OAuthAuthenticationInterceptor.handleMessage().
• That catch block logs and returns without re-throwing anything — CXF's PRE_INVOKE interceptor chain treats the request as having passed and proceeds to the next stage.
• The chain carries through to the actual REST resource method call, and the forged token's admin claim — never verified — reaches privileged operations (API backend access, consumer key/secret exposure, etc.).

5.2 상세 공격 과정

This differs from the usual "attacker forged a valid signature" story — the attacker never actually deceives the signature check. They don't need to produce a real RSA signature at all. Confirmed In the code path we directly diffed, the algorithm check (§04, W1) throws before the signature bytes are even inspected — all that's required is a syntactically valid three-segment token whose alg value isn't RS256/384/512.

Analysis From the call order we traced in OAuthJwtAuthenticatorImpl.authenticate(), signature verification (validateSignature) runs before handleScopeValidation(), which is what reads the scope claim. That means a request riding this bypass path may reach the resource method with scope validation never having executed at all — the "forged token with an admin claim" that WSO2 and watchTowr describe is the concrete method actually used in the observed attacks, but the code we diffed suggests an even looser condition (the complete absence of scope checking) may theoretically have been sufficient. This last sentence is our own inference, not traced all the way through the resource implementation in this session, and not something WSO2 separately confirmed.

The exact header/payload bytes of a working forged token are not published here (harm-reduction policy) — this piece stays at the conceptual level of "what condition triggers this path."

5.3 미흡점 ↔ 공격 흐름 매핑

06취약점 패치

07대응방안

Updating to the update level listed per product in the table above is the only real fix. Community users can apply the fixes in GitHub PR #13752/#14167 directly or upgrade to a later release; WSO2 support subscribers should update to the listed update level or higher via WSO2 Update Manager.

• If an immediate update isn't possible, add a temporary rule in front of the Admin/Publisher/DevPortal REST APIs (reverse proxy or API gateway) that pre-parses the JWT in the Authorization header and blocks any request whose alg value isn't RS256/RS384/RS512 — enforcing, one hop earlier, the same condition the server ultimately checks.
• Don't expose the administrative REST APIs (especially /api/am/admin, /api/am/publisher, etc.) directly to the public internet — restrict access via VPN or IP allowlisting.
• 탐지 관점. Watch WAF/API gateway logs for JWTs reaching the administrative REST API with an alg header other than RS256/RS384/RS512, and for tokens carrying admin scopes/claims that appear without having gone through a normal login flow. During incident review, also keep in mind that on pre-patch versions, an "Authentication Failure"/"Error while authenticating" line in the server log may actually be evidence of a request that was logged but never blocked.

08왜 이게 반복되는가

This case and the Issabel Framework hard-coded JWT key CVE we covered alongside it (CVE-2026-89026) both end at the same outcome — a forged JWT stealing administrative access — but for opposite root causes. Issabel's problem was that the key itself was public, making signature verification meaningless from the start (CWE-321); WSO2's verification logic and its error-mapping infrastructure were each individually correct, but a single piece of exception handling in between cut the signal (CWE-703). "We verify the signature" is not, by itself, a safety guarantee — what you do when that verification fails is part of the same sentence, and these two cases show that from opposite directions.

Catching a checked exception, logging it, and moving on is common in Java codebases — usually harmless. It stops being harmless the moment that exception is the vehicle for a security decision ("this request must be rejected"). When the surrounding authentication framework defaults to fail-open — "let it through unless explicitly blocked" — one missing re-throw in one catch block is enough to erase the whole authentication step.

Patch-completeness assessment. ① Did it remove the root cause? Confirmed — both catch blocks in the same file were fixed identically, and no point remains where the signal is silently erased. ② Variant surface? Analysis — searching the repository for other callers of JWTUtil.verifyTokenSignature-style methods turns up the API gateway (data-plane) side too, in GatewayUtils.java and InternalAPIKeyAuthenticator.java (the Internal Key/MCP authentication path). We did not trace all the way through in this session whether that path shares the same "caught but never explicitly rejected" pattern. This is a static signal only, logged as a separate patch-gap candidate rather than a confirmed finding. ③ Silent or incomplete re-patch? Analysis — product-apim's PR #14167 is only an integration-test update, not evidence that a re-patch was needed, and no follow-up commit revisiting this fix was found. Taken together, this patch is judged to remove the root cause for the REST API interceptor path; the gateway-side Internal Key path remains an open hypothesis that needs separate verification.

The signature-verification logic was fine. The infrastructure that turns errors into HTTP codes was fine. The problem sat between the two — the single channel that's supposed to carry a failure forward as a failure. So what we're leaving behind isn't a tool, it's this question: is this exception actually blocking the request?

09결론

CVE-2026-5430 is an authentication bypass in the REST API authentication of WSO2 API Manager and three sibling products: the exception raised by a JWT signed with an unsupported algorithm is logged and swallowed by the interceptor instead of rejecting the request (CVSS 3.1 = 9.8-10.0). Both the signature-verification logic and the HTTP error-mapping infrastructure were individually correct, but two catch blocks in between erased the rejection signal, letting the CXF interceptor chain's "unless blocked, let it through" default carry the request all the way to a privileged operation. The patch restores that signal by introducing a new exception type and widening the mapping condition. watchTowr observed active exploitation on 2026-09-13.