CISA Lists WSO2 and Adobe Commerce Vulnerabilities Exploited

The U.S. cybersecurity agency CISA included two critical vulnerabilities in its actively exploited vulnerabilities catalog, KEV, on Thursday (24): CVE-2026-5430, which affects WSO2 API management products, and CVE-2026-71362, in Adobe Commerce and Magento Open Source. The inclusion is based on evidence of exploitation in real attacks, according to the agency's notice, and gives federal civilian agencies until September 27 to apply the patches.

No organization has been publicly identified as a victim of attacks as of the publication of this article.

WSO2: The API Gateway

CVE-2026-5430 affects WSO2 API Manager versions 4.1.0 to 4.6.0, API Control Plane and Traffic Manager in versions 4.5.0 and 4.6.0, and Universal Gateway in those same versions. The CISA catalog records the flaw as a path traversal. Technical analyses by researchers describe a different mechanism: an authentication bypass where the system, upon receiving a JWT token signed with an unsupported algorithm, stops verifying the signature and accepts the credentials as legitimate. In both interpretations, the result is the same, allowing for administrative account takeovers.

The security company watchTowr reported attempts to exploit its honeypots since at least September 13, according to The Hacker News. This means the window between the first observed attack and the catalog inclusion was 11 days.

The severity of the vulnerability stems from the product's function. An API gateway sits on the edge of the architecture, authenticating calls between internal systems, partners, and applications. WSO2, a Sri Lankan company with operations in the U.S. and Europe, sells this layer to banks, carriers, and governments, which use it to expose services to third parties. A forged administrative credential at this point gives access to the inventory of APIs and the policies that control who can call what.

Adobe Commerce: Session Hijacked, Account Taken

CVE-2026-71362 has a CVSS score of 9.1 and is classified as improper authorization. According to Sansec, a company specializing in e-commerce security, the problem lies in handling customer identity within an active session: an unauthenticated attacker can swap the session for that of another customer and take over the account, gaining access to personal data and order history.

Adobe published the patch in bulletin APSB26-92 on August 11, with patched versions for Adobe Commerce 2.4.4 to 2.4.9, Magento Open Source 2.4.6 to 2.4.9, and Commerce B2B 1.3.3 to 1.5.3. The bulletin fixed seven vulnerabilities, five of which were critical.

Sansec reported having detected and blocked the first exploitation attempts shortly after the bulletin was published, still in August. The inclusion in KEV, six weeks later, formalizes the interpretation: for CISA, real exploitation is occurring.

Six weeks is enough time for mature process retailers to have applied the patch, but insufficient for others. In environments with heavy customizations, common in retail, each patch undergoes regression testing before deployment, and the maintenance schedule rarely keeps pace with attackers' timelines, who began testing the vulnerability within days.

Where the Risk Spreads

The September 27 deadline applies only to the U.S. federal government, but the KEV catalog serves as a prioritization reference for private security teams in various countries. The WSO2 vulnerability has already received alerts in Australia's specialized press, and the Adobe Commerce issue has been addressed in warnings from universities and e-commerce consultancies in the U.S. and Europe.

In retail, Magento maintains a significant base of medium-sized stores in Europe and Latin America, including Brazil, many of which are operated by agencies and third-party integrators. In this model, the patch relies on a support contract that does not always provide emergency response. The question for the retail CISO is who in the supply chain applied APSB26-92, and when.

For banks and fintechs exposing APIs via WSO2, the check is more direct: the production version, the date of the last patch, and the authentication logs since September 13. A token accepted without a valid signature does not leave the same trace as a login with an incorrect password, and the audit needs to specifically look for this.