NotificationX CVE-2024-1698: Unauthenticated SQL Injection in a 30,000-Site WordPress Plugin (CVSS 9.8)

If your WordPress site uses NotificationX—the popular FOMO, social proof, and sales notification plugin that shows those “someone just purchased” popups and live visitor counters—there is a critical flaw you need to know about. Tracked as CVE-2024-1698, it is an unauthenticated SQL injection vulnerability that earned a CVSS score of 9.8 out of 10: about as severe as a web vulnerability gets. It affects every version of the plugin up to and including 2.8.2, and because no login is required to exploit it, any anonymous visitor on the internet can attempt to pull data straight out of your site’s database.

NotificationX is installed on more than 30,000 active WordPress sites, many of them WooCommerce stores that rely on it to build buyer confidence. That makes this flaw exactly the kind of thing opportunistic attackers scan the web for. The good news: the developer, WPDeveloper, patched it in version 2.8.3, and updating takes about a minute. Below is how it works in plain language, what an attacker could actually do, and the exact steps to check whether you are exposed and fix it.

CVE-2024-1698 at a glance

The vulnerability class is CWE-89, “Improper Neutralization of Special Elements used in an SQL Command”—in plain terms, the plugin trusted user input it should have treated as dangerous. CVE-2024-1698 also carries a very high EPSS score (upper 70th percentile), meaning security models rate it as highly likely to be exploited in the wild.

How the vulnerability works

To display social-proof popups, NotificationX needs to know how notifications are performing—how many people saw one, how many clicked. It collects that data through a public REST API endpoint, /wp-json/notificationx/v1/analytics. Because the tracking has to happen in a normal visitor’s browser, that endpoint is intentionally open to everyone. No login, no permission check.

The problem is what the plugin did with one of the values that endpoint accepts. When a request came in, the type parameter was taken from the request and dropped directly into a database (SQL) query without being properly escaped or bound through a prepared statement. A database cannot tell the difference between the data you meant to send and instructions an attacker smuggled in—it simply runs whatever it receives. So instead of sending a harmless value in type, an attacker sends a fragment of SQL, and the database dutifully executes it as part of the original query. That is SQL injection.

This particular flaw is a blind SQL injection, which means the vulnerable page does not print the query results back to the attacker. Attackers get around that using time-based techniques: they craft a query that tells the database “pause for a few seconds if the first character of the admin password hash is an a.” By measuring how long the response takes, they read protected data one character at a time—slow, but fully automatable with off-the-shelf tools such as sqlmap. To pull it off, an attacker needs nothing more than the URL of a vulnerable site: no account, no stolen credentials, and no action from any of your users.

Real-world impact

Your WordPress database is the crown jewels. It holds every user account, every password hash, secret authentication keys, and—on a WooCommerce store—customer records and order history. An unauthenticated SQL injection is a direct line to all of it. With CVE-2024-1698, a remote attacker could:

• Dump the wp_users table to harvest usernames and password hashes, then crack weak hashes offline to log in as an administrator.
• Steal secret keys, session tokens, and API credentials stored in the wp_options table—potentially reaching connected services like payment gateways or email providers.
• Extract customer names, email addresses, and order details, turning the flaw into a reportable data breach with GDPR and PCI implications for online stores.
• Use recovered admin access to plant backdoors, inject spam or malicious redirects, or install a credit-card skimmer—often without any obvious sign to visitors.

Because exploitation requires no authentication and can be fully scripted, flaws like this are mass-scanned within days of disclosure. Attackers do not target you specifically—they spray requests across thousands of sites and let tooling find the unpatched ones.

How to check if you’re affected

• Look for the plugin. In your dashboard, go to Plugins → Installed Plugins and search for “NotificationX.” It also adds its own NotificationX item to the admin sidebar menu.
• Check the version. The version number is listed right under the plugin name on the Plugins screen. If it is 2.8.2 or lower, you are vulnerable. Version 2.8.3 and everything after it (the current release is in the 3.x series) contains the fix.
• Review your logs. If you keep server access logs, search for POST requests to /wp-json/notificationx/v1/analytics. Requests containing SQL keywords such as SLEEP, SELECT, UNION, or AND( in the body—or unusually slow responses to that path—can indicate attempted exploitation.

How to fix it

The fix is simple and should be done immediately.

• Update NotificationX now. Go to Dashboard → Plugins, find NotificationX, and click Update. Any version 2.8.3 or newer is patched; updating to the latest release is best. While you are there, turn on auto-updates for this plugin so you are covered next time.
• Can’t update right away? Deactivate and remove the plugin until you can, or put a web application firewall (WAF) in front of your site. Services such as Wordfence and Patchstack shipped virtual patches that block exploit attempts against this endpoint.

If your site was running a vulnerable version while publicly reachable, treat it as a possible breach and harden accordingly:

• Change all administrator passwords, and rotate the authentication keys and salts in wp-config.php to force every session to log out.
• Review your user list for accounts you do not recognize, especially administrators.
• Rotate any API keys or third-party credentials stored in the database.
• Scan the site with a reputable malware scanner and, if you find signs of compromise, restore from a known-clean backup.
• Going forward, make sure your database user has only the privileges it needs, and keep regular off-site backups.

The takeaway

CVE-2024-1698 is a textbook reminder that the most dangerous vulnerabilities often hide behind the most ordinary features. A popup that shows recent sales does not sound like an attack surface, but the public endpoint it relies on became a doorway straight into the database because a single piece of user input was not sanitized. The lesson is familiar: keep plugins updated (auto-updates are your friend), run fewer plugins from trusted developers, use a web application firewall, and monitor for unusual requests. WPDeveloper did their part by patching quickly in 2.8.3—the only sites still at risk today are the ones that never clicked “Update.” Don’t let yours be one of them.

Sources: National Vulnerability Database (CVE-2024-1698), GitHub Advisory Database (GHSA-jfg4-396j-6xjx), Wordfence Threat Intelligence, and Patchstack.