{"id":2036,"date":"2026-09-28T13:15:49","date_gmt":"2026-09-28T07:45:49","guid":{"rendered":"https:\/\/www.hexnode.com\/threat-watch\/?p=2036"},"modified":"2026-09-30T09:25:47","modified_gmt":"2026-09-30T03:55:47","slug":"cisa-kev-wso2-adobe-commerce-exploitation","status":"publish","type":"post","link":"https:\/\/www.hexnode.com\/threat-watch\/cisa-kev-wso2-adobe-commerce-exploitation\/","title":{"rendered":"CISA KEV Alert: WSO2 CVE-2026-5430 and Adobe Commerce CVE-2026-71362"},"content":{"rendered":"

Most security teams keep a backlog of “patch when we get to it” vulnerabilities. This week, four of them jumped the queue. CISA confirmed active, real-world exploitation of flaws in WSO2’s API management suite and Adobe Commerce\/Magento, adding both to its Known Exploited Vulnerabilities (KEV) catalog within a day of each other in late September 2026. Around the same time, CISA also flagged ongoing attacks against Microsoft SharePoint and MikroTik RouterOS. The common thread isn’t a single attacker or campaign, it’s that all four sit in front of systems enterprises can’t easily take offline: API gateways, ecommerce backends, collaboration platforms, and network infrastructure.<\/p>\n \t\t

\r\n \t\t\tWho is affected?<\/span> \t\t\t \t\t\t\t

\r\n \t\t\t\t\tWho is affected by CISA KEV CVE-2026-5430 and CVE-2026-71362?<\/strong>
\nThese aren’t attacks tied to one named threat actor, they’re vulnerabilities CISA confirmed are being actively exploited, regardless of who’s behind each attempt. WSO2’s API management and gateway products are used by roughly a thousand organizations worldwide, concentrated in banking, government, telecommunications, and logistics, sectors where APIs sit at the center of daily operations. Adobe Commerce and Magento, meanwhile, power a large share of mid-size and enterprise online stores, handling customer accounts, sessions, and payment workflows. Both platforms are attractive not because they’re obscure, but because they’re widely deployed and often internet-facing. A confirmed KEV listing means CISA has evidence real attackers are already probing or exploiting these systems, not just a theoretical risk sitting in a scan report.
\n \t\t\t\t<\/p>\r\n \t\t\t \t\t\t\r\n \t\t<\/div>\r\n \t\t\n

What happened?<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n
Detail<\/th>\nWSO2 (CVE-2026-5430)<\/th>\nAdobe Commerce\/Magento (CVE-2026-71362)<\/th>\n<\/tr>\n<\/thead>\n
Added to KEV<\/strong><\/td>\nSeptember 24, 2026<\/td>\nSeptember 24, 2026<\/td>\n<\/tr>\n
Federal deadline<\/strong><\/td>\nSeptember 27, 2026<\/td>\nSeptember 27, 2026<\/td>\n<\/tr>\n
Affected products<\/strong><\/td>\nAPI Control Plane, API Manager, Traffic Manager, Universal Gateway (API Manager 4.1.0\u20134.6.0; other components 4.5.0\u20134.6.0)<\/td>\nAdobe Commerce and Magento Open Source<\/td>\n<\/tr>\n
CVSS severity<\/strong><\/td>\n9.8 (Critical)<\/td>\n9.1 (Critical)<\/td>\n<\/tr>\n
How it works<\/strong><\/td>\nSources disagree here. WSO2’s own advisory describes a JWT authentication weakness, the system accepts tokens signed with an unsupported algorithm, which can lead to unauthorized access and admin account takeover. CISA’s KEV entry instead labels it a path-traversal flaw enabling unrestricted file upload and remote code execution. Until vendor and CISA descriptions align, treat both risk paths as real. Administrators should apply the vendor-prescribed fixes without waiting for clarification, restrict administrative access, and review logs for suspicious authentication, file uploads, and signs of code execution.<\/td>\nAn incorrect-authorization flaw that lets an attacker switch a customer’s session to another account. Researchers at Sansec observed this being exploited without an existing account, admin privileges, or user interaction.<\/td>\n<\/tr>\n
Access needed<\/strong><\/td>\nUnauthenticated, per most reporting<\/td>\nNone \u2014 no account or interaction required<\/td>\n<\/tr>\n
What’s confirmed<\/strong><\/td>\nActive exploitation attempts observed since at least mid-September 2026; CISA has not confirmed ransomware use<\/td>\nActive exploitation observed and blocked by a third-party security vendor<\/td>\n<\/tr>\n
What’s uncertain<\/strong><\/td>\nThe exact technical mechanism (JWT bypass vs. path traversal), and how widespread exploitation is<\/td>\nFull scope of affected merchants<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Separately, CISA added two more actively exploited flaws a day later: CVE-2026-65660<\/strong>, a code-injection vulnerability in on-premises Microsoft SharePoint Server (2016, 2019, and Subscription Edition) that Microsoft initially labeled as lower-severity “spoofing” before revising it to reflect remote code execution risk, and CVE-2026-67279<\/strong>, an SSH-related flaw in MikroTik RouterOS that can let an unauthenticated client open a session and issue commands. Both carry their own federal remediation deadline of September 28, 2026.
\n

<\/div>

How Hexnode UEM MSP Simplifies Patch Management Across Client Environments<\/h4>

MSPs can standardize patch management across clients while keeping each client's controls & requirements separate.<\/p><\/div><\/div><\/div><\/a><\/div><\/div><\/div><\/p>\n

Why this matters<\/h2>\n

These four flaws sit in places most security stacks weren’t built to watch closely: API gateways, ecommerce checkout flows, document collaboration platforms, and network routers. A firewall or antivirus tool doesn’t tell you whether a WSO2 gateway just accepted a forged token, or whether a Magento session was silently swapped to a different customer. That visibility gap is exactly what attackers rely on \u2014 not sophistication, but the fact that exploitation of an internet-facing system rarely shows up on endpoint dashboards until something downstream breaks. For enterprises, this means the usual patch-later approach for “critical but not yet exploited” vulnerabilities no longer applies once CISA confirms real-world attacks. It also means identity, device, and endpoint signals need to talk to each other, because an attacker who gets past a public-facing app eventually has to touch a device, an account, or a session to do anything useful.<\/p>\n

How Hexnode can help<\/h2>\n

Hexnode UEM<\/a>: Keeping endpoint patch status and compliance visible<\/h3>\n

When a KEV entry drops with a two- or three-day remediation window, the first blocker is usually not knowing which devices or servers are exposed. Hexnode UEM gives IT teams a centralized view of device compliance and patch status across managed endpoints, so identifying unpatched or misconfigured endpoints doesn’t depend on manual inventory checks.<\/p>\n

It doesn’t patch WSO2 or Adobe Commerce itself; those require vendor updates. However, Hexnode can deploy underlying operating system updates and supported application patches to managed Windows and macOS devices, including the admin workstations used to access these systems. IT teams can schedule deployments and track patch status, helping keep those endpoints current and compliant.<\/p>\n

Hexnode XDR<\/a>: Watching for suspicious behavior after initial access<\/h3>\n

If an attacker does get through a public-facing flaw like the WSO2 or SharePoint issues described here, the next step usually involves reaching an endpoint or an identity. Hexnode XDR correlates endpoint and identity signals to help detect unusual behavior, such as an admin account suddenly active from an unexpected device, earlier in the chain. It’s a detection and response layer, not a guarantee against exploitation of the underlying vulnerability.<\/p>\n

Hexnode Access<\/a> and Hexnode IdP<\/a>: Strengthening workstation and application access<\/h3>\n

Hexnode Access lets users sign in to macOS and Windows workstations using cloud identity credentials. It connects local workstation login to the organization\u2019s identity provider and helps administrators control device access.<\/p>\n

Hexnode IdP manages access to integrated web and SaaS applications through SSO, MFA, and conditional access policies based on user identity, device compliance, and security context. For sensitive administrative consoles integrated with Hexnode IdP, these policies can restrict sign-ins from devices that fail compliance requirements. This adds protection where IdP policies govern access; it does not establish that those policies would block the specific WSO2 or SharePoint exploits.
\n

\n
\n
\n
\n \"Hexnode-IDP_Usecases\"\n <\/div>\n <\/div>\n
\n
\n Feature Resource \n <\/h5>\n

\n Hexnode IdP use cases\n <\/h4>\n

\n Check out this document for a quick glance into Hexnode IdP's capabilities.\n <\/p>\n \n Get the Infographic\n \n \n \n \n <\/g>\n <\/svg>\n\n <\/a>\n <\/div>\n <\/div>\n <\/section><\/p>\n

What security teams should do next<\/h2>\n

CISA’s confirmation that WSO2 and Adobe Commerce flaws are being actively exploited, alongside ongoing attacks on SharePoint and MikroTik RouterOS, is a reminder that KEV listings exist precisely because theoretical risk has become real activity. The practical response is the same regardless of platform: identify every exposed instance, apply vendor patches or mitigations, rotate any credentials or tokens that may have been exposed, and review logs for signs of prior compromise before assuming a patch alone closes the gap. Where identity and endpoint controls are already in place, through tools like Hexnode UEM, XDR, Access, and IdP, teams can add friction against attackers who make it past a patched-but-not-yet-verified system. Start with an accurate inventory of affected systems this week, not next quarter.
\n

<\/div><\/div>
Try\u202fHexnode\u202fFree for 14 Days\u202f\u202f\u202f<\/h5>

See which devices are exposed before attackers do. Try Hexnode free.<\/p>