CVE-2024-13708: Booster For WooCommerce XSS Vulnerability

CVE-2024-13708 Overview

CVE-2024-13708 is a Stored Cross-Site Scripting (XSS) vulnerability in the Booster for WooCommerce plugin for WordPress. The flaw affects versions 4.0.1 through 7.2.4 and stems from insufficient input sanitization and output escaping during SVG file uploads. Unauthenticated attackers can upload SVG files containing arbitrary JavaScript. The injected scripts execute in the browser context of any user who accesses the uploaded file. The underlying weakness maps to [CWE-434: Unrestricted Upload of File with Dangerous Type].

Critical Impact
Unauthenticated attackers can upload malicious SVG files that execute arbitrary JavaScript in victims' browsers, enabling session theft, account takeover, and administrative actions through the browser of authenticated users.

Affected Products

Booster for WooCommerce plugin for WordPress, versions 4.0.1 to 7.2.4
WordPress sites running the vulnerable woocommerce-jetpack package
E-commerce deployments using the Booster checkout file upload feature

Discovery Timeline

2025-04-04 - CVE-2024-13708 published to the National Vulnerability Database (NVD)
2025-04-09 - Last updated in NVD database

Technical Details for CVE-2024-13708

Vulnerability Analysis

The vulnerability resides in the checkout file upload component of the Booster for WooCommerce plugin, implemented in class-wcj-checkout-files-upload.php. The plugin accepts SVG files from unauthenticated users during checkout without enforcing strict content validation. Scalable Vector Graphics (SVG) is an XML-based format that supports embedded <script> elements and event handlers such as onload. When a victim later opens the uploaded file directly in a browser, the embedded script executes within the site's origin.

The issue is a stored XSS, meaning the malicious payload persists on the server. Any visitor or administrator who later renders the SVG triggers script execution. Authenticated victims expose their session cookies and CSRF tokens to the attacker-controlled script.

Root Cause

The root cause is twofold: missing input sanitization on uploaded SVG content and missing output escaping when the file is served. The plugin neither strips scriptable XML nodes from SVG payloads nor forces a Content-Disposition: attachment header. The upload handler also fails to restrict the MIME types accepted from unauthenticated requests on the checkout flow.

Attack Vector

An unauthenticated remote attacker crafts an SVG document containing JavaScript inside a <script> element or an event attribute such as onload. The attacker submits the file through the checkout file upload endpoint exposed by the plugin. The server stores the file in a publicly reachable location. The attacker then distributes the file URL or waits for an administrator to review the upload. When the SVG renders, the embedded script runs with the privileges of the viewing user.

No authentication or user interaction is required to plant the payload. Execution requires a victim to access the SVG, which can be triggered through ordinary admin review workflows. See the Wordfence Vulnerability Analysis and the plugin source in the WordPress Plugin Repository for additional technical context.

Detection Methods for CVE-2024-13708

Indicators of Compromise

SVG files in the WooCommerce checkout uploads directory containing <script>, onload=, onerror=, or javascript: strings
Unusual SVG uploads originating from unauthenticated checkout sessions or anonymous IP addresses
Web server access log entries requesting .svg files under plugin-managed upload paths followed by outbound calls to unfamiliar domains
New or modified WordPress administrator accounts created shortly after SVG uploads were viewed

Detection Strategies

Scan the uploads directory for SVG files and grep their contents for <script, on[a-z]+=, and javascript: patterns
Inspect WordPress audit logs for file upload events tied to the Booster for WooCommerce checkout file upload feature
Monitor HTTP responses serving SVG content for missing Content-Disposition: attachment or Content-Security-Policy headers
Alert on installed Booster for WooCommerce plugin versions between 4.0.1 and 7.2.4 reported by inventory tooling

Monitoring Recommendations

Enable WordPress activity logging for plugin file uploads and administrator session events
Forward web server logs to a SIEM and correlate SVG retrievals with subsequent admin-context actions
Track outbound network requests from administrator browsers that follow SVG access from the affected WordPress host
Periodically inventory WordPress plugin versions and flag deployments still running vulnerable Booster for WooCommerce releases

How to Mitigate CVE-2024-13708

Immediate Actions Required

Update Booster for WooCommerce to a version newer than 7.2.4 on every affected WordPress site
Audit the checkout uploads directory and remove any SVG files containing scriptable content
Reset credentials and invalidate active sessions for administrators who may have viewed attacker-supplied SVGs
Disable the checkout file upload feature in plugin settings if it is not required for business operations

Patch Information

The vendor addressed the issue in versions after 7.2.4. Apply the latest available release of Booster for WooCommerce from the WordPress plugin repository. Confirm the installed version after the update and re-run the upload directory audit to verify no residual malicious files remain.

Workarounds

Block .svg uploads at the web server or WAF layer for unauthenticated requests targeting the plugin's checkout endpoint
Serve uploaded files with the Content-Disposition: attachment header to force download rather than inline rendering
Apply a strict Content-Security-Policy that disallows inline scripts on pages and file paths that serve user-uploaded content
Restrict access to the WooCommerce checkout uploads directory using authentication or signed URLs where feasible

bash

# Example nginx configuration to force SVG downloads instead of inline rendering
location ~* /wp-content/uploads/.*\.svg$ {
    add_header Content-Disposition "attachment";
    add_header X-Content-Type-Options "nosniff";
    add_header Content-Security-Policy "default-src 'none'; script-src 'none'";
    types { } default_type application/octet-stream;
}