The password you never needed

The feature that looked fine

The plugin’s actual job was automation. Passwordless login was bolted on late, by people who knew their own product well and auth flows less well — and that is the part worth taking away, because the interesting bugs are rarely in the code someone labelled security-critical.

A magic link is a simple contract. You give an email address, the server mints a one-time token and emails you a URL containing it, and clicking that URL signs you in. Two steps, one secret, delivered over a channel the attacker does not control. If the secret only ever travels by email then nobody completes the second step without reading your inbox, and that is the entire security model.

Two small mistakes, chained

Neither half is exotic, which is exactly why it is worth writing about. First: the response to “send me a link” carried the token back to whoever asked for it. The email still went out, correctly — the secret was simply also handed to the caller in the reply. At that point the out-of-band half of the model has quietly stopped existing, because the secret now travels over a channel the attacker does control.

The second turned up while building the proof. Verifying a token and acting on that verification were wired to the same lifecycle event, at different priorities, in one file. Read separately, each is reasonable. Read as a pair, they collapse a two-step confirmation into one step: a single request that merely presents a token both marks it verified and completes the sign-in, before any response is sent. There was never a second step to skip. It had already folded into the first.

Either mistake might have been caught in review. Together, in a feature nobody was treating as sensitive, they were not — and what came out needed nothing but an email address, which is usually on the contact page.

How we know

A description is not a finding. Nothing here was reported on the strength of reading code: the engine built an isolated WordPress instance, installed the plugin’s official release untouched, and ran the chain against that. 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 code behind it.

It also ran the negative control a claim like this needs: a fabricated token authenticates nobody. That is what separates a real authentication bypass from a misconfigured test environment, and it is the step most often skipped.

It went through Wordfence’s coordinated disclosure process, which handled contact with the vendor. The 9.8 was scored by their analysts rather than asserted by us, and that is the only reason it is worth anything as evidence.

Three questions for your own stack

None of this is WordPress-specific. If your product has any token-based passwordless flow — magic links, one-time codes, “email me a link” — these are worth answering on whatever you are built on.

1. Does any response ever contain the token? Check every return path of the request endpoint, not the happy one. Debug branches and error responses are where it leaks.
2. Can verifying a token and using it happen in the same request? If your framework has events or hooks, list every listener on the ones your auth flow touches, not only the ones you wrote.
3. Can the two-step flow be driven end to end by one automated request? If it can, even though the design says it should not, that is your answer. It was here.

None of that needs exotic tooling. It needs someone to read the code that shipped rather than the code you remember writing.

What it proves, and what it doesn’t

It proves the pipeline works end to end on code nobody prepared for us. The engine read the source, found a shape worth pulling, built the target, ran the chain, and a third party with no stake in our marketing scored it and put our name on it. Until this, every claim on this site described what the software does. This one is an artefact you can check without asking us anything.

It does not prove we would find every bug in your application, and one finding is not a track record. A plugin nobody was maintaining is an easier read than a product with a security team and a decade of hardening.