I Shut down a Targeted Magic link login Vulnerability

What Happened

A routine server monitoring flagged unusual login activity on a dormant staging site, hundreds of requests in short bursts, targeting a single account, sustained over several days.

The Paws For Support project had wrapped some time earlier. Ongoing maintenance had transitioned to a local specialist, which made sense for the client’s day-to-day needs. The staging environment had been left active on the server pending confirmation it was no longer needed, standard practice until a client or their team signs off on removal.

No active work. No recent logins. No reason anyone would have been looking.

That’s exactly when these things get missed.

What I Found

The first step was stopping the noise, HTTP authentication added to the staging domain, bot traffic stopped immediately.

The second step was understanding why that specific account was being targeted.

WordPress automatically generates a public username slug from the email address used during account setup. In this case, name.surname@gmail.com had become the publicly visible username name.surname exposed at the site’s default REST API endpoint:

/wp-json/wp/v2/users

Every other user account on the site had been set up with anonymised credentials. Randomised slugs like huio_89i7 were specifically used to prevent this kind of exposure. Those accounts appeared in the same API response and required no further action. The one account that stood out was the anomaly, not the norm.

The bots hadn’t guessed the email address. They had scraped it directly from WordPress’s default public API, then used it to reconstruct a valid login target and hammer the magic link endpoint repeatedly.

This isn’t a rookie configuration mistake. It’s a WordPress default behaviour that most developers never think to lock down, and most site owners would have no reason to know exists.

One additional detail worth noting: the Site Admin email address listed in WordPress Settings had no corresponding user account. The account appears to have been added during the original build and removed during the handover transition. The email address persisted in settings but the user no longer existed. In this case that turned out to be an accidental safeguard. There was no valid account to compromise. But that’s luck, not a security strategy.

Three Vulnerabilities Worth Understanding

What I Flagged for the Live Site

Once the staging site was secured, I shared the full findings with the client and their current designer, along with a checklist for their live domain:

• Is /wp-json/wp/v2/users publicly accessible?
• Are any username slugs derived from email addresses?
• Is the magic link login endpoint rate limited or otherwise protected?
• Does the Site Admin email in Settings > General point to an active, secured account?
• Are staging and production credentials fully separated?

Acting on their live site wasn’t my place, that’s their designer’s domain now, and that’s the right way to work. My role was to catch it, document it clearly, and make sure the right people had what they needed to act.