Cyberuptive
Contact Us

What Do CISA's WSO2 and Adobe Commerce KEV Additions Mean for Your Patch Priority?

By Chuck Lerch, Founder and CEO, Cyberuptive

On September 24, 2026, CISA added two vulnerabilities to its Known Exploited Vulnerabilities catalog that had nothing in common technically but shared an uncomfortable trait: both had patches available for weeks before attackers started exploiting them at scale. CVE-2026-5430, a JSON Web Token authentication bypass in WSO2 API Manager and related gateway products, had a vendor fix since May. CVE-2026-71362, a session-hijacking flaw in Adobe Commerce and Magento, had a fix since August. Both carry a federal remediation deadline of September 27, 2026. If your organization or your MSSP runs either product, the KEV listing is not the first warning — it is the second.

WSO2 API Manager and Adobe Commerce serve entirely different purposes — one brokers API traffic and identity tokens for backend services, the other runs e-commerce storefronts — but CISA added both to its Known Exploited Vulnerabilities (KEV) catalog on the same day, September 24, 2026, each with a September 27 remediation deadline for federal civilian executive branch agencies (The Hacker News). The pattern connecting them is not the vulnerability class. It is the gap between "patch available" and "patch applied." WSO2 shipped a fix in April 2026 and published a formal advisory in May. Adobe shipped its fix in August. Attackers did not start exploiting either flaw meaningfully until much closer to the KEV listing — which means a five-month and one-month patch window, respectively, still left enough unpatched instances standing to draw CISA's attention.

CVE-2026-5430: WSO2 JWT authentication bypass

