Stop a wp-login.php POST flood in layers: measure the traffic, throttle the endpoint at your CDN or WAF before it reaches PHP, add a narrow server-side limit, then use WordPress controls and stronger authentication to reduce account-takeover risk. Do not rely on a login plugin alone during a large attack; plugin rules run after the request has already consumed origin resources.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The safest configuration limits only POST /wp-login.php, preserves access for administrators and required integrations, and treats /xmlrpc.php as a separate decision. Temporary, evidence-based bans are safer than permanent country-wide or broad IP blocks.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →What a wp-login.php POST flood is
wp-login.php is the WordPress login script in the site root. In a brute-force flood, automated clients repeatedly submit guessed usernames and passwords with POST requests. The same traffic can be both an authentication threat and a resource-exhaustion attack: every request may invoke web-server processing, PHP workers, WordPress code, session handling and database queries.
An HTTP 200 response does not prove a login succeeded; WordPress can return a normal login page after a failed submission. Conversely, a successful response may be hidden among thousands of failures. Count attempts by method, path, status and outcome rather than blocking on one status code alone.
#1 Best Overall
Wordfence reported that it blocked and logged more than 54 billion malicious requests and more than 55 billion password attacks in 2024. Those are vendor-reported annual totals, not an independent industry census, but they illustrate why login abuse is routine rather than exceptional.
Measure the flood before changing rules
Start with a short observation window and preserve the relevant access, WAF and authentication logs. A rule tuned without knowing normal administrator traffic can lock out the people it is meant to protect.
Free tools Windows power users keep installed
One-click scans. No signup required.
Check the request pattern
- Confirm the exact host and path. Some sites expose the login script at more than one hostname, while a reverse proxy may rewrite paths before they reach the origin.
- Confirm the method is
POST. Keep ordinaryGET /wp-login.phppage loads in mind when choosing a rule, but do not rate-limit unrelated WordPress URLs with the same threshold. - Record status codes, response sizes and timing. A concentration of 401, 403 or repeated login-error responses is useful for identifying failed attempts, but status-code behavior varies with themes, plugins and WAF challenges.
- Measure requests per minute by source IP, ASN or other edge identifier, and also measure the aggregate rate against the whole site. A distributed attack can remain harmful even when each address sends only a few requests.
- Look for legitimate administrators, SSO callbacks, automation, Jetpack connections and mobile applications that use the endpoint. Record their source networks, user agents and expected frequency before enforcing a block.
Preserve evidence and alert on spikes
Keep a copy of logs before rotating them. Alert on a sudden increase in POSTs to /wp-login.php, unusual geographic or ASN concentration, rising PHP worker utilization, database saturation, elevated 5xx responses and successful logins from unfamiliar locations. Correlate WAF events with WordPress failed-login events so an edge challenge does not look like an application failure.
Put the first limit at the edge
Edge enforcement is the preferred first control because it can reject or challenge abusive requests before they consume origin CPU, PHP workers or database capacity. Cloudflare documents rate-limiting rules for login endpoints and credential-stuffing cases; feature names and available actions depend on the current plan.
Create a narrow login rule
- Select the exact public hostname and path
/wp-login.php. - Match the
POSTmethod. Review/xmlrpc.phpin a separate rule rather than combining two endpoints with different compatibility requirements. - Choose a counting key, normally the client IP at the edge. For distributed attacks, add an aggregate or managed-detection rule if your service supports it.
- Set a request window and threshold from the measurements you collected. Start with a challenge action or a short temporary block, then lower the threshold only after observing legitimate administrator and integration traffic.
- Where supported, count failed responses such as 401 or 403 to focus mitigation on repeated unsuccessful attempts. Do not assume every failed login uses those codes; verify your own logs.
- Add narrowly defined exceptions for trusted SSO, Jetpack or mobile-app networks only when their addresses are stable and monitored. An exception should not cover an entire country or a broad consumer ISP range.
- Log matches, alert on sustained activity and review the rule after deployment. A rule that silently challenges every request can hide a compatibility problem.
Use a challenge when browser-based administrators need to continue signing in and the traffic pattern is uncertain. Use a temporary block when the source is clearly abusive or when the origin is already under load. Permanent blocks should be reserved for well-understood, stable sources; attackers can rotate addresses, and shared networks can contain legitimate users.
Add a server-side control for traffic that reaches the origin
Server limits are a second line of defense for bypasses, misconfigured DNS, and traffic that an edge rule does not identify. Scope them to the login endpoint and document every exception.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsNginx
Define a dedicated shared zone and apply it only to the exact login location. Choose the rate and burst from observed legitimate use; the values below are an example starting point, not a universal safe setting.
limit_req_zone $binary_remote_addr zone=wp_login:10m rate=5r/m;
server {
location = /wp-login.php {
limit_req zone=wp_login burst=10 nodelay;
# pass the request to your normal PHP handler here
}
}The exact placement must match your existing PHP handler. If you need to limit only POST requests, use a method-aware map or conditional routing that your configuration standards support, and test both the login page load and form submission. Watch for legitimate bursts from SSO or password managers before reducing burst.
Apache and ModSecurity
Apache deployments can use ModSecurity with the OWASP Core Rule Set, or a narrow access-control rule that detects repeated submissions to /wp-login.php. Keep the rule endpoint-specific and use temporary enforcement where possible. Test it in detection or logging mode first; an overly broad rule can affect REST requests, media uploads or unrelated virtual hosts.
Caddy and fail2ban-style controls
Caddy can apply route-specific access controls and proxy requests through a WAF or authentication layer. Fail2ban can consume web-server or WordPress authentication logs and impose temporary firewall bans after repeated failures. Configure trusted-proxy handling correctly: if the firewall sees only your reverse proxy address, it may ban the proxy and leave the attacker untouched. Verify which header is authoritative for the real client address and prevent clients from spoofing it.
Use WordPress protection as defense in depth
Wordfence Brute Force Protection can limit login attempts, lock out abusive IPs, restrict password-reset abuse and rate-limit other suspicious requests. These controls are useful when an attack is small enough for PHP to handle, and they provide application-level visibility that an edge rule cannot.
They are not the best sole defense during a large flood because WordPress must load before the plugin can evaluate the request. Keep the edge or web-server limit in place, then tune the plugin to catch attempts that pass the earlier layers. Review lockout duration, failed-attempt thresholds and allowlists alongside your SSO and support procedures so a legitimate administrator can recover without disabling protection globally.
Harden accounts so throttling is not your only protection
- Require two-factor authentication or passkeys for administrators and other privileged roles. These controls reduce account takeover even if a password is guessed.
- Use a unique, long password for every account and remove unused users. Rename or remove legacy administrator accounts such as a default
adminuser after confirming that no integration depends on it. - Keep WordPress core, themes and plugins updated, and remove abandoned components. A login flood often accompanies attempts to exploit an outdated plugin.
- Monitor successful logins, new-user creation, role changes, password resets and plugin or theme modifications, not just failed attempts.
- Give support staff a documented emergency path that does not require turning off all rate limits. A temporary, audited exception is safer than a permanent global allowlist.
Treat XML-RPC as a separate endpoint
/xmlrpc.php is a high-interest WordPress endpoint and should have its own disable, restriction or rate-limit decision. Disable it only when the site does not need it. Jetpack connections and some mobile workflows require XML-RPC, so confirm those dependencies first and allow only the required traffic where possible. A rule for wp-login.php does not automatically protect XML-RPC, and an XML-RPC block does not stop direct login POSTs.
Compare the available controls
| Control | Where it runs | Origin-resource protection | Specificity and exceptions | Logging and operations | Compatibility and cost considerations |
|---|---|---|---|---|---|
| CDN/WAF rate limit | Edge, before the origin | Strongest; abusive requests can be stopped before PHP | Can match host, path, method, source and sometimes response code; requires carefully scoped exceptions | Central event logs and alerts; plan-dependent features | Check the current service plan and proxy configuration; preserve SSO, Jetpack and mobile access |
| Nginx, Apache or Caddy rule | Origin web server or reverse proxy | Good, but the request has reached the server | Very precise by virtual host and path; configuration mistakes can affect all traffic | Server logs and standard monitoring; requires deployment and rollback discipline | No separate plugin license, but administration expertise is required |
| ModSecurity/OWASP CRS | Web-server security layer | Good when rules run before PHP | Detailed detection, but tuning is needed to avoid false positives | Rich audit logs; rule maintenance adds operational work | Verify CRS compatibility with your Apache or proxy stack |
| Fail2ban or firewall bans | Host firewall | Strong after a source is identified | Temporary IP bans are effective for concentrated attacks; proxy-IP handling is critical | Ban and unban logs; requires reliable authentication logs | Can block shared or changing addresses if thresholds are too aggressive |
| Wordfence or another application control | WordPress/PHP | Limited during a high-volume flood because PHP still runs | Understands login and password-reset behavior; easy to create lockout conflicts | Application events and lockout reports | Useful defense in depth; review licensing and site performance for your deployment |
Tune limits without locking out administrators
Base thresholds on real behavior
Count normal administrator sign-ins, failed password entries, SSO retries and password-manager behavior over several days. A human may submit a few attempts in a short period, while an attack can generate hundreds or thousands. Use a short burst allowance for legitimate retries and a longer temporary penalty for sustained abuse.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Test every access path
- Load the login page with
GET, submit a valid administrator login, and verify that a failed password is handled normally. - Exercise SSO callbacks, Jetpack connectivity and any supported mobile application.
- Confirm that the edge sees the real client address when a reverse proxy is in front of the origin.
- Check that a challenge or block produces the expected status and that the origin receives no request during enforcement.
- Keep a rollback rule or console access available before enabling a production block.
Prefer temporary, narrow action
Temporary bans let an address cool down while limiting damage from false positives. Narrow the rule to POST /wp-login.php; do not respond to login abuse by blocking the entire site, REST API or an entire country unless you have a separate, documented reason. Reassess thresholds when traffic patterns change, such as after an SSO migration or a marketing campaign that creates new administrator activity.
Recover after a suspected compromise
- Keep tested backups that can be restored without relying on the compromised host. Maintain an offline-capable copy and verify that restoration works.
- Review successful logins, newly created users, role changes, password resets, plugin and theme changes, and file-integrity alerts for the incident window.
- Reset affected passwords, revoke sessions and rotate secrets used by integrations. Require 2FA or passkeys for privileged users before reopening access.
- Inspect the filesystem and database for unexpected administrator accounts, modified plugins, injected code and altered scheduled tasks. Update or replace compromised components.
- Preserve logs and timestamps, document which rules were enabled, and remove emergency exceptions after the threat subsides.
A practical rollout sequence
- Inventory every legitimate consumer of
wp-login.phpand/xmlrpc.php. - Measure request volume, source distribution, response codes and origin load; save logs.
- Deploy a logged, narrow edge rule for
POST /wp-login.phpwith a conservative threshold and an exception plan. - Test administrator, SSO, Jetpack and mobile workflows, then enable challenge or temporary blocking.
- Add the Nginx, Apache, Caddy or fail2ban control needed for traffic that bypasses the edge.
- Enable and tune application protection, 2FA or passkeys, unique passwords and update management.
- Make a separate XML-RPC decision, continue alerting, and review the configuration after the attack.
Bottom line
For most WordPress sites, the durable answer is layered and narrowly scoped: rate-limit POST /wp-login.php at the edge, reinforce it at the web server, use Wordfence or equivalent application controls for defense in depth, and require strong administrator authentication. Measure first, preserve legitimate integrations, monitor successful as well as failed activity, and use temporary targeted bans instead of broad permanent blocks.
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.
