CVE-2024-13744 is a high severity (CVSS 8.1) arbitrary file upload in the Booster for WooCommerce plugin, in the validate_product_input_fields_on_add_to_cart function, in versions 4.0.1 to 7.2.4. It may lead to code execution. Update past 7.2.4. Check the plugin changelog and apply the update soon.
What's affected
- Booster for WooCommerce, versions 4.0.1 to 7.2.4.
The record does not name a fixed version, but it links a code changeset. Check the plugin page for a release newer than 7.2.4.
How to check if you're exposed
Run the command below from the WordPress root with WP-CLI, or check the Plugins or Themes screen in the dashboard. Check staging, development and multisite networks too.
wp plugin list --format=table | grep -i booster
Compare the version shown to the affected range above. If you manage many sites, run the same check on each one.
What to do now
- Update to a release newer than 7.2.4.
- If you do not use the product input fields module, turn it off.
- Check the uploads folder for script files and block execution there.
- Look up CVE-2024-13744 on its Gold page to see the current details and any fix information.
- Scan your sites again after changes. Our free in-browser dependency scan covers package manifests such as package.json and requirements.txt, so use it for the build tooling around your site as well.
Why it matters
This is the second upload issue in Booster published in 2025. CVE-2024-13342 covers a different function, add_files_to_order, and this one covers validate_product_input_fields_on_add_to_cart. The cause in both is missing file type validation, and the attack complexity is rated high in both.
A single update fixes both, but the pair shows why file handling code in e-commerce plugins deserves a review whenever one flaw is reported.
This CVE is an arbitrary file upload flaw (CWE-434, Unrestricted File Upload). Nothing in the record says it is exploited in the wild, and it is not marked as listed in CISA's Known Exploited Vulnerabilities catalog. That is a snapshot, so keep checking.
File upload handlers are risky because the server ends up storing something a stranger chose. If the handler does not check the file type properly, a file that the web server treats as code can end up in a web-reachable folder, and code that runs on your server is the start of a full compromise.
The usual defenses are an allowlist of file types checked on the server, renaming uploads, storing them outside the web root or with script execution turned off, and requiring authentication where possible. Double extension tricks work only on some server configurations, which is why the advisory language is conditional. The attack complexity is rated high for that reason.
Quick check
How does this differ from CVE-2024-13342?
It affects a different function and a different version range, though both are in Booster.
Is login required?
No. The record says unauthenticated attackers can exploit it.
Sources
Note: these pages could not be retrieved when this post was written, so statements rest on the CVE record text. Check the vendor pages for the latest version information.
Last reviewed: 19 October 2026.
