Stop a wp-login.php POST flood in layers: measure the traffic, rate-limit the endpoint at your CDN or WAF before it reaches PHP, add a narrowly scoped web-server control, then use WordPress protections, strong administrator authentication and monitoring. Do not rely on a login-security plugin alone during a large flood, and do not blindly block whole countries or every administrator. A good design preserves legitimate admin, SSO, Jetpack and mobile-app access while making automated guessing expensive.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What a wp-login.php POST flood is—and why it needs two kinds of defense
wp-login.php is the login script in a WordPress site’s document root. In a brute-force POST flood, an automated client repeatedly submits usernames and passwords to that script. The attacker may be trying to take over an account, exhaust PHP workers, consume database connections, or all three at once. Even failed requests can invoke WordPress, load plugins and themes, write logs, and occupy CPU and memory.
As an Amazon Associate I earn from qualifying purchases.
That combination makes this both an authentication problem and a resource-exhaustion problem. Two-factor authentication, passkeys and unique passwords reduce the chance that a guessed password succeeds; they do not stop thousands of requests from reaching your server. Conversely, a network block can reduce load while leaving an administrator with a weak or reused password. Treat traffic control and account security as separate controls.
1. Measure the attack before changing rules
Start with the access logs from your CDN, reverse proxy and origin. Confirm that the requests are actually POST /wp-login.php, rather than a scanner hitting several paths or a legitimate integration. Record the host name, request method, response status, source address as seen by the trusted proxy, user-agent, country or network, request rate and time range. Preserve a copy of the relevant logs before rotating them.
#1 Best Overall
Identify legitimate traffic that shares the endpoint
List every expected caller: human administrators, an SSO flow, scheduled automation, Jetpack, and mobile WordPress applications. Some sites also have monitoring or deployment systems that authenticate through the normal login handler. Ask which source addresses are stable, which users need access, and whether an integration can be moved to a more specific API or protected path. An exception that is too broad can become an attacker’s bypass.
Separate failed guessing from normal sign-ins
Look at response codes and timing. A run of 401 or 403 responses can be a useful signal for failed attempts, but a flood can also produce 200, 302 or 429 responses depending on the application and challenge behavior. Count requests as well as failures. Compare the current rate with a quiet period so that a rule is based on your site’s real administrator behavior, not a generic number.
Set an alert and preserve evidence
Alert on a sustained spike in POSTs to this path, a sudden increase in failed-login events, or a rise in PHP worker and database utilization. Keep timestamps, source distributions and representative requests. That evidence helps tune a threshold, prove whether the edge rule is working and investigate any successful login later.
2. Rate-limit POST /wp-login.php at the edge
The first active control should run at the CDN or WAF edge. Create a rule that matches the exact host, the POST method and the path /wp-login.php. Count requests over a time window, then challenge or block a client that exceeds a threshold chosen from your measured legitimate traffic. Edge enforcement rejects or challenges abusive requests before they consume origin CPU, PHP workers or database capacity.
Cloudflare login rate limiting
Cloudflare documents rate-limiting rules for login endpoints and credential-stuffing use cases. In the rule builder, constrain the hostname and URI path rather than applying a site-wide limit. Use the HTTP method condition so normal page views are unaffected. If available on your plan, count failed response codes such as 401 and 403 to focus mitigation on unsuccessful attempts; retain a request-count rule as a backstop because status codes vary by WordPress configuration.
Choose a response that suits your users. A managed challenge can let a real administrator through while stopping a simple bot; a block is more economical during an obvious flood. Set a short mitigation period first, observe the logs, and lengthen it only when the signal is reliable. Cloudflare feature availability and rule actions depend on the current plan, so verify those details in the account before relying on them.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Build exceptions deliberately
Do not exempt an entire office, VPN provider or country unless you can accept the risk. Prefer a small, documented set of trusted source addresses or an authenticated integration path. Recheck exceptions whenever an administrator changes networks. If SSO, Jetpack or a mobile app uses the endpoint, test a login and a failed login from that workflow before enabling a hard block.
Review XML-RPC separately
/xmlrpc.php is not covered by a rule that only matches /wp-login.php. It is another high-interest WordPress endpoint and needs its own decision. Disable XML-RPC when the site does not need it. If Jetpack or mobile workflows require it, restrict and rate-limit it independently rather than breaking those services with a broad WordPress rule.
3. Add a server-side control for traffic that reaches the origin
An edge rule can miss a direct-origin request, a misconfigured DNS record or an internal route. Add a narrow control on the web server as a second barrier, and make sure the server sees the real client address when a reverse proxy is in front of it.
Nginx
Define a dedicated shared rate-limit zone and apply it only to the exact login location. The following is an illustrative starting point, not a universal limit; tune the rate and burst from your measured administrator traffic:
http { limit_req_zone $binary_remote_addr zone=wp_login:10m rate=1r/s; server { location = /wp-login.php { limit_req zone=wp_login burst=5 nodelay; include fastcgi_params; # pass to the existing PHP handler } } }Keep the exact-match location separate from the rest of the site. A burst allows a short sequence of legitimate requests while the sustained rate limits automation. Test configuration syntax, reload during a maintenance window, and watch both the Nginx status and WordPress login success rate. If a proxy is present, configure its trusted address ranges so $binary_remote_addr represents the client rather than the proxy.
Apache and ModSecurity
On Apache, use ModSecurity with the OWASP Core Rule Set or a narrow access rule to detect repeated POSTs to /wp-login.php. Keep the rule scoped to that path and method, and log the action and matching client address. A broad deny rule can block unrelated application traffic and is difficult to troubleshoot. If you use a reverse proxy, configure trusted proxy handling before writing IP-based rules.
Caddy and other proxies
Caddy and comparable front ends can enforce an access or rate-control policy before forwarding to PHP. The important properties are the same: exact host and path matching, a method condition, a measured threshold, a temporary action and an auditable exception list. Confirm that the proxy forwards the original address safely; trusting an arbitrary client-supplied forwarding header lets an attacker evade an IP limit.
Fail2ban-style temporary bans
Fail2ban can read authentication or web-server logs and impose a temporary firewall ban after repeated failures. Use a filter that targets the login endpoint, not every request from the address. Ban durations should be temporary and observable, with an unban path for an accidentally blocked administrator. If traffic passes through a CDN, configure the real-client IP correctly and place the ban where it has an effect; banning the CDN’s shared address can deny access to everyone.
Free tools Windows power users keep installed
One-click scans. No signup required.
4. Use WordPress protection as a second layer
Wordfence can lock out IP addresses after repeated failures, limit password-reset abuse and rate-limit abusive requests. Its brute-force setting is useful defense in depth: it can recognize application-level failures and provide WordPress-specific logs. However, the request has already reached PHP when a plugin makes the decision, so plugin throttling is less suitable as the only defense during a large flood. Keep the edge and server controls in front of it.
Configure lockout and password-reset limits conservatively, then test an administrator login, a deliberately incorrect password and a reset request. Record how the plugin reports a lockout and who can release it. Ensure that your edge exception strategy does not bypass the plugin’s logging, and that a trusted integration has a supported authentication path rather than an unbounded exemption.
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 totals, not an independent industry census; they indicate the scale the provider observed, not the volume on your site.
5. Harden administrator accounts so a surviving request cannot become a takeover
Require phishing-resistant or two-factor authentication
Require 2FA or passkeys for every administrator and privileged editor. Enforce it for new accounts and verify that recovery codes are stored offline. A second factor reduces the value of a guessed password, while a passkey can resist phishing; neither prevents the POST traffic itself, so retain the rate controls.
Recommended Free Tools
Remove legacy access
Delete unused administrators, remove the predictable legacy admin account or rename it as part of a controlled migration, and give each person an individual account. Use unique passwords generated for this site and revoke credentials belonging to former staff or old integrations.
Patch the complete WordPress stack
Keep WordPress core, themes and plugins updated from maintained sources. A login flood may be noise around an unrelated vulnerability, and an outdated plugin can turn a stolen session into persistent access. Review plugin ownership and remove software that is no longer needed.
6. Monitor for signs that a login succeeded
A lower request rate does not prove that the incident is over. Review successful logins during the attack window, especially from unusual networks or at unusual times. Check for newly created users, changes to administrator roles, modified plugins or themes, unexpected scheduled tasks and altered files.
Compare file integrity with a known-good backup or deployment artifact. Preserve suspicious logs before cleaning the site. If you find an unauthorized account or changed code, isolate the affected credentials, reset passwords and tokens, remove persistence, patch the entry point and restore only from a backup whose integrity you can establish.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problems7. Recovery and backup requirements
Maintain backups that are tested and capable of being accessed offline or from a separate account. A backup that lives on the same compromised server is not a recovery plan. Test a restoration of both the database and uploaded files, and document who can perform it when the normal administrator account is unavailable.
After containment, rotate administrator passwords, application passwords, SSO secrets and API keys that may have been exposed. Review the edge, server and plugin logs together to establish the first suspicious event and the last unauthorized action. Keep temporary blocks until traffic returns to baseline, then reduce them rather than leaving a permanent broad blocklist.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.8. Choosing the right layer
| Approach | Where it runs | Origin-resource preservation | Specificity and exceptions | Logging and operations | Compatibility and cost |
|---|---|---|---|---|---|
| CDN/WAF rate limit | Edge, before the origin | Best; abusive requests are challenged or dropped before PHP | Can match host, method and path; trusted integrations need explicit exceptions | Central request analytics and alerts; features and actions are plan-dependent | Usually the least operational load; availability depends on the provider plan |
| Nginx, Apache or Caddy control | Origin web server or reverse proxy | Good, but the request has reached the server | Very precise when limited to /wp-login.php; proxy-IP configuration is essential |
Uses server logs and configuration management; requires reload and testing | Available with the server stack; administrators maintain the rules |
| Fail2ban temporary ban | Host firewall or local service | Good after a log event; less useful if the application is already saturated | Can target repeated failures; incorrect proxy handling can ban a shared proxy | Requires filter tuning, ban monitoring and an unban procedure | Low software cost but higher maintenance |
| WordPress security plugin | PHP/application layer | Limited during a high-volume flood because PHP runs first | Understands login and reset events; can lock out attackers and record application context | Convenient WordPress logs and controls; must remain reachable for administration | Useful as defense in depth; licensing and features vary by edition |
| 2FA, passkeys and password policy | Authentication decision | Does not reduce request volume | Protects privileged accounts; recovery and integration exceptions must be designed | Monitor enrollment, failures and successful logins | Low direct infrastructure cost; requires user enrollment and support |
9. Common mistakes and how to correct them
Using only a plugin
If every request reaches PHP, the plugin may be overwhelmed along with the site. Put an edge or web-server limit first, then keep the plugin for application-aware lockouts and logging.
Blocking every country or every non-admin address
Broad geography blocks create avoidable false positives for traveling staff, VPN users and distributed teams. Scope the rule to the login endpoint and use measured thresholds. If a temporary geographic restriction is unavoidable during an emergency, document its end time and monitor legitimate failures.
Locking out the whole office
An IP-based policy can treat many people behind one NAT gateway as one client. Use a challenge, a higher threshold based on observed traffic, or an authenticated exception instead of a permanent allowlist that an attacker could discover.
Forgetting XML-RPC
A successful login rule for /wp-login.php does not protect /xmlrpc.php. Disable it when unused, or give required Jetpack and mobile workflows a separate, tested limit.
Trusting the wrong client IP
When a proxy is in front of WordPress, the origin may log only the proxy address. Configure trusted proxy ranges and reject untrusted forwarding headers. Otherwise, Fail2ban and server limits may punish every user together—or be bypassed by a forged address.
Making a permanent blocklist
Attack infrastructure changes quickly, and recycled addresses can belong to legitimate users later. Prefer temporary bans with expiry, a review queue and an auditable exception process.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 1110. A practical rollout checklist
- Capture and preserve logs showing method, path, status, source distribution and timing.
- List legitimate administrator, SSO, Jetpack, mobile and automation traffic.
- Create an edge rule for the exact host,
POSTmethod and/wp-login.phppath. - Choose a threshold and window from observed legitimate traffic; add a challenge or temporary block and monitor exceptions.
- Review
/xmlrpc.phpseparately and disable, restrict or rate-limit it according to actual requirements. - Add a narrow Nginx, Apache, Caddy or Fail2ban control at the origin, with correct proxy-IP handling.
- Enable WordPress application lockouts and password-reset limits as defense in depth.
- Require 2FA or passkeys, remove unused privileged accounts and rotate reused credentials.
- Check successful logins, new users, changed plugins and file integrity.
- Test an offline-capable restore and document how temporary rules and bans will be removed.
What success looks like
You should see the edge absorbing or challenging the excess POST volume, stable PHP and database utilization, and normal administrators completing logins through documented exceptions. Failed-login alerts should become explainable rather than constant noise. Keep measuring after the immediate spike: tune thresholds when administrator behavior changes, review XML-RPC and integration needs, and retain temporary controls only as long as their logs show a benefit.
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.
