CISA adds actively exploited WSO2 and Adobe Commerce flaws to its KEV catalog
On September 24, 2026, CISA added the path traversal flaw CVE-2026-5430 in WSO2 and the broken authorization flaw CVE-2026-71362 in Adobe Commerce and Magento to its Known Exploited Vulnerabilities catalog, both of them already exploited in the wild. U.S. federal agencies must patch by September 27, and any organization exposing these products should do the same without waiting.
September 24, 2026. CISA adds two critical flaws — CVE-2026-5430 in WSO2 and CVE-2026-71362 in Adobe Commerce/Magento — to the Known Exploited Vulnerabilities (KEV) catalog. September 13, 2026. watchTowr first sees real-world exploitation attempts against the WSO2 flaw on its honeypots. September 27, 2026. That is the deadline imposed on U.S. federal civilian agencies (FCEB) to apply the fixes. Why it matters: the KEV only lists vulnerabilities whose exploitation is proven — these two are not lab hypotheses, they are holes attackers are already walking through.
Two flaws, two different risk profiles
The two vulnerabilities have little in common, which is exactly what makes this batch worth reading closely.
CVE-2026-5430 is a path traversal rated CVSS 9.8 in the WSO2 platform. It affects four components — API Control Plane, API Manager, Traffic Manager and Universal Gateway — and enables unrestricted file upload leading to remote code execution. In practice, an attacker who reaches one of these interfaces can drop a file where it does not belong, then get it executed. On an API gateway or an IAM control plane, that is the worst category of flaw there is: the machine being compromised is the very one that arbitrates access to everything else.
CVE-2026-71362 is an incorrect authorization rated CVSS 9.1 in Adobe Commerce and Magento. It lets an attacker gain elevated access to sensitive resources without any user interaction. According to Sansec, the Dutch e-commerce security firm, the flaw “lets attackers switch a customer session to another customer account,” opening access to the victim’s account and private data.
Two vectors, one lesson: WSO2 is the front door of an infrastructure, Adobe Commerce is the cash register of a merchant. Both attract the same kind of actor — the one who wants access and data, not noise.
Exploitation documented since the summer
The KEV is not populated on a CVSS score but on evidence. Here, that evidence goes back several weeks.
watchTowr says it has observed in-the-wild exploitation attempts against CVE-2026-5430 since at least September 13, 2026, on its sensors. The KEV listing therefore comes barely more than a week after the first signals — a short window that reflects how confident CISA is in the reality of the threat.
For CVE-2026-71362, the timeline runs longer. Sansec says it detected and blocked exploitation attempts as early as August 2026. Telemetry from Previdian narrows it further: a single Australian IP address tried to exploit the flaw against its honeypots on September 10, 2026. Adobe has yet to update its advisory to confirm exploitation status — a common silence, but one that did not stop CISA from deciding.
That gap between the two flaws has a practical consequence. For WSO2, exploitation is recent and probably still targeted. For Adobe Commerce, it has been running for weeks: attackers have had time to industrialize their attempts, and every day of delay raises the odds that a customer account has already been switched.
Two attack chains, two different traces
To defend well, you have to understand how each flaw actually plays out, because the two leave different traces.
On the WSO2 side, the path traversal opens a simple door: the attacker manipulates a file path to escape the intended directory. On an API platform the sensitive point is upload — configuration files, policies, certificates. Once the malicious file lands in the right place, code execution turns the gateway into a foothold: the attacker watches API traffic pass through and can pivot to upstream services. The trace to hunt is twofold — recent files in upload directories, and unusual child processes spawned by the WSO2 service.
On the Adobe Commerce side, the chain is quieter. The incorrect authorization drops nothing; it switches identity: the attacker swaps their session for a legitimate customer’s. The victim sees nothing — their cart, history and data are simply read, or modified, by someone else. The trace lives in the access logs: logins to the same account from different addresses or browser fingerprints, or a shipping-address change right after an abnormal login.
What the KEV listing omits
An entry in the KEV is a decision, not a detection guide. It names the CVE, the product and the deadline; it does not publish indicators of compromise, exploitation signatures or the scale of the campaign. Operators of a WSO2 gateway or a Magento storefront still have to do that work themselves.
That is why the deadline is only the beginning. CISA gives agencies until September 27, 2026 to patch, but patching a machine that is already compromised leaves the attacker inside. The practical sequence is patch, then hunt, then confirm: apply the fix to stop new exploitation, sweep for the traces above, and only then declare the incident closed. For most teams, the patch is the easy hour; the hunt is the long week.
What to patch, and in what order
The first action is to locate the exposed instances. The WSO2 flaw touches four products that are not always inventoried: a forgotten API gateway behind a reverse proxy, or an API Manager control plane inherited from a dead project, is enough to reopen the hole.
Once the inventory is done, the priority order is simple:
- WSO2 first, because the flaw yields code execution. Apply the patch, but do not stop there: an exploited path traversal may have left webshells or uploaded files behind. Look for recent artifacts in upload directories and in the application logs.
- Adobe Commerce/Magento next. Apply the security patch, then audit administrative logins and abnormal account changes — a session switch does not always leave an obvious mark in application logs, but it does in access logs.
For FCEB agencies, the September 27, 2026 deadline is binding in the literal sense: it is written into BOD 22-01. For everyone else, it functions as a signal. When CISA hands out three days, it is because the threat is judged immediate.
Verdict
The batch is a reminder that “trusted” platforms — an API gateway, an online store — are first-choice targets, not blind spots. If you operate WSO2, patch today and treat any exposed instance as potentially compromised, because remote code execution does not grant the benefit of the doubt. If you run Adobe Commerce or Magento, apply the security patch and actively look for signs of session switching: weeks of documented exploitation is a window in which a customer account may already have been taken over. If you only track the KEV, note the pace — two confirmed flaws in one batch, with a three-day deadline, is the kind of signal that justifies re-prioritizing these fixes above your usual cycle. Together, the two flaws show that the KEV is not a severity ranking but a catch-up calendar: every entry is a race against attackers who are already moving. And the race starts with the inventory — for most teams, locating these products across estates is where the real time goes, because neither is tracked in a single asset register.