On September 24, 2026, CISA added CVE-2026-5430 to the Known Exploited Vulnerabilities (KEV) catalog, confirming what many of us in incident response have suspected over the past several weeks: a path traversal vulnerability affecting multiple WSO2 products is being actively exploited in the wild. This is not a theoretical risk. The flaw allows unrestricted file upload and can be chained directly into unauthenticated remote code execution — the worst-case scenario for any internet-facing middleware.
If your organization runs WSO2 API Control Plane, API Manager, Traffic Manager, or Universal Gateway — and a significant portion of enterprises in finance, healthcare, and government do, often as the backbone of their API strategy — you are operating internet-facing attack surface that threat actors are actively probing and compromising today. CISA's Binding Operational Directive (BOD) 26-04 applies, which means federal civilian agencies have a mandated remediation deadline, and private-sector organizations should treat that deadline as their own benchmark.
This post breaks down the vulnerability from a defender's perspective: how the attack chain works, what exploitation looks like in your logs and on your endpoints, and the exact detection content and remediation steps you need to execute this week.
Technical Analysis
Affected Products
CVE-2026-5430 impacts the following WSO2 product lines:
- WSO2 API Control Plane
- WSO2 API Manager (the most widely deployed component — commonly exposed on ports 9443 for the management console and 8243/8280 for gateway traffic)
- WSO2 Traffic Manager
- WSO2 Universal Gateway
These products share the WSO2 Carbon kernel, which is why a single vulnerability class cuts across the product family. In our experience, organizations frequently undercount their exposure here: WSO2 nodes are often deployed in clusters behind load balancers, and forgotten staging or DR instances running older builds are prime targets.
How the Vulnerability Works
At its core, CVE-2026-5430 is a path traversal flaw (CWE-22). The vulnerable component fails to properly sanitize file path input in an HTTP request handler, allowing an attacker to escape the intended upload or resource directory using traversal sequences (../, URL-encoded variants such as %2e%2e%2f, and double-encoded forms like %252e%252e%252f).
The attack chain, as observed in active exploitation:
- Reconnaissance: The attacker identifies an exposed WSO2 endpoint — typically the management console (port 9443) or a file-handling servlet — via internet scanning. WSO2 instances have a distinctive TLS certificate and HTTP response fingerprint (
Server: WSO2 Carbon Serverheaders and characteristic login pages), making them trivial to enumerate at scale. - Traversal + Unrestricted File Upload: The attacker submits a crafted multipart request containing traversal sequences in the filename or path parameter. Because the application fails to canonicalize and validate the destination path, the uploaded file is written outside the intended directory.
- Webshell Drop: The classic landing spot is an attacker-controlled JSP file written into a deployed web application directory — for example, under
<WSO2_HOME>/repository/deployment/server/webapps/or a tenant webapp path. WSO2's Tomcat-based container hot-deploys or serves the file. - Unauthenticated Code Execution: The attacker issues a GET/POST request to the dropped JSP, executing arbitrary OS commands with the privileges of the
wso2service account. Critically, no authentication is required to reach the vulnerable code path — this is a pre-auth RCE. - Post-Exploitation: From there, we typically observe the standard playbook: dropping a secondary payload, establishing persistence (cron, systemd units, or additional webshells), harvesting the WSO2 keystore and
deployment.tomlcredentials (which frequently contain database, LDAP, and keystore passwords in recoverable form), and pivoting into internal API backends — which, by architectural design, the gateway can reach.
Why This Is Especially Dangerous
API gateways and management planes sit at a trust boundary by design. A compromised WSO2 node doesn't just give an attacker a shell on one server — it gives them a privileged vantage point over every API that flows through it: tokens, API keys, backend service credentials, and the ability to modify API definitions to intercept or manipulate traffic. Treat any confirmed compromise as a full credential-exposure incident, not a single-host event.
Exploitation Status
- CISA KEV: Added 2026-09-24 — confirmed active exploitation.
- Mandated action: Apply vendor mitigations per CISA BOD 26-04, Prioritizing Security Updates Based on Risk, and comply with CISA's Forensics Triage Requirements. Where mitigations are unavailable for cloud services, follow applicable BOD 26-04 guidance or discontinue use of the product.
- Attacker sophistication: Consistent with opportunistic mass exploitation following KEV listing, but the pre-auth RCE nature of this bug makes it equally attractive to initial access brokers and APT operators. Assume scanning began before the KEV listing and check historical logs, not just traffic from today forward.
Detection & Response
Detection for this threat operates on three layers: (1) web/proxy logs showing traversal attempts against WSO2 endpoints, (2) host telemetry showing the WSO2 Java process behaving abnormally (spawning shells, writing JSP files), and (3) file-system forensics hunting for webshell artifacts in deployment directories. Prioritize layer two — it is the highest-fidelity signal and the least likely to be evaded.
Sigma Rules
The following rules target the highest-signal behaviors: web traversal attempts against WSO2 paths, the WSO2 JVM spawning operating-system shells (near-zero legitimate use), and JSP file creation in WSO2 webapp deployment directories.
---
title: WSO2 Path Traversal Attempt in Web Request - CVE-2026-5430
id: 3f8a1c44-7b2e-4d91-9c05-6a7e2f8b1d33
status: experimental
description: Detects path traversal sequences in HTTP requests targeting WSO2 management console, file upload servlets, or gateway endpoints. Indicative of exploitation attempts against CVE-2026-5430.
references:
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-5430
- https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/09/26
tags:
- attack.initial_access
- attack.t1190
logsource:
category: webserver
detection:
selection_traversal:
cs-uri|contains:
- '../'
- '..\\'
- '%2e%2e%2f'
- '%2e%2e%5c'
- '%252e%252e%252f'
- '..%c0%af'
- '..;/'
selection_wso2:
cs-uri|contains:
- '/fileupload'
- '/fileUpload'
- '/carbon/'
- '/services/'
- '/api/am/'
- '/authenticationendpoint/'
condition: selection_traversal and selection_wso2
falsepositives:
- Rare. Legitimate API requests containing encoded traversal sequences are uncommon on WSO2 admin and file-handling endpoints.
level: high
---
title: WSO2 Java Process Spawning Shell or Command Interpreter
id: 8c2d5e19-4a6f-4b83-a1d7-9e3c6f2a5b44
status: experimental
description: Detects the WSO2 Carbon JVM (java) spawning cmd.exe, powershell.exe, sh, bash, or other command interpreters. A strong indicator of webshell execution following CVE-2026-5430 file upload. WSO2 JVMs do not legitimately spawn OS shells in normal operation.
references:
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-5430
- https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/09/26
tags:
- attack.persistence
- attack.execution
- attack.t1505.003
- attack.t1059
logsource:
category: process_creation
detection:
selection_parent:
ParentImage|endswith:
- '\\java.exe'
- '/java'
selection_parent_cmdline:
ParentCommandLine|contains:
- 'wso2'
- 'carbon'
selection_child:
Image|endswith:
- '\\cmd.exe'
- '\\powershell.exe'
- '\\pwsh.exe'
- '\\net.exe'
- '\\whoami.exe'
- '\\certutil.exe'
- '/sh'
- '/bash'
- '/dash'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
- '/python'
- '/python3'
condition: selection_parent and selection_parent_cmdline and selection_child
falsepositives:
- WSO2 startup scripts invoking shells before JVM handoff (filter on ParentCommandLine containing 'wso2server.sh' wrapper chain if noise appears)
- Custom mediation extensions executing system commands (rare; baseline per host)
level: critical
---
title: JSP File Created in WSO2 Webapp Deployment Directory
id: b47e9f02-1d3c-4a58-8e6b-2c9d4a7f5e61
status: experimental
description: Detects creation of JSP/JSPX files in WSO2 webapp deployment directories by non-installer processes. A primary artifact of CVE-2026-5430 unrestricted file upload leading to webshell deployment.
references:
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-5430
- https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/09/26
tags:
- attack.persistence
- attack.t1505.003
logsource:
category: file_event
detection:
selection_path:
TargetFilename|contains:
- '\\repository\\deployment\\server\\webapps\\'
- '/repository/deployment/server/webapps/'
- '\\repository\\deployment\\server\\jaggeryapps\\'
- '/repository/deployment/server/jaggeryapps/'
- '\\repository\\deployment\\server\\servletfeatures\\'
- '/repository/tenants/'
selection_ext:
TargetFilename|endswith:
- '.jsp'
- '.jspx'
- '.war'
condition: selection_path and selection_ext
falsepositives:
- Legitimate application deployments by administrators or CI/CD pipelines. Correlate with change windows and deployment tooling accounts; alert on creation by the wso2 service account itself outside deployment pipelines.
level: high
KQL — Microsoft Sentinel / Defender
The first query hunts web traversal attempts against WSO2 paths in proxy/firewall logs ingested via CEF (CommonSecurityLog). The second hunts host-level process execution in Defender — the JVM spawning shells — which is your highest-fidelity compromise indicator.
// Hunt 1: Path traversal attempts targeting WSO2 endpoints in proxy/firewall logs (CEF)
let lookback = 14d;
CommonSecurityLog
| where TimeGenerated > ago(lookback)
| where RequestURL has_any ("/carbon/", "/fileupload", "/fileUpload", "/services/", "/api/am/", "/authenticationendpoint/")
| where RequestURL has_any ("../", "%2e%2e%2f", "%2e%2e%5c", "%252e%252e%252f", "..%c0%af", "..;/")
or AdditionalExtensions has_any ("../", "%2e%2e%2f", "%252e%252e%252f")
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Attempts=count(),
SampleURLs=make_set(RequestURL, 10), SourceIPs=make_set(SourceIP, 10)
by DestinationIP, DestinationPort
| order by Attempts desc;
// Hunt 2: WSO2 JVM spawning command interpreters (webshell execution artifact)
DeviceProcessEvents
| where TimeGenerated > ago(lookback)
| where InitiatingProcessFileName =~ "java" or InitiatingProcessFileName =~ "java.exe"
| where InitiatingProcessCommandLine has_any ("wso2", "carbon")
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "sh", "bash", "dash", "curl", "wget", "nc", "ncat", "python", "python3", "whoami.exe", "net.exe", "certutil.exe")
| project TimeGenerated, DeviceName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName, RemoteIP, InitiatingProcessRemoteIP
| order by TimeGenerated desc;
// Hunt 3: New JSP/WAR files appearing on WSO2 hosts (Defender file events)
DeviceFileEvents
| where TimeGenerated > ago(lookback)
| where FolderPath has_any ("repository\\deployment\\server\\webapps", "repository/deployment/server/webapps", "repository\\deployment\\server\\jaggeryapps", "repository/tenants")
| where FileName endswith ".jsp" or FileName endswith ".jspx" or FileName endswith ".war"
| project TimeGenerated, DeviceName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256
| order by TimeGenerated desc;
Velociraptor VQL
This artifact hunts WSO2 deployment directories for recently created or modified JSP files — the canonical webshell landing zone — and cross-references the running JVM process. Run it across your WSO2 fleet, prioritizing internet-facing nodes. Files dropped in the last 30 days that are not attributable to a known deployment require immediate triage.
-- CVE-2026-5430: Hunt for webshell artifacts in WSO2 deployment directories
-- Flags recently created/modified JSP/WAR files and captures JVM context
LET wso2_roots <= SELECT FullPath FROM glob(
globs=[
'/opt/wso2*/repository/deployment/server/webapps/**',
'/opt/wso2*/repository/deployment/server/jaggeryapps/**',
'/home/wso2*/**/repository/deployment/server/webapps/**',
'C:/Program Files/WSO2/**/repository/deployment/server/webapps/**'
])
LET suspicious_files <= SELECT FullPath, Size, Mtime, Btime, Mode
FROM glob(globs=['**/*.jsp', '**/*.jspx', '**/*.war'],
root='/')
WHERE (FullPath =~ 'repository/deployment/server/webapps'
OR FullPath =~ 'repository/deployment/server/jaggeryapps'
OR FullPath =~ 'repository/tenants')
AND Mtime > (timestamp(epoch=now() - 30*24*3600))
LET jvm_procs <= SELECT Pid, Name, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ 'java' AND CommandLine =~ 'wso2|carbon'
SELECT 'FILE' AS ArtifactType, FullPath AS Detail, Size, Mtime, Btime, NULL AS Pid, NULL AS CommandLine
FROM suspicious_files
UNION ALL
SELECT 'JVM_PROCESS' AS ArtifactType, CommandLine AS Detail, NULL AS Size, NULL AS Mtime, NULL AS Btime, Pid, CommandLine
FROM jvm_procs
Triage Guidance for Findings
If any of the above detect fire, move fast and preserve evidence — CISA's Forensics Triage Requirements (referenced in the KEV entry) apply to federal agencies and are sound practice for everyone:
- Isolate, do not rebuild (yet). Snapshot the host and capture memory before remediation. The WSO2 keystore,
deployment.toml, and in-memory tokens are forensically critical. - Pull the access logs. WSO2 logs HTTP access to
<WSO2_HOME>/repository/logs/http_access_*.logandwso2carbon.log. Look for traversal sequences and requests to any JSP files you cannot attribute to a legitimate deployment. - Assume credential exposure. Rotate everything the node could touch: keystore passwords, database credentials in
deployment.toml, LDAP binds, API keys, and OAuth client secrets managed by the platform. - Check downstream APIs. Audit backend service logs for requests sourced from the WSO2 host that fall outside normal gateway traffic patterns.
Remediation
Immediate Actions (Today)
- Apply the WSO2 security update addressing CVE-2026-5430 immediately. Follow the official WSO2 security advisory for your product and version — WSO2 delivers fixes via its Updates 2.0 channel (
wso2updatetool). Consult the advisory at https://security.wso2.com/ and the CISA KEV entry at the source URL for the authoritative mitigation instructions. If you are a WSO2 subscription customer, contact WSO2 support to confirm the exact update level that remediates the flaw for your deployment. - Federal agencies: comply with BOD 26-04 within the KEV-mandated due date. Where a patched version cannot be deployed in time for cloud-hosted services, follow the BOD's discontinuation guidance — take the service offline rather than accept unauthenticated RCE exposure.
- Block management interfaces at the network edge. The WSO2 management console (
/carbon, port 9443) and file-upload servlets should never be reachable from the internet. Enforce ACLs or WAF rules restricting admin-plane access to trusted management networks now, independent of patching. - Deploy WAF rules blocking traversal sequences (
../,%2e%2e%2f,%252e%252e%252f,..;/) in URI paths and multipart filename parameters as a compensating control. Note: this is mitigation, not remediation — encoding bypasses exist, and only the vendor patch closes the hole.
Verification and Hardening Script
Use the following on Linux WSO2 hosts to inventory installations, check update level, sweep logs for traversal indicators, and find recently dropped JSP files. Run it before patching (to capture evidence of compromise) and after (to verify clean state).
#!/bin/bash
# CVE-2026-5430 WSO2 triage & verification script - run as root
REPORT="/tmp/wso2_cve_2026_5430_triage_$(date +%Y%m%d_%H%M%S).txt"
exec > >(tee -a "$REPORT") 2>&1
echo "=== [1] Locate WSO2 installations ==="
find /opt /home /usr/local -maxdepth 4 -type d -name "wso2*" 2>/dev/null
find /opt /home /usr/local -maxdepth 6 -type f -name "wso2server.sh" 2>/dev/null
echo "=== [2] Check WSO2 update level (Updates 2.0) ==="
for d in /opt/wso2* /home/*/wso2*; do
if [ -f "$d/bin/wso2update_linux" ]; then
echo "--- $d ---"
sudo -u "$(stat -c '%U' "$d")" "$d/bin/wso2update_linux" --version 2>/dev/null
sudo -u "$(stat -c '%U' "$d")" "$d/bin/wso2update_linux" check 2>/dev/null | tail -5
fi
done
echo "=== [3] Sweep access & carbon logs for traversal attempts ==="
find / -path "*/repository/logs" -type d 2>/dev/null | while read -r logdir; do
echo "--- Scanning $logdir ---"
grep -rEi '(\.\./|%2e%2e%2f|%252e%252e%252f|\.\.%c0%af|\.\.;/)' "$logdir" 2>/dev/null | head -50
done
echo "=== [4] Hunt for recent JSP/WAR files in deployment dirs (last 30 days) ==="
find /opt /home /usr/local -type d \( -path "*repository/deployment/server/webapps*" -o -path "*repository/tenants*" \) 2>/dev/null | while read -r dir; do
find "$dir" \( -name "*.jsp" -o -name "*.jspx" -o -name "*.war" \) -mtime -30 -printf "%T+ %u %p\n" 2>/dev/null
done
echo "=== [5] Check for shells spawned by the WSO2 JVM (current processes) ==="
WSO2_PID=$(pgrep -f "wso2.*java|carbon.*java" | head -5)
for pid in $WSO2_PID; do
echo "--- Children of JVM PID $pid ---"
ps --ppid "$pid" -o pid,ppid,user,cmd 2>/dev/null
done
echo "=== [6] Verify management console is not internet-exposed (local listeners) ==="
ss -tlnp 2>/dev/null | grep -E ':(9443|9763|8280|8243)'
echo "=== [7] New cron/systemd persistence (last 14 days) ==="
find /etc/cron* /var/spool/cron /etc/systemd/system -type f -mtime -14 -printf "%T+ %p\n" 2>/dev/null | sort -r | head -30
echo "=== Report written to $REPORT — preserve this file for forensics ==="
Strategic Hardening (This Quarter)
- Separate the control plane from the data plane. WSO2 Control Plane and management consoles belong on isolated management subnets with jump-host access, never co-exposed with gateway runtime traffic.
- Run the WSO2 JVM under a dedicated, least-privilege service account with no sudo rights and read-only access to anything outside
<WSO2_HOME>. This blunts post-exploitation from webshells. - Deploy file integrity monitoring (or the Sigma/VQL content above continuously) on
repository/deployment/server/webapps/andrepository/tenants/. Webshell detection on gateway infrastructure is non-negotiable. - Centralize WSO2 logs. Ship
http_access_*.log,wso2carbon.log, and audit logs to your SIEM in near-real-time. Local logs on a compromised host will be the first thing an attacker tampers with. - Add API gateway infrastructure to your vulnerability management SLA. KEV-listed flaws on internet-facing middleware should carry a 48–72 hour internal patch SLA, mirroring BOD 26-04's risk-based urgency, regardless of whether you fall under federal mandate.
Closing Assessment
CVE-2026-5430 follows a pattern we have watched repeat across the middleware and gateway ecosystem: a file-handling path traversal, chained to unrestricted upload, landing an unauthenticated webshell on infrastructure that brokers trust for the entire enterprise API estate. CISA's KEV listing confirms exploitation is happening now. The defensive math is simple — patch per the vendor advisory, pull your management plane off the internet, hunt for the artifacts described above going back at least 30 days, and treat any hit as a full credential-exposure incident. If you need surge capacity for the hunt or the IR work, that is exactly what we do.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.