CVE-2025-15380 affects NotificationX and it is an unauthenticated DOM based cross site scripting vulnerability that can execute JavaScript in a victim browser on public pages. The attack does not require a WordPress account and it does not require any special permissions. It abuses a front end preview mechanism where the plugin accepts attacker supplied configuration, decodes it, and renders it directly into the DOM. This matters because NotificationX is installed specifically to show attention grabbing UI elements like notification bars and press bars. If the preview path can be triggered by anyone, then any attacker can weaponize it to run script on the site origin and steal session data, run actions in the background, or plant further attacks through social engineering. Even a single successful execution can be enough to compromise administrators if they browse the front end while logged in.
| CVE | CVE-2025-15380 |
| Plugin Version | NotificationX <= 3.2.0 |
| All Time | 1 843 443 |
| Active installations | 40 000+ |
| Publicly Published | January 20, 2026 |
| Last Updated | January 20, 2026 |
| Researcher | Dmitrii Ignatyev |
| PoC | Yes |
| Exploit | No |
| Reference | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-15380 https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/notificationx/notificationx-320-unauthenticated-dom-based-cross-site-scripting-via-nx-preview https://t.me/cleantalk_researches/400 |
| Plugin Security Certification by CleanTalk |  |
| Logo of the plugin |  |
PSC by CleantalkJoin the community of developers who prioritize security. Highlight your plugin in the WordPress catalog.
Timeline
| December 23, 2025 | Plugin testing and vulnerability detection in the NotificationX have been completed |
| December 23, 2025 | I contacted the author of the plugin and provided a vulnerability PoC with a description and recommendations for fixing |
| January 20, 2026 | Registered CVE-2025-15380 |
Discovery of the Vulnerability
The vulnerable flow begins with the nx-preview POST parameter that is processed on public facing pages. The value is base64 encoded JSON that represents preview configuration for a press bar, including content arrays like sliding_content. The plugin decodes the payload and passes it into the front end rendering pipeline. In the client side code, fields such as sliding_content title are inserted into the DOM using a raw HTML rendering path like dangerouslySetInnerHTML. Because there is no sanitization or escaping step that guarantees the content is safe, attacker supplied markup survives into the browser as active HTML. When a payload uses an HTML element with an event handler, JavaScript can execute immediately on render. The key weakness here is not just that the input is attacker controlled. It is that the rendering is explicitly treated as HTML and the plugin trusts preview data from unauthenticated requests.
Understanding of DOM XSS attack’s
DOM based XSS is often underestimated because the server response may look harmless, and the actual execution happens only after the browser builds the DOM. In practice it is still XSS on the site origin and it enables the same outcomes as other XSS classes. On WordPress sites this can include stealing wp nonce values from admin pages opened in other tabs, issuing authenticated requests to admin AJAX endpoints, changing user emails, creating new users, or installing plugins, depending on what the victim session can access. Real world exploitation often relies on a lure page that auto submits a form to the vulnerable site, or a crafted link that forces a POST through a browser trick. Because the vulnerable trigger is a preview feature, administrators may not suspect it and may reproduce issues by visiting attacker supplied links during support investigations. This vulnerability also affects normal visitors. Even if a visitor is not logged in, an attacker can still use the site origin to run phishing overlays, steal form inputs, or redirect users, which is why front end XSS is a brand and trust risk, not only an admin compromise risk.
Exploiting the DOM XSS Vulnerability
To exploit CVE-2025-15380, an attacker without any cookies:
POC:
<html> <body> <form action="http://127.0.0.1/wordpress/" method="POST"> <input type="hidden" name="nx-preview" value="eyJzb3VyY2UiOiJwcmVzc19iYXIiLCJ0eXBlIjoibm90aWZpY2F0aW9uX2JhciIsInRoZW1lcyI6InByZXNzX2Jhcl90aGVtZS10d28iLCJwb3NpdGlvbiI6InRvcCIsImJhcl9jb250ZW50X3R5cGUiOiJzbGlkaW5nIiwic2xpZGluZ19jb250ZW50IjpbeyJ0aXRsZSI6IjxpbWcgc3JjPXggb25lcnJvcj1hbGVydCgxMzM3KT4ifV0sImJhcl90cmFuc2l0aW9uX3N0eWxlIjoic2xpZGVfcmlnaHQiLCJzbGlkaW5nX2ludGVydmFsIjozMDAwLCJiYXJfdHJhbnNpdGlvbl9zcGVlZCI6NTAwLCJhZHZhbmNlX2VkaXQiOjB9" /> <input type="submit" value="Submit request" /> </form> <script> history.pushState('', '', '/'); document.forms[0].submit(); </script> </body> </html>____
The most severe scenario is administrator session compromise. If an administrator is logged in and visits the front end, the attacker can execute JavaScript on the site origin and perform privileged actions by abusing the admin session and extracting nonces from the DOM where possible. A second scenario is widespread user targeting. Attackers can weaponize the site to deliver malicious scripts to any visitor by tricking them into visiting the attacker page that triggers the POST and renders the preview. This can be used for credential phishing overlays, payment skimmers, or traffic redirection. Because the attack is unauthenticated and does not depend on stored state, it can be executed repeatedly and at scale. The preview feature also creates a perception risk. Users may see broken or malicious looking notification bars, which damages trust and can cause support incidents even when no accounts are stolen. The fact that the payload lives in a base64 JSON blob makes it harder to spot in casual logs, which helps attackers stay quiet while still achieving full origin script execution.
Recommendations for Improved Security
The correct fix is to remove raw HTML injection from the preview rendering path and treat preview fields as plain text unless there is a very strong reason to allow HTML. If HTML must be allowed, it must be sanitized with a strict allow list that removes all event handlers and dangerous tags, and it must be applied before data reaches any sink like dangerouslySetInnerHTML. The preview endpoint should also require authentication and enforce a nonce, because preview is an administrative or builder oriented feature and should not be available to anonymous users on public pages. On the client side, replace dangerouslySetInnerHTML with safe rendering that escapes content by default, and only render whitelisted markup through a trusted sanitization library. As operational mitigations, site owners should update NotificationX to a patched version as soon as available, consider disabling the preview feature on production, and deploy a strong Content Security Policy where feasible to reduce XSS impact. Logging should be improved to capture nx preview usage, because unexpected bursts of POSTs with nx preview parameters are a strong indicator of exploitation attempts.
By taking proactive measures to address DOM XSS like CVE-2025-15380 WordPress website owners can enhance their security posture and safeguard against potential exploitation. Stay vigilant, stay secure.
#WordPressSecurity #DOMXSS #WebsiteSafety #StayProtected #HighVulnerability
Use CleanTalk solutions to improve the security of your website