- CVE-2026-75962 affects Post SMTP for WordPress up to version 4.0.1, scored 7.2 by Wordfence on the NVD record.
- A rejected email address was saved verbatim in the email log, allowing stored scripts on Multisite sites with public registration.
- Check for Multisite with open registration, confirm the plugin version and fixed release, and review what else logs raw input.
Testing often focuses on what happens when something works. This vulnerability lives in what happens when something fails. A WordPress email plugin rejected a bad address, then wrote that same address into its log exactly as received. The log became the delivery route for an attack.
The record is CVE-2026-75962, published by NIST's National Vulnerability Database on October 6, 2026. It covers the Post SMTP plugin for WordPress, which handles email delivery and keeps email logs.
What the record says
The NVD describes a stored cross-site scripting flaw. In plain terms, an attacker plants a script in a place where the site saves it. The script then runs in the browser of whoever opens a page that shows it.
The entry points to the 'user_email' parameter. Every release through 4.0.1 is covered. The stated cause is that the plugin neither sanitises what comes in nor escapes what it displays. Attackers need no login. That applies to WordPress Multisite installations with public registration enabled.
How two checks create the gap
The mechanism is a disagreement between two gatekeepers. WordPress accepts email addresses that contain numeric HTML character references. These are codes that a browser turns into visible characters. Post SMTP's own validator is stricter and rejects such addresses.
A rejection should end the story. Here it did not. When the send failed, the plugin raised an exception, and the exception message contained the address. According to the NVD, that message carried the attacker-controlled address verbatim into the email log.
Think of two border guards with different rulebooks. The first waves a traveller through. The second turns the traveller away, but copies the name onto a noticeboard that others later read, without checking it. The risk sits in the noticeboard, not in the turn-away.
Why the failure path matters
This is the lesson for leaders. Teams tend to treat logs as internal, trusted records. A log is only as trusted as the data written into it. When a system logs an error, it often logs the input that caused the error. That input came from outside.
Rejection also gives a false sense of safety. The validator did its job and said no. The weakness was that the rejected value was still stored and later shown without being made safe.
The vector adds to the concern. It rates the scope as changed, meaning the impact can reach beyond the plugin itself. It lists no privileges required and no user interaction. The description does say the script runs when a user accesses an injected page. The NVD entry does not say which users view those pages.
What the record does not tell us
The NVD entry does not report any exploitation in the wild. It does not say how many sites run affected versions. The exposure also depends on configuration: Multisite with public registration. A standard single-site WordPress install is not the case the record describes.
The references include a code comparison between plugin versions 4.0.1 and 4.0.2. The record does not state a fixed version in its description. Confirm the fixed release in the plugin's own changelog.
Questions to put to your team
First, do we run WordPress Multisite with public registration, and is Post SMTP installed on any of those networks? Second, which version is it, and has it moved past 4.0.1? Third, does the business need open registration, or can it be limited?
Fourth, who can open the email log screens, and what could a script run by that user reach? Fifth, which other plugins write failed input into logs or admin screens? Ask for that review, not only a patch.
A validator that says no is only half a defence. The other half is what the system does with the thing it just refused.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
