The verification email you never asked for

The feature that looked fine

The plugin’s whole job was small: give a site a REST route that other code could call to send someone a verification code by email, and a second route to check whether a code submitted back matched. Neither half needed a login of its own — a visitor filling out some other form on the site, before they had an account, is exactly who a verification step exists for. Treating the route as public was the correct call.

What it needed and never got was a second, quieter check: not whether the caller was allowed to ask for a code at all, but whether the address the code was about to be sent to had anything to do with the request in front of it.

The question nobody asked

The route took one parameter: an email address. It ran no check against who was logged in, because nobody was expected to be. It ran no check against a session, a submitted form, or anything else already in progress, because the plugin does not model that concept at all. It simply took the address in the request, wrote a row for it, and told the site’s own mail function to send that address a templated verification email. There is no permission callback on the route — not a weak one, none.

So the address in the request and the person making the request never had to be the same person, and nothing checked that they were. Name a stranger’s address and the stranger gets a real email from a real site, on demand, as many times as the request is repeated — the route carries no rate limit either. The code itself was never the weak point. The weak point was that anyone could choose who received it.

How we know

A description is not a finding. The engine built an isolated WordPress instance, installed the plugin’s official 1.0.0 release untouched, hash-verified against wordpress.org’s own archive, and sent one anonymous POST naming an address — no cookie, no nonce, no account. A real email went out to it, and a new row landed in the plugin’s own database table recording the attempt. Nobody else’s site was involved at any point, and no person confirmed it by hand — RIA Labs performs no manual step, by design. What makes the finding admissible is the proof gate, which throws out a filing that has no working exploit behind it.

It went through WPScan’s coordinated disclosure process, which handled contact with the vendor. The 5.3 was scored by their analysts rather than asserted by us, and that is the only reason it is worth anything as evidence. They are a CVE Numbering Authority, so the identifier was theirs to assign. As of 18 September 2026 the registry record itself had not yet propagated, even though the advisory was already live — the identifier is real and reserved either way, and we link the advisory rather than a record that does not resolve.

Three questions for your own stack

None of this is WordPress-specific. If your product emails, texts, or otherwise notifies an address a caller supplies in a request, these are worth answering on whatever you are built on.

1. Does the route check who is asking, or only what they are asking for? “No login required” is a correct answer for plenty of routes. It stops being correct the moment the request causes an outbound message to someone else.
2. Is the recipient bound to anything, or is it a free parameter? A verification flow’s entire security model depends on the code reaching the person it is about. If the address is just another field in the request body, that model does not exist yet.
3. What stops the same request from running ten thousand times? A route with no rate limit and a free-form recipient is not only an authorization gap. It is a mail relay wearing a verification flow’s clothes.

None of that needs exotic tooling. It needs someone to ask who a field’s value actually reaches, not just whether the field is required.

What it proves, and what it doesn’t

It proves the pipeline still finds the plain cases, not only the elaborate ones: no chained mistake, no traversal, no injection — a single missing check on a route that talks to a stranger’s inbox. Plain bugs are not lesser bugs; this one turns a small utility plugin into a relay for mail nobody asked to receive.

It does not prove we would find every bug in your application, and five findings are not a track record. It also does not establish how the plugin’s vendor will respond — as of publication there is no patch, and the listing is closed pending review rather than fixed.