Is CVE-2022-26352 (dotCMS Unrestricted Upload of File) being exploited in the wild?

What Makes This CVE a Live Exploitation Case?

CVE-2022-26352 is not just a theoretical upload flaw. The practical question is whether the vulnerability has crossed from a software weakness into active attacker use, which changes triage from routine patching to urgent exposure management. Once a CVE is in CISA's Known Exploited Vulnerabilities catalogue, teams should treat it as an exploitation signal, not a scoring exercise.

For a file upload flaw, the real operational issue is often not the upload itself but what the attacker can place, where it lands, and whether that content can be executed, traversed, or abused later. That is why unrestricted upload issues are routinely paired with webshell placement, path manipulation, and follow-on compromise paths.

For broader context on how active exploitation changes response priority, see Zero-Day and Exploited Vulnerabilities Guide, which covers KEV triage, emergency mitigation, and post-patch hunting.

How to Confirm Exposure and Judge Severity Quickly

Start by confirming whether any internet-facing or partner-facing dotCMS instance is in scope, then verify whether the ContentResource API path is reachable from those entry points. If the application exposes upload functions to unauthenticated or broadly authenticated users, the exposure should be treated as materially higher until proven otherwise.

Next, determine whether uploaded files are stored with restrictive path handling, extension checks, and content validation. A flaw described as unrestricted upload of a dangerous type becomes much more serious when uploaded content can be written outside the intended directory or interpreted by another component in the stack.

Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog for version-specific guidance, because the authoritative response is to confirm exposure against the product advisory rather than rely on generic CVE summaries.

Containment, Fix, and What to Check Afterward

If patching or upgrading is delayed, the priority is to block the vulnerable upload path as tightly as possible, restrict access to the affected endpoint, and monitor for suspicious file placement or execution attempts. In practice, temporary containment is only useful if it removes the attacker’s ability to write, store, or reach dangerous content through the vulnerable API.

After remediation, look for evidence of earlier compromise. With upload vulnerabilities, that means reviewing web server logs, application logs, filesystem changes, and any unexpected files beneath web-accessible or application-controlled directories. If the system allowed path traversal or storage outside the intended location, check adjacent directories as well as the nominal upload path.

Where the upload path may have been abused to stage a webshell or script, validate whether any sessions, admin credentials, or backend service accounts were used after the first suspicious write event. For file upload hardening patterns and isolation controls, File Upload Security Guide is the most direct internal reference.

Why This Pattern Shows Up in Real Intrusions

Upload flaws are attractive because they can create an initial foothold without needing password theft first. Once an attacker can place a file in a reachable location, the next step is often to turn that file into execution, persistence, or a staging point for additional activity. That is why file upload weaknesses often sit at the front of a compromise chain rather than the end of it.

When the vulnerable component is a content management platform, the blast radius can include published content workflows, admin sessions, and server-side file handling logic. The issue becomes more than data integrity, it becomes a route into the application trust boundary. For a root-cause view of how dangerous upload weaknesses are categorized, the CWE Top 25 Guide helps map the flaw to common weakness patterns practitioners already track.

Risk and Threat Considerations

Because CISA placed this CVE in KEV and marked it as used in ransomware campaigns, the risk is not limited to opportunistic web probing. The concern is that a seemingly simple upload bug can become a dependable entry path for post-exploitation activity, especially if the uploaded content can be written to a location the server later executes or processes.

Failure mechanism: An attacker abuses the unrestricted upload path to place a malicious file, bypass content or extension controls, and store it where the application or web server can later reach, traverse, or execute it.

Impact: The result can be unauthorized code execution, persistence, defacement, data access, or a stepping stone into broader intrusion activity, including ransomware deployment.

Practitioner Guidance

What to verify: Confirm the exact upload route, storage location, and whether any uploaded file can be reached from a web path, application parser, or downstream job. If the answer is yes, treat the issue as an exploitation path until the storage and execution boundaries are demonstrably separated.

Decision rule: If the vulnerable instance is exposed and cannot be patched immediately, disable or front-end the upload function rather than trusting validation alone. A partially filtered upload endpoint is still high risk when the attack path depends on path traversal or dangerous file type handling.

Common mistake: Teams often focus on file extension checks and miss the storage boundary. The dangerous condition is not only what the user uploads, but where the file lands and what the platform can do with it afterward.

Practitioner takeaway: For this CVE, treat KEV listing as an active exploitation signal, then verify exposure, close the upload path, and hunt for files or execution traces that suggest the flaw was already used.

Related resources from NHI Mgmt Group

• CVE-2022-26352 (dotCMS Unrestricted Upload of File)
• Is CVE-2021-20022 (SonicWall Email Security Unrestricted Upload of File) being exploited in the wild?
• Is CVE-2021-26828 (OpenPLC ScadaBR Unrestricted Upload of File with Dangerous Type) being exploited in the wild?
• Is CVE-2024-7694 (TeamT5 ThreatSonar Anti-Ransomware Unrestricted Upload of File with Dangerous Type) being exploited in the wild?