CVE-2022-29464 is an unrestrictive upload of file vulnerability in WSO2 Multiple Products. CISA added it to the Known Exploited Vulnerabilities catalogue on 25 April 2022, which means attackers have used it in real attacks. Multiple WSO2 products allow for unrestricted file upload, resulting in remote code execution.
What This Vulnerability Means in Practice
This CVE is dangerous because unrestricted file upload can let an attacker place server-side content where the application did not intend to accept it. In a product that processes uploads on the application tier, that can turn a simple content-handling flaw into remote code execution, which is why upload validation is treated as a high-risk control boundary.
For background on the record itself and to confirm authoritative vulnerability details, use the CVE Program and the NIST National Vulnerability Database. Those sources are the right place to verify the canonical CVE entry and related record data.
Why Unrestricted Uploads Become Remote Code Execution
Upload features are risky when the server accepts a file, stores it in a reachable location, and later processes or executes it with application privileges. If the application trusts filename, extension, MIME type, or client-side checks alone, an attacker may be able to smuggle active content, overwrite trusted files, or place a payload that the server later interprets.
That danger is not limited to one product family. File upload weaknesses often combine with path handling, content-type confusion, or unsafe deployment locations, which is why file upload security belongs in the same conversation as web application attack patterns. NHIMG’s Web Application Attacks Guide is useful context for the broader attack surface around upload handling and server-side exploitation.
How Organisations Check Exposure and Reduce Attack Surface
The first question is whether the affected product is present anywhere in the estate, including external-facing instances, test deployments, partner-exposed portals, and forgotten environments. Internet exposure matters because an upload flaw becomes far easier to weaponise when the vulnerable endpoint is directly reachable, and vendor advisories should be checked for the exact affected release family and remediation path.
Because this CVE was added to CISA’s Known Exploited Vulnerabilities catalogue, organisations should treat it as a prioritisation signal, not a theoretical issue. The most useful operational reference is NHIMG’s Vulnerability Management Guide, which frames how to scope assets, check KEV status, and verify remediation rather than assuming a generic patch cycle is enough.
Detection, Containment, and Post-Exploitation Review
Once upload abuse is suspected, teams should review web logs, application logs, and host telemetry for unusual upload paths, unexpected file types, new executable content, and follow-on process creation. Because the vulnerability can lead to code execution, the post-event review should also look for new web shells, modified application files, suspicious outbound connections, and any signs that the attacker used the foothold to pivot deeper into the host or adjacent services.
Where compromise is plausible, containment should include isolating the server, preserving evidence, and reviewing whether the attacker could have accessed credentials, session material, or service configuration stored on or reachable from the application host. NHIMG’s The State of NHI & AI Agent Breach Report 2026 is relevant here because it illustrates how exploitation often becomes an identity and secrets problem after initial access.
Risk and Threat Considerations
Unrestricted upload flaws are attractive because they can convert ordinary application input into server-side execution, which gives an attacker a durable foothold rather than a one-time data error. The main risk is not the file itself, but the trust the application places in content that should never be executable or reachable as code.
Failure mechanism: The attacker uploads a payload that bypasses validation, lands in a server-accessible path, and is then interpreted by the application stack or underlying web server as executable content.
Impact: Remote code execution can lead to full application takeover, data theft, tampering, persistence, and further movement into adjacent systems or administrative interfaces.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Validates untrusted upload input before the server processes it |
| SC-7 — Boundary Protection | Upload endpoints cross a trust boundary that must be constrained and monitored | |
| Recommendation — Enforce server-side validation on every uploaded file and reject unexpected content types, names, and structures. Segment upload services and restrict where uploaded content can be written or executed. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Covers secure handling of web application inputs and common exploitation paths |
| Recommendation — Harden the application’s upload workflow and test it for unsafe file handling before release. | ||
| OWASP ASVS | V5 — File Handling | Directly addresses secure upload, storage, and processing of files in web apps |
| Recommendation — Apply file-handling verification to prevent executable or dangerous uploads from reaching the server. | ||
| MITRE ATT&CK | T1105 — Ingress Tool Transfer | Attackers often stage payloads through upload or transfer mechanisms before execution |
| Recommendation — Hunt for staged payload transfer and follow-on execution after suspicious uploads. | ||
Practitioner Guidance
Why practitioners should care: File upload controls are not just input-validation hygiene, they are an execution boundary. Treat every upload path as a potential code-loading or content-hosting path until proven otherwise.
What to watch for: Review whether the application stores uploads outside the web root, re-encodes or sanitises content safely, and rejects unexpected file types by server-side policy rather than by client-supplied metadata. If you cannot guarantee safe handling, reduce the feature, move processing out of the web tier, or isolate it behind stronger containment.