Newsletter Plugin CVE-2026-92537: Subscriber Token Leak, Patch

A medium severity label is doing a lot of hiding here. Newsletter, one of the most widely installed email plugins for WordPress with more than 200,000 active sites, shipped version 9.4.0 on October 1 to close CVE-2026-92537. The flaw lets anyone who holds a single click-tracking link from a sent newsletter pull back that subscriber's raw login cookie, with no account and no password. If you run the plugin, update first and read the rest second, because the links that trigger this went out in email long before the fix landed.

What the flaw does

The plugin exposes a public click-tracking route under its REST interface, the endpoint that records when a subscriber clicks a link in one of your emails. According to the Wordfence advisory that assigned the CVE, that route carries no permission check, so it answers unauthenticated requests. Given a validly signed tracking link, it sets a login cookie for the matching subscriber. The bug is that the subscriber object is not marked trusted, so the plugin returns the subscriber's raw authentication token instead of the hashed version. The response hands the caller a working newsletter cookie for that person.

With that cookie, the advisory notes, an attacker reaches the subscriber-facing endpoints that take no further check: a JSON export of the subscriber's full stored profile, a profile rewrite, and a one-click unsubscribe. None of them ask for a password, a nonce, or an email confirmation. A leaked tracking link becomes a readable copy of whatever personal data your signup forms collect.

Who is exposed

Every site running Newsletter 9.3.9 or earlier is affected, and the exposure is not theoretical. The signed tracking links sit inside every external link of every newsletter you have sent. The advisory states they carry no timestamp and stay valid until the site's relink key changes, the secret the plugin uses to sign them. So a usable link can be read from a forwarded email, a shared team inbox, a mail gateway's logs, or the Referer header sent to whatever page the link redirects to, since the redirect carries no referrer policy. Anyone who sees one of those links can replay it.

Why the 5.3 understates the risk

Wordfence scored this a 5.3, a medium, and the vector weights it on integrity rather than confidentiality. For a defender, that framing is misleading. The documented outcome is an unauthenticated export of a named person's stored personal data. If you operate in the EU or handle subscriber data under similar rules, an open path to pull personally identifiable information is a data exposure question, not something you schedule for next quarter. This is the third WordPress email or credential plugin issue we have covered in recent weeks, after the Gravity SMTP credential leak and the Mailgun for WordPress account takeover. The pattern holds: mail plugins keep both subscriber records and sending credentials, and convenience endpoints keep handing them out.

Hunt your access logs for tracking-link replay

There is no tidy indicator of compromise for this, because a replayed tracking link looks almost like a normal click. The tell is volume and spread: one source requesting the tracking route across many different subscriber identifiers, or unauthenticated requests landing straight on the profile export and rewrite endpoints. Pull those from your web server logs before you assume you were untouched. Centralizing those logs is the kind of visibility a managed log pipeline is meant to give you.

# one source, the tracking route, many subscriber ids
grep "/tnp/l/" access.log | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head
# unauthenticated profile export, rewrite, or unsubscribe
grep -E "na=(px|ps|ocu)" access.log

Update to 9.4.0, then rotate the relink key

The first action is the update: move to 9.4.0 or later from the WordPress plugins screen. The current release at the time of writing is 9.4.5. Patching closes the endpoint, but it does not retire the links you already mailed. Because those stay valid until the relink key changes, regenerate that key after updating so the tracking links already sitting in inboxes stop resolving to anyone's cookie. From there, knowing whether a vulnerable version was reachable across your fleet in the first place is a vulnerability detection problem worth owning rather than guessing at.