Manually Recovery Client Broken Site 7 Hour Turn Around
A client’s site broke right after a major event and…
Catching a WordPress Vulnerability on Staging Site & Protected clients Live Domain
A Paws For Support – Hosting & Security
Companion to: Organic SEO Matches Paid Ad Traffic – Paws For Support
What Happened
Today 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.
The Bigger Picture
If you’ve read the full Paws For Support case study, you’ll know the foundations were built to last. That hasn’t changed.
Twelve months on, the site is still compounding. Currently tracking 1.22k clicks per 28 days and closing in on the 1.5k milestone, up from the 500 clicks/month recorded when the original case study closed. The SEO work done in mid-2025 is still generating organic traffic.
The handover went smoothly, with a local designer now handling day-to-day updates. Everything was documented when access was handed over, so this was easy to come back and assist within the scope of my managed hosting role. The infrastructure still holds, the server remains monitored, and the client continues to be supported where it counts.
