CVE-2024-13201: Springboot-blog RCE Vulnerability

CVE-2024-13201 Overview

CVE-2024-13201 is an unrestricted file upload vulnerability in wander-chu SpringBoot-Blog 1.0. The flaw resides in the upload function within src/main/java/com/my/blog/website/controller/admin/AttachtController.java, part of the Admin Attachment Handler component. Attackers manipulating the file argument can upload arbitrary files to the server without proper validation of file type, content, or extension.

The vulnerability is exploitable remotely and requires high privileges, meaning the attacker must have authenticated administrative access. The exploit has been publicly disclosed. The vendor was contacted about the disclosure but did not respond, leaving the project without an official patch.

Critical Impact
Authenticated administrators can upload arbitrary files through the attachment handler, potentially leading to webshell deployment and full server compromise.

Affected Products

wander-chu SpringBoot-Blog 1.0
Component: Admin Attachment Handler (AttachtController.java)
Function: upload

Discovery Timeline

2025-01-09 - CVE-2024-13201 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-13201

Vulnerability Analysis

The vulnerability is categorized under [CWE-434] Unrestricted Upload of File with Dangerous Type and [CWE-284] Improper Access Control. It affects the attachment upload handler exposed through the administrative interface of SpringBoot-Blog.

The upload function in AttachtController.java accepts files from authenticated administrators but does not enforce restrictions on the file type, MIME type, or extension. Because the uploaded files are stored within a web-accessible directory, attackers who upload server-executable content such as .jsp files can invoke that content over HTTP to achieve remote code execution.

The EPSS score for this issue is 0.5% with a percentile of 39.9, indicating a low predicted probability of exploitation activity in the near term. However, the public disclosure through the project's GitHub issue tracker lowers the barrier to weaponization.

Root Cause

The root cause is the absence of server-side validation in the attachment upload flow. The handler processes multipart form data without verifying whether the submitted file parameter matches an allowlist of permitted formats. Neither content sniffing nor extension validation prevents dangerous types such as scripts or executable web content from being written to disk.

Attack Vector

An authenticated administrator sends a crafted HTTP POST request containing a malicious file payload to the attachment upload endpoint. Because the request is processed over the network and no user interaction is needed beyond the attacker's own submission, exploitation is straightforward once administrative credentials are obtained. Credential theft, brute force against weak admin passwords, or insider abuse can each satisfy the privilege requirement.

For technical details, see the GitHub Issue Report and the VulDB entry.

Detection Methods for CVE-2024-13201

Indicators of Compromise

Unexpected files with executable extensions such as .jsp, .jspx, or .war appearing in the SpringBoot-Blog attachment storage directory
HTTP POST requests to the attachment upload endpoint originating from unusual IP addresses or outside normal admin working hours
Outbound network connections initiated by the SpringBoot-Blog Java process to unfamiliar destinations following an upload event
New administrative sessions preceding file upload activity that do not correlate with known admin logins

Detection Strategies

Inspect web server access logs for POST requests to the admin attachment upload path followed by GET requests to the newly created file
Monitor the attachment storage directory with file integrity monitoring to alert on creation of files with non-media extensions
Correlate authentication events with upload activity to identify anomalous administrator behavior

Monitoring Recommendations

Enable verbose logging of the AttachtController upload handler including original filename, content type, and source IP
Forward SpringBoot-Blog application logs and web server logs to a centralized SIEM for retention and correlation
Alert on process execution spawned by the Java runtime that hosts the blog application, such as shell or scripting interpreters

How to Mitigate CVE-2024-13201

Immediate Actions Required

Restrict access to the SpringBoot-Blog admin interface using network controls, VPN, or IP allowlisting until a fix is available
Rotate all administrator credentials and enforce strong password policies to reduce the risk of unauthorized authenticated access
Audit the attachment storage directory for unauthorized files and remove any suspicious uploads
Consider decommissioning or replacing the affected 1.0 release given the vendor's lack of response to the disclosure

Patch Information

No official patch is available. According to the CVE record, the vendor was contacted early about the disclosure but did not respond. Organizations running wander-chu SpringBoot-Blog 1.0 must apply compensating controls or migrate to an actively maintained blog platform. Track the GitHub Issue Discussion for community-supplied fixes.

Workarounds

Modify the upload function in AttachtController.java to enforce an allowlist of permitted extensions and MIME types such as image/png, image/jpeg, and image/gif
Store uploaded attachments outside the web root or in a directory configured to prevent script execution
Rename uploaded files to server-generated identifiers to prevent attackers from predicting or controlling the final file path
Deploy a web application firewall rule to block multipart uploads containing script-like content targeting the attachment endpoint

bash

# Example nginx configuration to prevent script execution in the uploads directory
location ^~ /uploads/ {
    types { }
    default_type application/octet-stream;
    add_header X-Content-Type-Options nosniff;
    location ~* \.(jsp|jspx|war|sh|py|php)$ {
        deny all;
        return 403;
    }
}