>samit_hota
Back to security news

Security News · SN-2026-488

CRITICALCVE-2026-5430OPEN

Active Exploitation Targets WSO2 API Manager via Forged Admin JWT Tokens

Affected: WSO2 API Manager · WSO2 API Control Plane · WSO2 Traffic Manager · WSO2 Universal Gateway

Samit Hota·
#news#vulnerability-disclosure#wso2

A critical WSO2 API Manager vulnerability tracked as CVE-2026-5430 is under active exploitation in the wild, allowing unauthenticated remote attackers to forge administrative JSON Web Tokens (JWTs) and gain unrestricted access to enterprise control planes. Security researchers at watchTowr observed honeypot traffic on September 13, 2026, containing crafted authorization tokens carrying baked-in administrator privileges. The underlying flaw was originally discovered and reported by Hacktron Team, leading to an initial security advisory from WSO2 in May 2026 under reference WSO2-2026-5328.

Because API gateways sit at the perimeter of corporate infrastructure and handle authentication for critical internal microservices, exploitation of this bug poses a severe threat to organizations relying on WSO2 for API management and routing.

Technical Breakdown: The JWT Verification Bypass

The security vulnerability stems from an improper verification of cryptographic signatures (CWE-347) within WSO2’s JWT processing pipeline. Under standard operations, JSON Web Tokens consist of three distinct, Base64URL-encoded components: a header declaring the algorithm, a payload containing identity claims and roles, and a cryptographic signature verified against a trusted key or secret.

When WSO2 API Manager processes incoming requests authenticated via JWTs, its verification engine fails to enforce strict algorithm checks. If an attacker submits a JWT configured with an unsupported or unexpected signature algorithm, the service fails to fail closed. Instead of rejecting the unknown algorithm and dropping the request, the parser approves the token despite lacking valid signature verification.

This oversight allows attackers to construct arbitrary JWT payloads—including claims that assign full administrative rights—and sign them with unsupported algorithm declarations. Because the gateway accepts the token as valid without verifying the signature payload against a legitimate key, the request bypasses access controls completely.

In-The-Wild Exploitation and Threat Intelligence

Cybersecurity firm watchTowr confirmed that automated exploitation attempts are actively hitting public-facing deployments. Yordan Ganchev, principal threat intelligence specialist at watchTowr, noted that the observed exploitation attempts involve forged administrative JWTs intended to grant attackers full access to backend API configurations and control interface endpoints.

Prior to active exploitation, automated scoring models reflected a low likelihood of attack. The Exploit Prediction Scoring System (EPSS) assigned CVE-2026-5430 an EPSS probability of 0.22% (putting it in the 13th percentile of scored vulnerabilities). This discrepancy highlights a common operational trap for security operations teams: relying solely on predictive metrics like EPSS can obscure real-world threat realities. While EPSS evaluates statistical indicators across historical datasets, active honeypot captures confirm that weaponized probes are already live across the internet.

Blast Radius and Operational Impact

The official Common Vulnerability Scoring System assessment rates CVE-2026-5430 at CVSS 9.8 (with some analysts rating it at a maximum 10.0 severity). The corresponding CVSS v3.1 vector—CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H—underscores why this flaw carries such high operational impact:

  • Network Reachable (AV:N): Exploitation occurs over standard HTTP/HTTPS API management ports without local access.
  • Low Attack Complexity (AC:L): Crafting a forged token requires no specialized timing, conditions, or brute-force efforts.
  • No Privileges or User Interaction (PR:N/UI:N): Unauthenticated remote actors can trigger the flaw directly without social engineering or user intervention.
  • Scope Changed (S:C): Bypassing authentication on the API gateway directly compromises secondary systems relying on the gateway for security.

In a enterprise environment, an API gateway acts as a central conduit for data flow and authorization. Gaining administrative access to WSO2 API Manager allows an attacker to extract consumer keys, application secrets, and backend credentials for every registered system. Furthermore, because the gateway intercepts traffic destined for internal systems, an attacker holding administrative access can monitor sensitive data in transit, manipulate incoming API calls, or pivot into backend corporate networks—effectively turning the management layer into a “lateral movement-as-a-service” vector.

Scope of Impact and Patch Requirements

The vulnerability affects multiple products across the WSO2 ecosystem, specifically impacting WSO2 API Manager versions 4.1.0 through 4.6.0, as well as the WSO2 API Control Plane, Traffic Manager, and Universal Gateway.

To mitigate the vulnerability, organizations must update affected installations to the following specific patch levels or higher:

  • WSO2 API Manager 4.1.0: Update level 4.1.0.257 or higher
  • WSO2 API Manager 4.2.0: Update level 4.2.0.197 or higher
  • WSO2 API Manager 4.3.0: Update level 4.3.0.108 or higher
  • WSO2 API Manager 4.4.0: Update level 4.4.0.72 or higher
  • WSO2 API Control Plane 4.5.0: Update level 4.5.0.58 or higher
  • WSO2 API Control Plane 4.6.0: Update level 4.6.0.22 or higher

Community users using open-source builds must apply the corresponding fixes available in WSO2’s GitHub pull requests linked in security advisory WSO2-2026-5328.

Security teams operating WSO2 API Manager should immediately review gateway access logs for authorization headers bearing unusual JWT algorithms or administrative claims originated from untrusted source IPs. If compromise is suspected, administrators should revoke existing API application keys, reset management portal credentials, and re-issue signing keys across connected backends.

Found something similar in your stack?

Let's find out before it becomes an incident.

Book an advisory call