CVE-2024-53677

What it actually does

Apache Struts versions from 2.0.0 before 6.4.0 contain flawed file upload handling that can allow attacker-controlled upload metadata, such as file name or path-related parameters, to influence where an uploaded file is written. The issue is categorized as path traversal: an attacker may be able to escape the intended upload directory and place a file in an unintended location. If the target location is executable by the application server, such as a web-accessible JSP directory, the flaw can escalate from arbitrary file placement to remote code execution under the privileges of the Struts application or servlet container.

Why it matters to the business

Successful exploitation can allow an external attacker to compromise an internet-facing Struts application, deploy a web shell, steal application data, pivot to connected systems, or disrupt service. Although this issue is not currently listed in CISA KEV and is not marked as ransomware-used, the EPSS score is high, indicating meaningful likelihood of exploitation activity. Because Apache Struts is commonly used in business-critical Java web applications, exposed upload endpoints should be treated as high priority, especially where applications accept unauthenticated or low-privileged file uploads.

How an attack unfolds

An attacker first identifies a Struts-based application that uses the vulnerable legacy file upload logic. They locate an endpoint that accepts multipart file uploads and submit a crafted upload request that manipulates filename or related upload parameters with traversal sequences or encoded traversal characters. If the application and server layout allow it, the uploaded content is written outside the intended temporary or application-controlled upload directory. The attacker then attempts to place a server-executable file, such as a JSP payload, into a web-accessible deployment path. If the file is successfully written and reachable over HTTP, the attacker requests it to execute commands or establish persistent access. From there, they may enumerate secrets, modify application content, access backend services, or use the compromised application server as a foothold.

How to fix it

Upgrade Apache Struts to version 6.4.0 or later. For source-based deployments, include the upstream fix corresponding to apache/struts commit 9c5c80d1731a13af0dc80fc3a04700f9a15dcf2a or a later release that contains it. Where Ubuntu Pro 16.04 ESM packages are in scope, update nova to 2:13.1.4-0ubuntu4.5+esm1 or later. Review Struts upload configuration and migrate away from deprecated or legacy upload handling where applicable, following the Apache S2-067 guidance. As defense in depth, restrict upload endpoints to authenticated users where possible, enforce strict allowlists for file extensions and MIME types, generate server-side filenames instead of trusting client-supplied names, store uploads outside web-executable directories, disable execution in upload directories, and ensure the servlet container account cannot write to application deployment paths.

How to confirm the fix worked

Confirm that all deployed Struts libraries report version 6.4.0 or later and that no older struts2-core or related Struts JARs remain in application WEB-INF/lib directories, container shared libraries, build artifacts, or shaded packages. Validate software composition analysis results against runtime deployments, not only source repositories. Exercise representative upload functionality after patching to confirm business functionality still works. Test that uploaded files are stored only in the intended non-executable storage location, that filenames containing traversal sequences are rejected or normalized safely, and that uploaded files cannot be accessed as executable server-side code. For Ubuntu Pro 16.04 ESM systems, verify the installed nova package version is 2:13.1.4-0ubuntu4.5+esm1 or later.

Typical attack path

1. Identify internet-facing applications running Apache Struts versions before 6.4.0.
2. Find Struts actions or routes that accept multipart/form-data file uploads.
3. Send crafted upload requests containing traversal sequences in filename or upload-related parameters.
4. Attempt to write the uploaded file outside the intended upload directory.
5. Place a server-executable file in a web-accessible path if the filesystem layout and permissions allow it.
6. Request the uploaded file over HTTP to confirm execution or access.
7. Use the foothold to execute commands, collect secrets, modify content, or pivot further.

How to detect it

Investigate whether vulnerable upload endpoints received suspicious multipart/form-data requests containing traversal strings, encoded traversal strings, absolute paths, Windows path separators, or attempts to upload server-executable extensions such as .jsp, .jspx, .war, .class, .groovy, or script files. Useful sources include reverse proxy logs, web server access logs, WAF events, servlet container logs, Struts application logs, file integrity monitoring, EDR file creation telemetry, and web root change monitoring. Look for newly created or modified executable files under web-accessible directories, application deployment directories, servlet container work directories, and temporary upload locations. Correlate suspicious upload requests with subsequent GET or POST requests to the uploaded file path, child processes spawned by the Java or servlet container process, unexpected outbound network connections, and access to secrets or configuration files. Pay particular attention to uploads where the client-supplied filename includes ../, ..\, URL-encoded traversal, double encoding, or paths targeting webapps, ROOT, WEB-INF, META-INF, or similar deployment paths.

• filename="../
• filename="..\\
• filename*=UTF-8''..%2f
• filename*=UTF-8''..%5c
• %2e%2e%2f
• %2e%2e%5c
• ..%2f
• ..%5c
• %252e%252e%252f
• %252e%252e%255c
• ../webapps/ROOT/
• ..\\webapps\\ROOT\\
• /WEB-INF/
• \\WEB-INF\\
• /META-INF/
• \\META-INF\\
• .jsp"
• .jspx"
• .war"
• Content-Disposition: form-data

What your security team should do

• Prioritize patching internet-facing Struts applications and any application with unauthenticated or low-privileged upload functionality.
• Inventory Struts usage across source repositories, CI/CD artifacts, application servers, container images, and packaged applications; do not rely only on package manager data.
• Upgrade Apache Struts to 6.4.0 or later and redeploy affected applications from clean build artifacts.
• Search access logs, WAF logs, application logs, and EDR telemetry for suspicious multipart uploads containing traversal sequences or attempts to upload JSP/server-side scripts.
• Review web roots, deployment directories, temporary upload directories, and application writable paths for recently created JSP, WAR, class, or script files.
• Block or alert on multipart upload requests with encoded or double-encoded path traversal patterns at the WAF or reverse proxy while patching is underway.
• Ensure uploaded content is stored outside web-accessible and executable directories and that the application server process has least-privilege filesystem permissions.
• If suspicious file writes or web shell activity are found, preserve forensic evidence, rotate application secrets, review outbound connections, and rebuild affected application servers from trusted images.