CVSS 10.0 in multi-tenant deployments, 9.8 in single-tenant deployments (WSO2's own CNA scoring). The flaw sits in how WSO2 API Manager, API Control Plane, Traffic Manager, and Universal Gateway validate JSON Web Tokens: the authentication mechanism accepts tokens signed with algorithms other than the ones an administrator explicitly configured. An attacker who crafts a JWT using an unsupported signing algorithm gets that token incorrectly validated — no legitimate signing key required — which can lead to unauthorized access up to and including administrative account takeover (NVD, CVE-2026-5430).

Two details make this one worth reading past the CISA summary. First, the KEV catalog entry names the flaw a "Path Traversal Vulnerability" with file-upload-to-RCE language, but the vulnerability WSO2 and NVD actually describe is a JWT signature bypass, tracked under CWE-347 (Improper Verification of Cryptographic Signature) — the KEV title and the technical description in the same government record disagree with each other. Security researchers flagged the mismatch within a day of the listing. It does not change what to patch or when, but it is a reminder to read the vendor advisory rather than stopping at a KEV title, particularly when writing internal tickets or contractual patch-verification evidence. Second, WSO2's affected-version list is broader than API Manager alone: API Control Plane (4.5.0, 4.6.0), API Manager (4.1.0 through 4.6.0), Traffic Manager (4.5.0, 4.6.0), and Universal Gateway (4.5.0, 4.6.0) are all in scope under vendor advisory WSO2-2026-5328, published May 3, 2026.

Exploitation is confirmed, not theoretical. Security researcher watchTowr reported observing forged, admin-privileged JWTs against its honeypot infrastructure beginning around September 13, 2026 — attackers reproducing the flaw despite no public proof-of-concept, then using forged tokens to reach WSO2's admin, publisher, and developer-portal API endpoints.

CVE-2026-71362: Adobe Commerce and Magento session hijacking

CVSS 9.1 (Critical), tracked under CWE-863 (Incorrect Authorization). Adobe disclosed the flaw in security bulletin APSB26-92 on August 11, 2026, as one of seven vulnerabilities patched that release. It requires no authentication and no user interaction to exploit, which is what earns it the critical rating despite being an authorization bug rather than a memory-corruption one: an unauthenticated attacker can switch an active customer session to a different customer's account, gaining access to that victim's stored payment methods, order history, and personal data without ever presenting valid credentials. Adobe's advisory stated the company was "not aware of any exploits in the wild" at the time of the August patch.

That changed fast. E-commerce security firm Sansec reported it began detecting and blocking exploitation attempts within weeks of the public disclosure, and by the time CISA added the CVE to KEV on September 24, active exploitation was confirmed rather than suspected (Security Affairs). Affected products are Adobe Commerce, Adobe Commerce B2B, and Magento Open Source on builds through the July 2026 security update; fixes ship in each product's August 2026 build (for example, Commerce 2.4.9-2026-aug and equivalent point releases across the 2.4.4 through 2.4.9 lines).

The pattern worth taking to your own patch program

Neither of these vulnerabilities is a zero-day. Both had vendor fixes, advisories, and CVE identifiers in the public record for months before CISA's KEV addition forced the issue. That gap is exactly what CISA's Binding Operational Directive 26-04 and the broader KEV catalog exist to close: a CVE with a patch nobody applied is functionally indistinguishable from an unpatched zero-day to the organization that gets breached through it. For regulated enterprises, this is also where vulnerability-management obligations under frameworks like NIST SP 800-171/172 and CMMC intersect directly with patch cadence — "we have a patch management process" and "we applied this specific patch within our stated SLA" are different claims, and only the second one holds up under a KEV-driven incident review.

If your organization runs WSO2 API Manager or any Adobe Commerce/Magento storefront, verify patch status now rather than assuming a general update cycle already covered it — both of these fixes shipped outside any predictable monthly patch Tuesday and required tracking vendor-specific advisories.

Remediation, in priority order

  1. Confirm WSO2 update levels. Subscription customers should be on API Control Plane 4.6.0 update level 22 or 4.5.0 update level 58; API Manager 4.6.0 update level 21, 4.5.0 update level 57, 4.4.0 update level 72, 4.3.0 update level 108, 4.2.0 update level 197, or 4.1.0 update level 257; Traffic Manager 4.6.0 update level 21 or 4.5.0 update level 56; and Universal Gateway 4.6.0 update level 21 or 4.5.0 update level 57, per vendor advisory WSO2-2026-5328. Community/open-source deployments should apply the public fix in carbon-apimgt PR #13752 or migrate to a current release.
  2. Restrict WSO2 admin surfaces in the interim. Until patched, limit network access to the Admin, Publisher, and DevPortal API endpoints to trusted management networks rather than leaving them internet-reachable.
  3. Hunt for prior compromise on WSO2 before declaring the incident closed. Review repository/logs/http_access_*.log for HTTP 200 responses to /api/am/admin/, /api/am/publisher/, or /api/am/devportal/ from unexpected sources, check for JWTs accepted using unsupported algorithms, and audit for new or unexpectedly privileged administrator accounts. Patching closes the vulnerability; it does not undo an intrusion that happened before the patch went in.
  4. Update Adobe Commerce, Commerce B2B, and Magento Open Source to the August 2026 security build corresponding to your current version line, per APSB26-92. This single update also closes six other vulnerabilities Adobe shipped in the same release, including two stored cross-site scripting issues.
  5. Review customer-session logs for anomalous session-account mismatches on Adobe Commerce/Magento storefronts covering the period since the July 2026 disclosure window, since exploitation of CVE-2026-71362 leaves a session-switching pattern rather than a classic authentication failure.

Organizations that rely on an MSSP for patch validation should ask a direct question: was this specific CVE, by number, confirmed patched on every affected instance, and when? A general statement that "patching is current" is not the same commitment. That level of CVE-specific tracking is the operating model behind Cyberuptive's patch management and vulnerability scanning services, and detection engineering for exploitation attempts against exactly this class of authentication and session-handling flaw is core to what a 24/7 managed detection and response SOC watches for — catching an attacker who got in during the window before a patch shipped, which a patch cycle alone cannot do.

Timeline

  • April 9–12, 2026: WSO2 merges public fixes for the JWT validation flaw in carbon-apimgt and product-apim repositories.
  • May 3, 2026: WSO2 publishes Critical advisory WSO2-2026-5328 for CVE-2026-5430.
  • August 11, 2026: Adobe publishes security bulletin APSB26-92, patching CVE-2026-71362 and six other Commerce/Magento vulnerabilities; Adobe states it is not aware of active exploitation at this time.
  • Mid-to-late August 2026: Sansec begins detecting and blocking exploitation attempts against CVE-2026-71362 shortly after public disclosure.
  • September 13, 2026: watchTowr observes the first forged-JWT exploitation attempts against CVE-2026-5430 on honeypot infrastructure.
  • September 24, 2026: CISA adds both CVE-2026-5430 and CVE-2026-71362 to the KEV catalog with a September 27 remediation deadline for federal civilian executive branch agencies.

Frequently asked questions about the WSO2 and Adobe Commerce KEV additions

Do I need to patch these if I'm not a federal agency?

The September 27, 2026 deadline under Binding Operational Directive 26-04 is binding only for federal civilian executive branch agencies. Everyone else should still treat KEV listing as confirmation of real-world exploitation, not a compliance-only signal — both flaws are actively being used against internet-reachable instances right now.

Why does the CISA KEV entry for CVE-2026-5430 describe a different vulnerability than WSO2's own advisory?

The KEV catalog entry titles CVE-2026-5430 a “Path Traversal Vulnerability” with file-upload-to-RCE language, while WSO2's advisory and the NVD record both describe a JWT signature-verification bypass under CWE-347. The CVE number, affected products, and remediation deadline in the KEV entry are correct; the vulnerability-class description is not. Rely on the vendor advisory and NVD record for technical accuracy, not the KEV title alone.

Is CVE-2026-71362 exploitable without any account on the Adobe Commerce store?

Yes. Adobe's own bulletin rates it as requiring no authentication and no user interaction. An attacker can switch an active customer session to a different customer's account without presenting valid credentials, gaining access to that victim's stored data.

Which WSO2 products besides API Manager are affected by CVE-2026-5430?

API Control Plane, Traffic Manager, and Universal Gateway are all affected in addition to API Manager, across the 4.1.0 through 4.6.0 version lines depending on the product. Check vendor advisory WSO2-2026-5328 for the exact update level required for your deployed version.

How can I tell if my WSO2 or Adobe Commerce environment was already compromised before I patch?

For WSO2, review access logs for HTTP 200 responses to the admin, publisher, or devportal API paths from unexpected sources and check for JWTs accepted with unsupported signing algorithms. For Adobe Commerce, review customer session logs for a session that appears to switch between two different customer accounts without a corresponding logout and re-authentication. Neither vendor has published classic file-hash or IP-address indicators of compromise for these specific campaigns.

Does patching alone close out the risk from these two CVEs?

Patching closes the vulnerability going forward, but it does not retroactively undo an intrusion that occurred during the window before the patch was applied. Both vendors and CISA guidance recommend reviewing logs for exploitation activity covering the period since each flaw's public disclosure, not just confirming the patch installed cleanly.

References

Vulnerability & KEV response

Related insights

How Cyberuptive helps