CVE-2024-12700: Unrestricted File Upload RCE Vulnerability

CVE-2024-12700 Overview

CVE-2024-12700 is an unrestricted file upload vulnerability [CWE-434] disclosed through CISA ICS Advisory ICSA-24-354-05. An authenticated user with low privileges can upload a JavaServer Pages (JSP) web shell to the affected web application. Once uploaded, the shell executes arbitrary code with the privileges of the account running the web server. The issue is network-exploitable and requires no user interaction beyond authentication. It affects an industrial-context web application distributed by Aggregate Digital.

Critical Impact
Any authenticated low-privileged account can obtain remote code execution on the underlying host, compromising confidentiality, integrity, and availability of the web server and adjacent systems.

Affected Products

Aggregate Digital software distributed via Aggregate Digital Downloads
Web application component that accepts file uploads from authenticated users
Refer to CISA ICS Advisory ICSA-24-354-05 for the authoritative affected version list

Discovery Timeline

2024-12-19 - CVE-2024-12700 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-12700

Vulnerability Analysis

The application exposes a file upload endpoint that does not restrict the type, extension, or content of uploaded files. An authenticated user can submit a .jsp file containing a web shell to a location served by the application container. Because the container processes JSP files as executable server-side code, subsequent requests to the uploaded resource invoke the shell. The shell runs in the security context of the web server process, giving attackers command execution, file system access, and outbound network capability from the compromised host.

Root Cause

The root cause is missing validation on the upload handler. The application does not enforce an allowlist of permitted MIME types or extensions, does not verify file content against declared types, and stores uploaded files inside a directory that the JSP engine treats as executable. This combination allows an authenticated user to place server-side code within the application's execution path.

Attack Vector

An attacker first obtains valid low-privilege credentials, either through phishing, credential reuse, or legitimate account provisioning. The attacker then submits a crafted multipart request to the upload endpoint with a JSP payload. After the upload completes, the attacker issues an HTTP GET or POST to the uploaded resource path, triggering execution. From there, the attacker can pivot into the operating system, harvest credentials, and move laterally.

No verified exploit code has been released publicly. Technical details are documented in the vendor and CISA advisories linked above.

Detection Methods for CVE-2024-12700

Indicators of Compromise

Newly created .jsp, .jspx, or .jsw files inside upload directories or under the web application root that do not match the vendor's shipped file inventory
HTTP POST requests to the application's upload handler followed by GET requests to unfamiliar .jsp resources from the same client
Web server processes (for example java, tomcat, catalina) spawning shell interpreters such as cmd.exe, powershell.exe, /bin/sh, or /bin/bash
Outbound network connections initiated by the web server process to unusual destinations shortly after upload activity

Detection Strategies

Deploy file integrity monitoring on web application directories to flag creation or modification of server-side executable files
Inspect web server access logs for sequential upload-then-execute request patterns from a single authenticated session
Correlate authentication events with upload activity to identify anomalous behavior from low-privilege accounts
Apply signatures or YARA rules for common JSP web shell families (JspSpy, Behinder, AntSword, Godzilla)

Monitoring Recommendations

Alert on any child process spawned by the web server user account, since a well-configured application server rarely forks shells during normal operation
Monitor egress traffic from web application hosts for reverse shell and command-and-control patterns
Track authentication logs for low-privilege accounts that interact with administrative or upload endpoints

How to Mitigate CVE-2024-12700

Immediate Actions Required

Apply the vendor patch referenced in CISA ICS Advisory ICSA-24-354-05 once obtained from the Aggregate Digital downloads portal
Audit web application upload directories for unauthorized .jsp files and remove any that are not part of the vendor distribution
Rotate credentials for all low-privilege accounts that had access to the upload functionality prior to patching
Isolate the affected system from untrusted networks until the patch is deployed

Patch Information

Refer to the vendor advisory and CISA advisory ICSA-24-354-05 for fixed version details and download instructions. Verify patch application by confirming that the upload handler rejects .jsp and other server-executable file extensions.

Workarounds

Restrict access to the upload endpoint at the reverse proxy or firewall layer so only trusted administrative IP ranges can reach it
Configure the application server to prevent JSP execution within upload directories, for example by mapping those paths to a static content handler
Enforce an allowlist of permitted MIME types and extensions at a web application firewall in front of the application
Run the web server under a dedicated low-privilege service account with no interactive shell and no write access outside required directories

bash

# Example Apache Tomcat configuration to disable JSP execution in an uploads directory
# Place inside the application's WEB-INF/web.xml
<servlet-mapping>
    <servlet-name>jsp</servlet-name>
    <url-pattern>*.jsp</url-pattern>
    <url-pattern>*.jspx</url-pattern>
</servlet-mapping>

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Uploads</web-resource-name>
        <url-pattern>/uploads/*</url-pattern>
    </web-resource-collection>
    <auth-constraint/>
</security-constraint>