CVE-2026-87762 in Adwised Web Push Notification Plugin
Summary
by MITRE • 10/11/2026
The Adwised Web Push Notification WordPress plugin through 2.5.7 does not have authorisation checks on several state-changing operations, and the secret comparison it uses instead can be bypassed on installations where the secret key has never been set, allowing unauthenticated users to store arbitrary JavaScript that is executed in the browser of every site visitor.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified within Adwised Web Push Notification WordPress plugin versions up through 2.5.7 represents a critical failure in access control and input validation mechanisms. This flaw stems from an absence of proper authorization checks on several state-changing operations, which are endpoints or functions designed to modify the application's data or configuration. In secure software architecture, any operation that alters server-side state must verify that the requesting user possesses the necessary privileges to perform such actions. The lack of these checks allows unauthenticated actors to interact with sensitive administrative functionalities without providing valid credentials, effectively bypassing the intended security boundaries of the WordPress environment.
The core technical flaw lies in the method used for authentication verification within specific plugin functions. Instead of relying on standard session tokens or nonce-based validation that ties requests to authenticated user sessions, the plugin employs a secret key comparison mechanism. This approach is fundamentally flawed because it assumes the existence and integrity of a pre-configured secret string. When this secret key has never been set by an administrator during installation or configuration, the conditional logic governing access control fails in a predictable manner. Specifically, if the stored secret is empty or null, certain implementations may default to allowing access rather than denying it, creating a logical bypass that permits unauthenticated execution of privileged code paths.
This architectural weakness directly facilitates Stored Cross-Site Scripting attacks against all visitors of websites running the affected plugin version. Because the authorization check can be circumvented when no secret key is configured, an attacker can submit arbitrary JavaScript payloads through exposed endpoints without needing to log in as a WordPress administrator or subscriber. Once submitted, this malicious script is persisted within the database associated with the web push notification service. Consequently, whenever any user visits the compromised website and interacts with elements that trigger these notifications, their browser executes the injected code locally. This results in the compromise of client-side security for every visitor, enabling session hijacking, credential theft via keylogging, defacement, or redirection to malicious phishing sites.
From a classification perspective, this vulnerability aligns closely with CWE-287 Improper Authentication and CWE-434 Unrestricted Upload of File with Dangerous Type if the payload involves file storage mechanisms, though it is primarily characterized by CWE-601 URL Redirection to Untrusted Site or CWE-79 Cross-site Scripting. The attack vector corresponds to ATT&CK technique T1189 Drive-by Compromise and potentially T1505 Server Software Component for persistence if the script remains active over time. The impact is severe as it affects all users regardless of their relationship with the site, turning a standard informational website into an attacker-controlled distribution point for malicious scripts without any prior authentication requirement from the adversary.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Administrators should immediately update the Adwised Web Push Notification plugin to version 2.5.8 or later where these authorization checks have been properly implemented using standard WordPress nonces and capability verification functions like current_user_can. For sites that cannot be updated instantly, temporary mitigations include disabling web push notifications entirely if not required for business operations, which removes the attack surface associated with this specific functionality. Additionally, implementing a Web Application Firewall can help detect and block requests attempting to exploit these unauthenticated endpoints by analyzing request patterns typical of automated exploitation tools.
Long-term resilience requires enforcing strict input validation on all user-supplied data destined for storage or execution contexts. Developers must ensure that state-changing operations always verify the authenticated identity and privilege level of the requester before proceeding with any database modifications or configuration changes. Relying solely on static secret keys is insufficient for modern web applications; instead, dynamic tokens tied to active sessions provide a robust defense against unauthorized access attempts. Security audits should routinely test edge cases where optional security features are left in their default unconfigured state to ensure that the system defaults to a secure deny-by-default posture rather than an insecure allow-by-default behavior when configuration data is missing.