CVE-2024-13321 is a high severity (CVSS 7.5) SQL injection in the AnalyticsWP plugin for WordPress, through the custom_sql parameter, in versions up to and including 2.0.0. Unauthenticated attackers can extract data from the database. Update past 2.0.0 or remove the plugin.
What's affected
- AnalyticsWP, all versions up to and including 2.0.0.
- The injectable value is the custom_sql parameter, handled by handle_get_stats().
The record does not name a fixed version. Check the plugin page and changelog for a release newer than the last affected version before relying on an update.
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 analytics
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 AnalyticsWP and confirm the version is above 2.0.0.
- If no fix is available for you, deactivate the plugin and use another analytics method.
- Review whether analytics data or other tables hold personal data that should be treated as exposed.
- Look up CVE-2024-13321 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
The record blames insufficient authorization checks on the handle_get_stats() function, which accepts a parameter named custom_sql. A feature that takes raw SQL from a request is only safe if it is locked behind strict authorization, and here that lock was missing. The result is that outsiders can add their own queries to the existing one.
The design lesson is to never accept SQL fragments from the browser. Pass a metric name or an ID and let the server build the query.
This CVE is an SQL injection flaw (CWE-89, SQL Injection). 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.
SQL injection happens when user input is placed into a database query as if it were part of the query itself. The database cannot tell which parts were written by the developer and which were supplied by a visitor, so it runs both.
The standard cure is prepared statements with bound parameters, plus escaping and validation as a second layer. The record points at missing escaping and missing query preparation, which is the usual pattern. Here the confidentiality impact is high and integrity and availability are not affected in the CVSS vector, so the main concern is data leaving the database: user records, order data and stored secrets.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
What is the root cause?
Insufficient authorization checks on handle_get_stats(), which takes a custom_sql parameter.
Is the impact read or write?
The vector shows high confidentiality impact only.
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.
