Site icon WebFactory Ltd

How Wordfence Locked Out My Admin Account After a Brutal Brute Force Attack and the Emergency FTP Bypass That Restored Access

When securing a WordPress installation, Wordfence often emerges as one of the top choices due to its robust firewall and malware scanning capabilities. However, like many security tools, it’s a double-edged sword. What happens when the very plugin meant to protect your website becomes the cause of an unexpected lockout? This is exactly what happened following a relentless brute force attack—and what unfolded proves to be both a cautionary tale and a guide to recovery through an emergency FTP bypass.

TLDR

After a sustained brute force attack, Wordfence mistakenly locked out the actual WordPress administrator. Without access to the dashboard, regaining control required emergency FTP access to disable the plugin temporarily. This article breaks down the steps taken, why Wordfence behaved the way it did, and how admins can avoid similar issues in the future by preparing a recovery plan.

The Onset of the Brute Force Attack

The trouble began in the early hours of a Monday morning when unusual server load and multiple failed login attempts were reported by the hosting provider. On further investigation, the site’s admin realized that a brute force attack was underway, targeting wp-login.php. Wordfence kicked in, as expected, blocking IPs rapidly and throttling login attempts.

Initially, the system worked flawlessly—hundreds of IPs were blacklisted, and notifications rolled into the admin’s inbox. However, things took an unexpected turn when the admin himself was locked out despite not having entered credentials incorrectly.

How Wordfence Lockouts Work

Wordfence uses various metrics to determine when to initiate lockouts. These include:

In this case, the admin’s IP was unfortunately caught in the broad net due to dynamic IP assignment by the ISP. The new IP landed on a blacklist by Wordfence UI behavior analytics.

“Blocked by Firewall” — So Now What?

The lockout manifested in the form of the dreaded “Your access to this site has been limited by the site owner” screen which effectively barred access to wp-admin. Attempts to recover via WordPress recovery email links failed since there were no traditional login errors—it was the firewall behind the scene doing the blocking.

The admin had no choice but to turn to FTP for a manual intervention. At this point, it became a race against time to restore administrative access without affecting the rest of the website operations or WordPress core.

Emergency FTP Bypass: Step-by-Step Recovery

Access through FTP is typically granted by your host; FileZilla or cPanel’s File Manager are useful tools for this task. Here’s the process that was followed to regain control:

  1. Access File System: Logged into FTP and navigated to wp-content/plugins.
  2. Disable Wordfence: Renamed the wordfence directory to wordfence_old. This action forces WordPress to deactivate the plugin silently.
  3. Login Again: With Wordfence disabled, the admin could now log in without hitting firewall restrictions.
  4. Review Logs and IPs: Logged into WordPress and checked the logs for IPs, timestamps, and bot behaviors.
  5. Restore Wordfence: After whitelisting the admin IP and updating Wordfence settings, the folder was renamed back and the plugin was reactivated successfully.

Why Wordfence Reacted This Way

While frustrating, Wordfence was technically doing its job. The plugin noticed suspicious activity and moved to safeguard the site, even if it meant locking out a legitimate user. The admin’s IP was either too similar to malicious traffic patterns or listed in the Threat Defense Feed.

Advanced settings such as “Immediately block fake Google crawlers” or “Participate in real-time threat defense” can sometimes cast wide nets, impacting legitimate users as well. Additionally, rate-limiting rules may unintentionally penalize shared IPs common among ISPs.

Preventive Measures for the Future

Having experienced the lockout firsthand, implementing preventive strategies became a top priority. Here are the safeguards now in place:

Lessons Learned

This event underlines the principle that security without accessibility becomes a new form of vulnerability. Wordfence did what it was built to do—but without preparation, it ended up hurting the very user it meant to protect. The solution wasn’t complex, but it required technical knowledge and calm under pressure, which could overwhelm a non-technical site owner.

Moving forward, having a well-documented recovery plan is just as important as setting up the firewall rules. Knowing what folder to rename—and when—could be the difference between prolonged downtime and minor inconvenience.

FAQs

Exit mobile version