Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2022-29464 (WSO2 Multiple Products Unrestrictive Upload of…
Threats, Abuse & Incident Response

Is CVE-2022-29464 (WSO2 Multiple Products Unrestrictive Upload of File) being exploited in the wild?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2022-29464 to its Known Exploited Vulnerabilities catalogue on 25 April 2022, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Multiple WSO2 products allow for unrestricted file upload, resulting in remote code execution. Any organisation running the affected product should treat remediation as urgent.

What “exploited in the wild” means for CVE-2022-29464

For this CVE, “exploited in the wild” is not a vague warning label. It means a public authority has already observed active abuse, so the question is no longer whether the flaw is theoretically dangerous but whether your own WSO2 deployment is exposed, reachable, and potentially already compromised.

The practical reading is simple: treat this as an active exploitation event, not a routine vulnerability-management item. If the affected product is internet-facing, the risk window is immediate; if it is internally reachable, the exposure can still be material because file-upload flaws often become a foothold for code execution and follow-on access.

For triage and escalation, use the CISA Known Exploited Vulnerabilities Catalog as the authoritative signal that exploitation has been confirmed, then validate your own exposure against the vendor advisory and asset inventory.

Why unrestricted file upload becomes a real-world compromise path

Unrestricted file upload is dangerous because the attacker is not just storing a file, they are trying to place executable or otherwise weaponised content where the application will trust it. In this class of issue, the security failure is usually not the upload itself, but the chain that follows: upload, placement, execution, and post-exploitation persistence.

That is why this CVE belongs with File Upload Security Guide style controls: type validation, content validation, storage isolation, and malware scanning are meant to break the attack path before the uploaded object can become code. When those controls are missing or bypassed, remote code execution becomes a realistic outcome rather than a theoretical one.

For current exploitation cases, the most important question is whether the vulnerable endpoint is reachable and whether uploaded content can influence server-side execution, templating, scripting, or downstream processing. If the answer is yes, assume an attacker may already have used it to plant a web shell or establish a durable foothold.

What to do if you cannot remediate immediately

If patching or vendor remediation must wait, containment matters more than debate about likelihood. Remove external reachability where possible, restrict the upload feature to the smallest trusted population, and isolate the application so any successful upload cannot directly execute in the web tier or adjacent services.

The most useful near-term control is to reduce the blast radius of a successful upload. That means reviewing where uploaded files land, whether they are executable, whether the service account has broader filesystem or command privileges than it should, and whether logs capture upload anomalies, unexpected file types, or post-upload execution attempts.

Use Vulnerability Management Guide to anchor the response in prioritisation, exception handling, verification, and post-remediation checks, because active exploitation calls for emergency handling rather than a normal patch queue.

Risk and Threat Considerations

When a file-upload CVE is confirmed as exploited, the main risk is not just service disruption, it is attacker-controlled code running in a trusted application context. That can turn one vulnerable endpoint into credential theft, lateral movement, data access, and, in some environments, ransomware staging.

Failure mechanism: The application accepts a file that should have been rejected, stores it in a location the server can act on, and then processes or serves it in a way that allows execution or control.

Impact: Attackers can gain remote code execution, deploy persistence, harvest secrets or session material, and use the compromised host as a pivot point for broader compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0DE.CM-01 — Networks and systems are monitored to detect potential cybersecurity eventsActive exploitation requires monitoring for abuse and compromise signals.
RS.MA-01 — Incidents are containedConfirmed exploitation calls for immediate containment of the affected service.
Recommendation — Monitor WSO2 upload activity and adjacent execution events for signs of exploitation. Isolate the vulnerable WSO2 instance before restoring normal access.
CIS Controls v8CIS-7 — Continuous Vulnerability ManagementThe question is about an actively exploited CVE that must be prioritised and tracked.
CIS-10 — Malware DefensesUnrestricted upload flaws often require scanning and blocking weaponised files.
Recommendation — Prioritise and remediate the exploited CVE on an emergency basis. Scan uploads and block executable or malicious file content.
NIST SP 800-53 Rev 5SI-3 — Malicious Code ProtectionUpload exploitation can deliver malicious content that must be detected or blocked.
Recommendation — Inspect and block malicious uploaded files before they execute.

Practitioner Guidance

What to verify: Confirm whether any WSO2 instance is exposed to untrusted users, whether file upload is enabled, and whether upload paths or handlers can reach executable contexts. Check logs for unusual upload names, unexpected MIME types, and any command, script, or archive activity immediately after upload.

What to prioritise: Treat internet-facing deployments and systems with privileged service accounts as highest priority. If the asset is business-critical, isolate it first, then hunt for compromise before returning it to service.

Practitioner takeaway: For an exploited file-upload CVE, the right first move is not only remediation, but blast-radius control and compromise assessment, because active exploitation often means the attacker may already have used the flaw to establish code execution.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org