Skip to main content
Vulnerability Database/CVE-2026-110721

CVE-2026-110721: NotificationX WordPress Auth Bypass Flaw

CVE-2026-110721 is an authentication bypass flaw in NotificationX WordPress plugin that enables unauthenticated attackers to inject arbitrary content into notification campaigns. This article covers technical details, affected versions, security impact, and mitigation strategies.

Published:

CVE-2026-110721 Overview

CVE-2026-110721 affects the NotificationX plugin for WordPress in all versions up to and including 3.3.3. The vulnerability is a Missing Authorization flaw [CWE-862] in the /notificationx/v1/popup-submit REST route. The route is registered with permission_callback => '__return_true', allowing unauthenticated requests. The handler PopupNotification::handle_popup_submission() accepts an attacker-controlled nx_id and copies the referenced campaign's source into a new entry without validating that the campaign is a Popup Notification or Exit Intent Popup. Attackers can inject forged social-proof entries into any enabled non-popup NotificationX campaign, including WP Comments, WooCommerce, Easy Digital Downloads, Give sales, and review notifications.

Critical Impact

Unauthenticated attackers can inject arbitrary name, title, message, email, and theme content into legitimate NotificationX campaigns displayed to site visitors, enabling convincing social-proof fraud and brand abuse.

Affected Products

  • NotificationX plugin for WordPress
  • All versions up to and including 3.3.3
  • Sites running any enabled non-popup NotificationX campaign (WP Comments, WooCommerce, EDD, Give, reviews)

Discovery Timeline

  • 2026-10-16 - CVE-2026-110721 published to NVD
  • 2026-10-16 - Last updated in NVD database

Technical Details for CVE-2026-110721

Vulnerability Analysis

The NotificationX plugin registers the /notificationx/v1/popup-submit REST endpoint without any authorization check. The permission_callback is set to __return_true, meaning WordPress accepts any request regardless of authentication state or capability. The downstream handler PopupNotification::handle_popup_submission() trusts an attacker-supplied nx_id parameter and loads the matching NotificationX campaign record. It then copies the campaign's source configuration into a new entry and persists it as a stored notification.

The handler never verifies that the referenced campaign type is popup or exit_intent, the two sources the endpoint is intended to serve. As a result, the stored entry attaches to whatever campaign the attacker references, including campaigns that render on product pages, blog posts, or checkout flows. Site visitors then see forged social-proof notifications claiming fake purchases, comments, reviews, or sign-ups.

Root Cause

Two defects combine to produce the vulnerability. First, the REST route lacks an authorization gate because permission_callback returns true unconditionally. Second, the submission handler performs no server-side validation on the campaign type associated with nx_id. Review the vendor source for context in Popup REST registration and handle_popup_submission.

Attack Vector

An unauthenticated remote attacker sends a crafted POST request to /wp-json/notificationx/v1/popup-submit with an nx_id referencing a non-popup campaign and attacker-chosen name, title, message, email, and theme fields. The plugin stores the entry and renders it to end users as if it were an authentic social-proof event. Repeated submissions can flood a site with fraudulent notifications. See the Wordfence vulnerability analysis and the fix in changeset 3746251.

No verified public exploit code is available. Technical details are described in prose only.

Detect Identity Attacks the Moment Authentication Fails

Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.

Stop Identity Attacks

Detection Methods for CVE-2026-110721

Indicators of Compromise

  • POST requests to /wp-json/notificationx/v1/popup-submit from unauthenticated clients or unusual IP addresses.
  • NotificationX entries with sender names, emails, or messages that do not correspond to real customers, comments, or orders.
  • Social-proof notifications appearing on campaigns that were not configured to accept user-submitted content.
  • Spikes in notification volume on WooCommerce, EDD, Give, review, or WP Comments campaigns.

Detection Strategies

  • Review web server and WordPress REST logs for anonymous requests targeting the popup-submit route.
  • Query the NotificationX entries table and correlate stored entries against legitimate order, comment, or review records.
  • Alert on requests to wp-json/notificationx/v1/* endpoints that lack a valid authenticated session cookie or nonce.

Monitoring Recommendations

  • Add web application firewall rules to log and rate-limit requests to the popup-submit endpoint.
  • Monitor WordPress plugin inventories for NotificationX versions at or below 3.3.3.
  • Track outbound notification content for keywords associated with scams, spam, or brand impersonation.

How to Mitigate CVE-2026-110721

Immediate Actions Required

  • Update the NotificationX plugin to the patched version released after 3.3.3 as published in changeset 3746251.
  • Audit all existing NotificationX entries and remove any forged or unverified social-proof records.
  • Review NotificationX campaigns and disable any that are not actively required.

Patch Information

The vendor addressed the vulnerability in a release following 3.3.3. The fix adds a campaign-type check in handle_popup_submission() so only Popup Notification and Exit Intent Popup sources accept submissions through the REST route. Site administrators should apply the update through the WordPress plugin manager or by deploying the vendor-supplied package.

Workarounds

  • Block or restrict access to /wp-json/notificationx/v1/popup-submit at the web server or WAF layer until the patch is applied.
  • Temporarily deactivate the NotificationX plugin on sites that cannot update immediately.
  • Restrict REST API access to authenticated users where feasible using an access-control plugin or server-level rules.
bash
# Example nginx rule to block anonymous access to the vulnerable REST route
location = /wp-json/notificationx/v1/popup-submit {
    deny all;
    return 403;
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.