CVE-2026-92537 in Newsletter Plugin
Summary
by MITRE • 10/01/2026
The Newsletter – Send awesome emails from WordPress plugin for WordPress is vulnerable to Insufficiently Protected Credentials in all versions up to, and including, 9.3.9 The plugin's public click-tracking REST route `/tnp/l/` is registered with `permission_callback => '__return_true'` and, upon receiving a valid keyed-MD5 signature, calls `set_user_cookie()`, which emits a `Set-Cookie: newsletter=<id>-<raw_token>` response header to the requester because the subscriber object loaded via `get_user()` lacks the `_trusted` property, causing `get_user_key()` to return the raw token column value instead of its MD5-masked variant. This makes it possible for unauthenticated attackers who obtain any signed click-tracking URL for a target subscriber to receive that subscriber's permanent raw authentication cookie, which they can then use to export the subscriber's full PII record via the JSON profile-export endpoint (`?na=px`), rewrite the subscriber's stored profile (`?na=ps`), and silently unsubscribe the subscriber via the RFC-8058 one-click endpoint (`?na=ocu`), none of which require a nonce, password, or email challenge. Signed tracking URLs are embedded in every external link of every newsletter delivered to a subscriber, carry no timestamp, and never expire until the site's relink key rotates, meaning that any party who observes such a URL — through a forwarded email, a shared inbox, a mail-gateway log, or Referer headers on the redirect target, which has no Referrer-Policy set — can replay it indefinitely to obtain the victim's credential.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/01/2026
The vulnerability in The Newsletter plugin for WordPress represents a critical failure in authentication and session management mechanisms, specifically classified under CWE-521 as Insufficiently Protected Credentials. This flaw affects all versions up to 9.3.9 and stems from an insecure implementation of the public click-tracking REST route located at `/tnp/l/`. The core issue arises because this endpoint is registered with a permission callback set to `__return_true`, effectively allowing unauthenticated access without any prior verification of user identity or authorization tokens. When a request reaches this endpoint, it validates a keyed-MD5 signature derived from the URL parameters. Upon successful validation, the plugin proceeds to call the internal function `set_user_cookie()`. This action is intended to set an authentication cookie for the identified subscriber; however, due to a logic error in how the user object is retrieved and processed, the system fails to properly mask or hash the credential before transmission.
The technical root cause lies in the interaction between `get_user()` and `get_user_key()`. When the plugin loads the subscriber object via `get_user()`, it does not correctly set the `_trusted` property on that object instance. Consequently, when `get_user_key()` is invoked to determine which key value should be used for authentication, it detects the absence of this trusted flag and defaults to returning the raw token column value from the database rather than its MD5-masked variant. This results in the emission of a Set-Cookie header containing the literal, unhashed subscriber ID and raw token as `newsletter=<id>-<raw_token>`. Because these tokens are permanent and do not expire until the site's relink key rotates, they constitute high-value credentials that provide persistent access to the victim's account. This behavior aligns with ATT&CK technique T1078, Valid Accounts, where attackers leverage legitimate credentials to maintain persistence within a system.
The operational impact of this vulnerability is severe due to the ease with which an attacker can obtain these signed tracking URLs and the lack of expiration on them. Signed tracking URLs are embedded in every external link sent via newsletters delivered by the plugin. These URLs carry no timestamp and never expire, meaning that any party who observes such a URL through common vectors like forwarded emails, shared inbox access, mail-gateway logs, or Referer headers from redirect targets can capture it indefinitely. The absence of a Referrer-Policy header on the redirect target further exacerbates this risk by allowing browser clients to send full URLs in Referer headers to third-party domains. Once an attacker possesses a valid signed URL, they can replay it at any time to obtain the victim's raw authentication cookie without needing a nonce, password, or email challenge. This effectively bypasses standard WordPress security measures that rely on nonces and session validation for sensitive operations.
With access to this permanent credential, attackers can perform several malicious actions against the targeted subscriber account. They can export the subscriber's full personally identifiable information (PII) record via the JSON profile-export endpoint using the parameter `?na=px`. Furthermore, they can rewrite the subscriber's stored profile data through the update endpoint at `?na=ps`, potentially altering contact details or preferences to facilitate further attacks or spam. Additionally, attackers can silently unsubscribe the victim from future newsletters by invoking the RFC-8058 compliant one-click unsubscribing mechanism via `?na=ocu`. These actions occur without triggering any additional verification steps, highlighting a significant gap in input validation and state management within the plugin's API endpoints. This scenario reflects aspects of ATT&CK technique T1098, Account Manipulation, as well as data exfiltration patterns described under T1530.
To mitigate this vulnerability, immediate action is required to address both the code-level flaws and broader security configurations. The most effective mitigation is upgrading The Newsletter plugin to a version where these issues have been patched by the developers. Until an update is available or if patching is not immediately feasible, administrators should consider disabling the click-tracking feature entirely if it is not strictly necessary for their operations, thereby removing the vulnerable endpoint from exposure. Additionally, implementing strict Referrer-Policy headers on all redirect targets associated with newsletter links can prevent leakage of tracking URLs via Referer headers to external domains. It is also advisable to review server-side logging and monitoring configurations to detect unusual patterns of access to REST endpoints that do not require authentication but result in cookie issuance. Regular audits of plugin code for similar permission callback misconfigurations are recommended to prevent recurrence of such insufficiently protected credential issues across the WordPress ecosystem.