A new CISA KEV deadline puts two actively exploited enterprise-software flaws ahead of ordinary severity-based patch queues. On 24 September, the US Cybersecurity and Infrastructure Security Agency added CVE-2026-5430 in multiple WSO2 products and CVE-2026-71362 in Adobe Commerce and Magento to its Known Exploited Vulnerabilities catalog. Federal civilian agencies have until 27 September to remediate; other operators should treat the listing as confirmed exploitation, not proof that every exposed server is compromised.
Key takeaways
- CISA says both vulnerabilities have evidence of active exploitation.
- The two flaws affect different layers: WSO2 integration software and Adobe commerce platforms.
- Defenders need inventory, evidence preservation, vendor-supported remediation and post-fix compromise checks.
What the CISA KEV deadline changes
CISA’s 24 September alert identifies CVE-2026-5430 as a path-traversal flaw across multiple WSO2 products and CVE-2026-71362 as an incorrect-authorisation flaw in Adobe Commerce and Magento. A KEV entry means the agency has sufficient evidence of exploitation in the wild. It does not, by itself, identify threat actors, count victims or prove exploitation on a particular organisation’s system.
BleepingComputer and The Hacker News independently reported the additions and the short federal deadline. Security Arsenal separately analysed the remediation sequence. These reports are not counted as separate proof of each victim claim; their value is independent confirmation of the catalog event and defensible operational context.
The two vulnerabilities create different investigations
WSO2 products often sit in identity, API-management and integration paths. A path-traversal weakness can affect files outside the location an application intends to expose, but defenders should use the vendor advisory for precise affected products, versions and fixes. They should not assume that every WSO2 deployment has identical exposure or that a generic web scan proves successful exploitation.
Adobe Commerce and Magento sit closer to customer accounts, orders and storefront administration. Incorrect authorisation can let a request cross a boundary it should not cross. The investigation should therefore include application logs, account activity, administrative changes and any security telemetry named in Adobe’s advisory. Operators must avoid turning a general vulnerability description into an unsupported claim that customer data was taken.
Why exploitation status outranks a score
Traditional patch queues often sort by a severity score, asset importance and maintenance convenience. A KEV listing adds another factor: attackers are already using the flaw. That changes the expected value of delay. A slightly lower-scored flaw with verified exploitation and an internet-facing path may deserve action before a theoretical critical issue buried behind several controls.
The directive formally binds federal civilian executive branch agencies, but the prioritisation logic applies more broadly. Enterprises can map KEV entries to software inventories and exposure-management data, then combine that with business criticality. Our CISA CVE quality framework coverage explains the agency’s push toward better vulnerability data, while Google PageBreak shows why reproducible evidence is more useful than a raw finding count.
Patch without destroying the evidence
Fast remediation should not erase the clues needed to determine whether an attacker arrived first. Before disruptive changes, teams should preserve relevant logs, system time, configuration and volatile evidence when their incident-response process supports it. They should document exposed interfaces and affected versions, then apply vendor-supported updates or mitigations. If the product cannot be fixed in time, isolation or retirement may be safer than leaving a known-exploited service reachable.
After remediation, teams should repeat exposure tests and search for persistence, changed accounts, unexpected files and anomalous application behaviour. A clean vulnerability scan only proves the scanner no longer detects the condition it tested. It does not prove the system was never exploited. Credentials and tokens reachable through the affected service may need rotation based on evidence and vendor guidance.
Claims that should remain narrow
CISA confirms active exploitation of the vulnerabilities as classes. Public sources do not establish that every organisation running WSO2, Adobe Commerce or Magento was targeted, nor that any named customer’s data was accessed. Attribution, campaign scale and impact should stay tied to evidence from vendors, incident responders or affected organisations.
Inventory quality is the first practical bottleneck
A security team cannot remediate software it cannot locate. WSO2 components may be owned by integration teams, embedded in a larger platform or exposed through a gateway whose public name does not reveal the product behind it. Adobe Commerce can be run internally, by an agency or through a managed hosting provider. Asset owners should reconcile configuration-management records with network discovery, cloud inventories and vendor support data before declaring the environment clear.
Version detection also needs care. A banner may be hidden, changed or supplied by an intermediary, while a package inventory can miss a container or appliance. The safest method combines several signals and assigns an owner to resolve discrepancies. If a managed service is involved, the customer should request written confirmation of affected versions, remediation time and evidence checks rather than assuming the provider patched automatically.
A short deadline changes change-management choices
Federal agencies face a 27 September deadline, leaving little room for a conventional maintenance cycle. That does not justify an untested change on a critical service. It does justify an accelerated path with a documented owner, tested backup, rollback criteria and temporary compensating controls. Internet exposure can sometimes be reduced while an update is validated, but a workaround should come from the vendor or a trusted authority.
For non-federal organisations, the date is not a legal deadline under the directive, yet confirmed exploitation makes indefinite delay difficult to defend. Leaders should explicitly accept any residual risk, record why a system cannot be fixed and set a near-term alternative such as isolation, service replacement or monitored containment. A ticket with no owner is not a mitigation.
Post-remediation review should improve the next response
Once systems are fixed and investigated, teams should capture how quickly they mapped the KEV entries to assets, which telemetry was missing and how many exceptions needed executive approval. Those measures reveal whether vulnerability operations are built around evidence or around periodic scans. They also help procurement teams write logging, inventory and emergency-patch requirements into future software contracts.
Organisations should separately record verified incidents and precautionary remediation. Mixing the two inflates breach counts and makes future risk analysis less reliable. A host can be vulnerable without being compromised; it can also be patched after compromise. Clear status labels keep the response urgent without converting uncertainty into fact.
The CISA KEV deadline is an ordering signal: defenders should find affected WSO2 and Adobe Commerce systems, preserve evidence, apply supported fixes and investigate for compromise before lower-confidence vulnerabilities consume the same response capacity.
Facts at a glance
| Fact | Detail |
|---|---|
| CISA addition | 24 September 2026 |
| WSO2 issue | CVE-2026-5430 path traversal |
| Adobe issue | CVE-2026-71362 incorrect authorization |
| Federal deadline | 27 September 2026 |
| Evidence level | CISA says active exploitation is established |
Frequently asked questions
What did CISA add to the KEV catalog?
CISA added CVE-2026-5430 affecting multiple WSO2 products and CVE-2026-71362 affecting Adobe Commerce and Magento.
What does a CISA KEV listing mean?
It means CISA has evidence that attackers are exploiting the vulnerability in the wild; it does not reveal every victim or attack method.
Who must meet the CISA KEV deadline?
The directive applies to US federal civilian executive branch agencies, while CISA urges other organisations to prioritise the same fixes.
What should defenders do before patching?
Confirm affected versions and exposure, preserve useful logs, apply vendor-supported fixes or mitigations, and check for compromise after remediation.
Get the day’s top stories in your inbox
One concise email. No spam, unsubscribe anytime.
