iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Stop a wp-login.php POST flood with layered controls: measure the traffic, rate-limit the endpoint at your CDN or WAF, add a server-level limit, then use WordPress account protections. Edge filtering is the priority because it rejects abusive requests before they consume origin CPU, PHP workers, database connections, or memory. Keep exceptions for legitimate administrators, SSO, Jetpack, and mobile clients, and handle xmlrpc.php as a separate decision.
A login flood is both an authentication attack and a resource-exhaustion attack. Bots may submit guessed passwords, send intentionally failing requests to consume resources, or distribute traffic across many addresses to evade a single-IP rule. A successful defense therefore combines traffic controls with 2FA or passkeys, unique passwords, monitoring, and an incident-recovery plan.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →
What a wp-login.php POST flood is
wp-login.php is the WordPress login handler in the site root. During a brute-force attack, automated clients repeatedly send HTTP POST requests containing candidate usernames and passwords. Every request can invoke web-server processing, PHP execution, WordPress bootstrap code, database queries, logging, and plugin hooks, even when authentication fails.
The visible symptom may be a slow dashboard, exhausted PHP-FPM workers, high database load, a full log partition, or a large number of 401-, 403-, or 200-level responses. A flood can continue after the attacker has stopped guessing because the objective may be to exhaust capacity rather than immediately take over an account.
#1 Best Overall
Why blocking one IP is rarely enough
Attackers commonly rotate addresses through botnets or proxies. A permanent one-address blocklist therefore has limited value and can create maintenance work. Temporary bans, request-rate limits, and behavior-based challenges are more adaptable. Rules should target the login path and method instead of blocking an entire country or hosting provider unless you have a documented business reason.
Why XML-RPC must be assessed separately
/xmlrpc.php is a different endpoint. Some sites do not need it and can disable it; others require it for Jetpack or mobile workflows. It can also receive password-guessing and amplification traffic. Measure it independently, then disable, restrict, or rate-limit it without accidentally breaking a required integration.
Recommended Free Tools
Measure the attack before changing rules
Start with evidence from the CDN, reverse proxy, web server, and WordPress security logs. Preserve a copy of relevant logs before rotating or deleting them. You need to know whether the traffic is truly a flood, which clients are legitimate, and where enforcement can occur safely.
Collect these fields
- Request method and exact path, distinguishing
POST /wp-login.phpfrom normal page views andPOST /xmlrpc.php. - Timestamp in a consistent timezone, preferably with a request ID that lets you correlate CDN and origin records.
- Source address as seen by the edge and by the origin, plus country or autonomous-system data when available.
- Response status, response size, request duration, and whether the request reached PHP.
- Host header, user agent, TLS or HTTP version, and any authenticated session or integration marker.
- Username or account identifier only where your privacy policy and log configuration permit it; avoid storing passwords.
Separate legitimate clients
List the administrators, SSO provider addresses, monitoring systems, Jetpack connections, and mobile applications that legitimately use the endpoint. Do not assume that every successful login originates from a fixed address: remote administrators and mobile users often change networks. Prefer a narrowly scoped exception based on a trusted identity, network, or integration token where your edge product supports it.
Alert on a baseline deviation
Record normal login volume by minute and hour. Alert when request count, failed-login count, origin CPU, PHP-FPM queue length, or database latency moves materially above that baseline. A single threshold that is safe for a small site may be too low for a busy membership site, so tune limits from observed legitimate traffic rather than copying a universal number.
Rate-limit at the edge first
Configure the CDN or WAF to match the exact hostname, the POST method, and the /wp-login.php path. Count requests over a rolling window and challenge or block clients that exceed the limit. If your WAF can count failed responses, a rule based on repeated 401 or 403 responses can focus mitigation on credential guessing while allowing occasional successful administration.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Cloudflare rule design
In Cloudflare, create a rate-limiting rule for the login host and path rather than a site-wide rule. A representative filter is:
(http.host eq "example.com" and http.request.method eq "POST" and http.request.uri.path eq "/wp-login.php")Replace the host with your real hostname and select a request-count threshold and period after reviewing your baseline. Choose the action—managed challenge, block, or a progressively stricter response—according to how confidently you can identify abuse. Check the current Cloudflare plan because rate-limiting features, counting options, and action types vary by plan.
Keep an exception strategy
Place narrowly defined exceptions before the blocking action for approved SSO, Jetpack, or mobile traffic. Avoid a permanent “allow all” rule for an office range that changes frequently. Test the rule in logging or simulated mode first, then verify that an administrator can sign in, log out, reset a password, and use the required integration.
Use the edge to protect origin capacity
When the edge rejects a request, it does not consume an origin PHP worker or run the WordPress bootstrap. This is the main reason edge enforcement should precede plugin-only controls. Continue collecting sampled logs and metrics so you can tell whether the rule is reducing origin load rather than merely hiding the requests from an application log.
Add a server-level control
Server controls are useful when traffic reaches the origin directly, when the CDN is unavailable, or when you need a second independent limit. Apply them only to the login endpoint and account for reverse-proxy headers correctly.
Nginx
Define a dedicated shared zone in the http context, then apply it only to an exact login location:
limit_req_zone $binary_remote_addr zone=wp_login:10m rate=10r/m;
server {
location = /wp-login.php {
limit_req zone=wp_login burst=5 nodelay;
include fastcgi_params;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
}The rate and burst values above are illustrative starting values, not a universal recommendation. Compare them with measured administrator and integration traffic, then adjust. A burst lets a legitimate client submit a short sequence without immediately failing, while nodelay rejects excess requests instead of queuing them. If your deployment uses a different PHP upstream or includes file, retain the existing values and add only the limit directives.
When Nginx sits behind a trusted proxy, configure the real-IP module with the proxy provider’s published address ranges before using the client address as the key. Otherwise every request may appear to come from the proxy, causing one shared limit and accidental lockouts.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteApache and ModSecurity
Apache deployments can use ModSecurity with the OWASP Core Rule Set or a narrow access rule to detect repeated login failures. Keep the rule specific to POST /wp-login.php, log the reason for a denial, and test it against password resets and SSO callbacks. A broad rewrite or deny rule can block static assets, front-end forms, or unrelated API calls.
Fail2ban-style temporary bans
Fail2ban can read authentication or web-server logs and impose a temporary firewall ban after repeated failures. Set the ban duration and retry window so that an address recovers automatically. Confirm that the log contains the real client address; if a reverse proxy is not configured correctly, fail2ban may ban the proxy itself and cut off every visitor. Keep the jail limited to the login endpoint and document how to remove an accidental ban.
Use WordPress application protection as a second layer
Wordfence Brute Force Protection can limit login attempts, lock out addresses after repeated failures, limit password-reset abuse, and rate-limit abusive requests. These controls are valuable defense in depth, but they execute in PHP. During a large flood, PHP still has to receive and process enough of the traffic to invoke the plugin, so application throttling should not be your only control.
Configure lockouts without trapping administrators
- Use a short observation and lockout policy that reflects your normal typo rate and password-manager behavior.
- Do not exempt an entire dynamic ISP range; use a trusted integration or a controlled administrator network where possible.
- Keep password-reset limits separate from login limits so an attacker cannot exhaust reset emails or mail-queue capacity.
- Log lockouts and alert on a sudden rise, but provide a documented emergency-unlock procedure for verified administrators.
WordPress.org security guidance summarizes the preferred direction as: “Prefer edge-level WAF, 2FA, passkeys, and targeted rate-limiting instead.” That combination addresses both traffic volume and account risk.
Harden accounts so a flood cannot become a takeover
Require phishing-resistant or second-factor authentication
Require 2FA or passkeys for every administrator and for any account that can install plugins, edit themes, or change users. A stolen password then does not automatically grant access. Enforce the requirement at the identity provider when using SSO, and verify that emergency or recovery accounts have equivalent protection.
Eliminate reusable password weaknesses
- Use a unique, long password for every WordPress account and store it in an approved password manager.
- Remove unused accounts and reduce privileges to the minimum role required.
- Rename or remove legacy administrator accounts named
adminafter creating a protected replacement; update ownership and content attribution before deletion. - Keep WordPress core, themes, plugins, PHP, and the operating system supported and patched.
Protect password-reset and user-enumeration paths
Rate-limit password-reset requests and monitor outbound mail volume. Review whether public author archives, REST responses, or error messages disclose usernames that make guessing easier. Do not “hide” the login URL as the primary defense: determined clients can discover it, and hiding it can complicate support and monitoring.
Decide what to do with XML-RPC
If the site has no dependency on XML-RPC, disable it at the edge or web server and confirm that publishing, mobile administration, and connected services still work. If Jetpack or a mobile workflow requires it, retain the endpoint but restrict and rate-limit it separately. A login rule for wp-login.php does not protect XML-RPC traffic.
Compare the control layers
| Control | Enforcement location | Origin-resource protection | Specificity and exceptions | Logging and operations | Compatibility and cost considerations |
|---|---|---|---|---|---|
| CDN/WAF rate limit | Edge, before origin | Strongest; abusive requests are rejected before PHP | Can match host, method, path, response code, identity, or network; requires careful exceptions | Centralized analytics and alerts; plan-dependent features | Usually compatible with SSO, Jetpack, and mobile clients when exceptions are tested; availability depends on the current plan |
| Nginx limit_req | Origin web server | Strong for requests that reach Nginx; PHP can be spared | Exact location and client-key rules; proxy IP configuration is critical | Server logs and status codes; moderate operational complexity | No separate plugin license, but requires server access and careful tuning |
| Apache/ModSecurity | Origin web server and request firewall | Good before WordPress execution when rules match early | Highly specific with OWASP CRS or custom rules; false positives require testing | Detailed audit logs; rules require maintenance | Depends on Apache modules, hosting permissions, and CRS configuration |
| Fail2ban | Host firewall | Protects the host after log detection; does not prevent the first requests | Temporary IP bans; vulnerable to distributed sources and incorrect proxy addresses | Clear ban history and recovery commands; operational overhead | Free software, but requires root access and correct log parsing |
| WordPress security plugin | PHP/application layer | Limited during a large flood because PHP still runs | Convenient login, reset, and lockout policies; plugin-specific exceptions | WordPress-visible events and alerts; adds application dependency | Useful defense in depth; licensing and feature availability vary by product and plan |
Test the change without locking out real users
- Record the current rule, threshold, exception list, and the person who can undo it.
- Enable logging or simulation mode at the edge and server before enforcing a block.
- Test an administrator login from the normal office or home network, including a deliberate failed password followed by a successful login.
- Test SSO, Jetpack, mobile administration, password reset, and any automation that legitimately uses the endpoint.
- Generate a controlled sequence of requests from an authorized test client and confirm that the expected challenge, 429 response, or block occurs.
- Watch origin CPU, PHP workers, database latency, response time, and application logs during the test.
- Enable enforcement, then verify that edge logs show the action and origin logs show fewer abusive requests.
- Schedule a review after traffic patterns change, a plugin is added, or an integration’s network ranges are updated.
Troubleshoot common failures
Administrators receive challenges or 429 responses
Lower the scope of the exception rather than raising a site-wide limit. Check whether multiple people share one NAT address, whether the rate window is too short, and whether failed SSO handshakes are being counted as login attempts. Confirm the proxy’s real-IP configuration before changing thresholds.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →The rule has no effect on origin load
Verify that DNS traffic actually passes through the CDN, that the hostname and path match exactly, and that HTTP and HTTPS hostnames are covered. Look for direct-to-origin addresses, alternate hostnames, IPv6 records, and an upstream load balancer that bypasses the rule. A plugin-only rule will not reduce requests that are already consuming PHP workers.
All visitors are blocked
Check whether the origin sees the CDN address as the client and therefore applies one shared Nginx or fail2ban limit. Restore the previous configuration, configure trusted proxy addresses, and retest with a small threshold before re-enabling enforcement.
Jetpack or mobile publishing breaks
Inspect which endpoint and source identity the integration uses. Add the narrowest verified exception or retain XML-RPC with its own limit. Do not disable an endpoint blindly when the business workflow depends on it.
Attackers keep changing addresses
Use edge request-rate limits, response-code signals, challenges, and account protections rather than extending a permanent IP list. Distributed traffic is a reason to move enforcement earlier, not to create broader geographic blocks.
Free tools Windows power users keep installed
One-click scans. No signup required.
Monitor and recover after an incident
Keep alerts for failed-login spikes, successful administrator logins from unusual locations, newly created users, privilege changes, plugin or theme changes, and file-integrity deviations. Review web-server and WordPress logs for the period before, during, and after the flood. Preserve evidence before making large cleanup changes.
Use tested backups
Maintain backups that can be restored without relying on the compromised host, and test restoration periodically. A backup is useful only when you know its age, contents, credentials, and recovery procedure. Keep at least one copy offline or otherwise inaccessible to a compromised web account.
Investigate signs of compromise
- List successful logins and compare them with administrator activity and expected locations.
- Review users, roles, application passwords, API keys, scheduled tasks, and recently modified files.
- Check plugins and themes for unexpected additions or changed code, and compare files with trusted release packages.
- Rotate WordPress, database, hosting, SFTP, SSH, CDN, and integration credentials after containment.
- Remove unauthorized persistence, patch the original weakness, and document the timeline and actions taken.
A practical operating checklist
- Measure
POST /wp-login.phpandPOST /xmlrpc.phpseparately. - Preserve logs and establish normal request and failure baselines.
- Deploy a host-and-path-specific edge rate limit before relying on PHP plugins.
- Test exceptions for administrators, SSO, Jetpack, mobile clients, and required automation.
- Add Nginx, Apache/ModSecurity, or temporary fail2ban controls where the architecture warrants them.
- Enable 2FA or passkeys, unique passwords, least privilege, and timely updates.
- Disable or restrict XML-RPC according to actual integration needs.
- Alert on failed-login spikes, successful-admin anomalies, user changes, and file modifications.
- Keep tested, offline-capable backups and a documented rollback and emergency-unlock procedure.
- Review thresholds and exceptions whenever traffic or integrations change.
Wordfence reported that it blocked and logged more than 54 billion malicious requests and blocked more than 55 billion password attacks in 2024. Those are vendor-reported annual figures, not an independent census, but they illustrate why login abuse is common enough to justify layered controls. Cloudflare’s documentation describes rate limiting as a way to protect a login endpoint from brute-force abuse, while Wordfence documents that its brute-force protection limits login attempts. Used together with account hardening and monitoring, these controls reduce both the chance of takeover and the resource cost of the flood.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
