Angular-Base64-Upload Library 0.1.20 - Remote Code Execution (RCE)

Angular-Base64-Upload Library 0.1.20 — CVE-2024-42640: Overview, Analysis and Mitigation

The Angular-Base64-Upload package (prior to v0.1.21) was assigned CVE-2024-42640 after disclosure of an unauthenticated remote code execution (RCE) vector affecting applications that exposed a provided demo endpoint or a similarly misconfigured server-side handler. This article explains the root cause, realistic impact, detection techniques, and practical, defense-oriented mitigations for developers, DevOps and security teams. The goal is to enable secure remediation and hardening without providing exploit steps or unsafe reproduction details.

Quick facts

• Package: angular-base64-upload
• Affected versions: prior to v0.1.21
• CVE: CVE-2024-42640
• Severity: Critical (RCE when server-side handling allows writing executable files into webroot)
• Primary cause: unsafe server-side handling of Base64 file uploads combined with permissive file placement/execution

Vulnerability summary and root cause

The published issue is not a flaw in Angular itself but the common server-side pattern used with a convenience/demo handler that accepts JSON payloads with a Base64-encoded file and a filename. When the server decodes and writes the uploaded bytes without sufficient validation, sanitization or storage hardening, an attacker can create a file that gets written into a web-accessible directory and then invoke it to execute arbitrary code.

Two conditions combined to make the defect exploitable in practice:

• An upload endpoint that decodes and writes arbitrary Base64 content to disk using a filename supplied by the client.
• Files stored in a location where the web server or application runtime will execute them (for example, writing PHP files into the webroot on a PHP-enabled server).

Mitigation therefore requires fixing server-side behavior and eliminating the ability to serve/execute attacker-controlled files from writable locations.

Impact and use cases

• Remote Code Execution: If an attacker can upload a script (for example, PHP) and the server will execute it, the attacker gains arbitrary code execution in the context of the webserver process.
• Data exfiltration / persistence: Compromise enables access to internal files, credentials, or a long-term foothold.
• Supply chain and demo servers: Demo handlers or forgotten example endpoints often lack authentication and are likely to be reachable in production — these are common risk vectors when libraries include example server code without proper warnings.

Safe, defensive analysis (what to look for)

When triaging you should search for patterns that typically lead to this class of vulnerability. Examples of risky server code patterns (high-level description):

• Server accepts a JSON body containing "base64" and "filename" fields.
• Server performs base64 decode and writes bytes to disk under a web-accessible path derived directly from the client-supplied filename.
• Uploads directory has PHP/CGI/other interpreters enabled or file extensions are not restricted.

Do not attempt to exploit such endpoints. Instead, use detection and remediation steps below to eliminate the risk.

Detection and indicators of compromise (IoCs)

• Unusual POST requests to endpoints that hint at demo handlers or dependencies (e.g., requests to paths that include node_modules, bower_components, demo, or similarly named files).
• Requests with JSON bodies containing a large "base64" field or suspicious filenames (for example, requests that include ".php", ".phtml", ".jsp", ".aspx").
• Newly created files in uploads or public directories with executable file extensions.
• Webserver logs showing GET requests resulting in code execution errors or uncommon server responses after file creation timestamps.

Set up log-based alerting for POST requests with large JSON base64 payloads, file creation events in webroot, or new files with executable extensions. Correlate with process activity to detect newly spawned shells or outbound connections.

Mitigation: immediate actions

• Upgrade the dependency to the patched release: update angular-base64-upload to v0.1.21 or later where the demo handler is no longer exposed in typical production builds (or where guidance is explicit).
• Temporarily disable or firewall any demo handlers, example endpoints or unintended API routes until they are audited.
• Ensure the uploads storage location is not in webroot. Store user-controlled files outside the document root and serve them through a controlled, non-executable delivery mechanism (signed URLs, object storage, or streaming endpoints that never execute content).
• Disallow execution of uploaded files: use webserver configuration to prevent execution of interpreted files in any uploads directory.
• Enforce allowed file types/whitelists and validate both filename and file content (MIME sniffing and magic bytes), not just extension or client-provided MIME type.
• Use strong random names (server-generated) and strip path traversal characters from user-supplied filenames.

Example: nginx configuration to prevent PHP execution in an uploads directory

# Place this inside your server block or in an include used for uploads directories
location /uploads/ {
    # Do not process PHP files here
    location ~ \.php$ {
        deny all;
        return 403;
    }

    # Serve static files normally
    try_files $uri =404;
}

Explanation: This nginx snippet ensures that any files under /uploads/ are treated as static content and any request attempting to access a file with a .php extension is explicitly denied. Using try_files prevents fallback to PHP handlers elsewhere in the configuration.

Secure server-side handling: recommended pattern

Below is a defensive, non-executable PHP example that demonstrates safe handling of Base64 uploads. It purposefully omits unsafe behavior (no execution of uploaded content, strict allowed extensions, storage outside webroot, and thorough validation).

 $filename]);
?>

Explanation: This code demonstrates secure handling rules: it uses a whitelist of non-executable extensions, decodes base64 with strict checking, strips any path components from the supplied filename, generates a server-controlled filename, stores the file outside of the webroot and sets conservative file permissions. The example intentionally avoids any step that would enable execution of uploaded content.

Hardening checklist for teams

• Update dependencies and enforce dependency policies: use a lockfile, pin to secure versions, and run npm audit / Snyk / OSS scanning during CI.
• Remove or secure example/demo server endpoints before deploying to production.
• Place uploads outside the document root; if storage in object storage (S3-compatible) is possible, prefer that and use signed, time-limited downloads.
• Restrict allowed file types and validate content with magic-byte checks.
• Generate server-controlled filenames and remove user-controllable path information.
• Apply the principle of least privilege on storage directories and file permissions.
• Continuously monitor logs and set alerts for large base64 uploads, new files in webroot, and requests to demo/example paths.

Testing, verification and incident response

After patching and hardening:

• Verify that uploading files with executable extensions is rejected or stored without execute permission.
• Confirm webserver will not execute files in upload storage (try to request a benign .php file in the uploads area and verify a 403 or a static download but no execution).
• Perform code and configuration reviews to ensure no forgotten demo handlers remain accessible.
• If suspicious activity is found, collect logs, preserve disk images, rotate credentials, and follow your organization’s incident response plan.

Timeline and responsible disclosure

Vulnerabilities like CVE-2024-42640 emphasize that example/demo artifacts distributed with client libraries must not be treated as production-safe code. Vendors and maintainers should clearly mark demo code and avoid providing shipping server endpoints that decode and store arbitrary client data into web-accessible, executable locations.

Further reading and resources

• OWASP: Unrestricted File Upload — secure patterns and mitigations
• Best practices for handling user-uploaded files (store outside webroot, whitelist content, enforce permissions)
• Dependency management: npm audit, Snyk, GitHub Dependabot, and SBOMs

Final notes

Do not attempt to exploit vulnerable endpoints. If you operate systems that used angular-base64-upload demos or similar server handlers, treat the presence of demo endpoints as a high-risk indicator and follow the mitigation steps above immediately: update the package, remove demo endpoints, store uploads outside webroot, and harden server configuration. Prioritize detection and containment if you suspect misuse.