Webdev and Tech
I Shut down a Targeted Magic link login Vulnerability
Routine server monitoring uncovered a targeted brute force attack on a dormant staging site, exploiting WordPress’s default API exposure of user email addresses. An attacker scraped public credentials and repeatedly targeted the magic link login endpoint before being stopped with HTTP authentication, revealing critical vulnerabilities in credential anonymisation and environment security practices.
Updated 20 October 2026
5 min read
In this article
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/usersEvery 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
Magic link endpoints are high-value targets.
A magic link login URL is more attractive to attackers than standard wp-login.php because it bypasses password authentication entirely. Properly anonymised usernames neutralise this risk regardless of which login plugin is in use, the attacker can’t target what they can’t identify.
A ghost leak is still a vulnerability.
Even without a live user account, the email address was visible in the REST API response. Partial exposure is still exposure. The only thing preventing a successful login attempt was the absence of a valid account on the other end, not any deliberate security measure.
Staging sites are attack practice ranges.
Staging environments are typically configured with relaxed security to make development easier to work in. If credentials are shared between staging and production, an attacker can run brute force attempts on staging without triggering the lockouts and rate limiting protecting the live site, then use those credentials to walk straight into the primary domain undetected. Keeping credentials separated across environments isn’t optional, it’s foundational.
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/userspublicly 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.
Written by
Vanessa Wood
Creator of the ALTC Framework and AI-Ready SEO Strategist at Brighter Websites.
Stay in the loop
Get New Articles by Email
Occasional emails from Vanessa about AI search, SEO and website marketing for regional service businesses. No spam, unsubscribe any time.
Or get in touch directly