WordPress brute force attacks: boring, massive and still profitable

Brute force attacks against WordPress are not new, elegant or particularly interesting from the outside. That is exactly why they still work. They do not need a spectacular vulnerability or a fresh exploit. They rely on volume, automation, reused passwords, forgotten users and teams that only look at login activity once something has already gone wrong.

For an agency managing one or two websites, the problem can feel small. For an agency managing 25, 50 or 100 WordPress installs, it becomes a portfolio problem. It is no longer “a login form”; it is a repeated surface with different users, clients, plugins, schedules and operational habits. The practical question is simple: who notices when the pattern starts?

Why brute force still pays

A brute force campaign does not need to succeed most of the time. It only needs to find one weak combination somewhere in a large estate: an old account, a reused password, a temporary supplier login that was never removed, an admin without a second factor or a site with weak rate limiting.

WordPress.org recommends strong passwords, correct permissions, updates and hardening practices. OWASP treats authentication as a critical area too: limiting attempts, detecting automation, using MFA and avoiding responses that help attackers are basic controls. For agencies, the lesson is straightforward: login security is not a small technical detail. It is part of operations.

The attacker has scale on their side. They can test many sites, credentials and IP addresses. The agency only gets a fair fight when it also operates at scale: clear inventory, centralized signals, consistent rules and repeatable response.

The problem is not only successful access

Brute force discussions often stop at “do not let them guess the password”. That matters, but it is incomplete. Across a WordPress portfolio, repeated login attempts also create noise, load, confusing tickets, false positives and slow decisions.

One site may absorb thousands of attempts without compromise. Another may have a vulnerable user and become an incident. A third may be hit by the same IP ranges seen across other clients. If every site is reviewed in isolation, the agency loses context. If the pattern is visible in one place, decisions improve.

What agencies should watch

The goal is not to chase every failed login. That does not scale. The goal is to separate actionable signals from normal background noise.

• Spikes in failed login attempts by site, user or time window.
• Administrative users with repeated attempts or predictable usernames.
• IP addresses or ranges appearing across several sites in the portfolio.
• Sites without 2FA, login limiting or consistent hardening.
• Suspicious follow-up activity: new users, permission changes, unexpected plugins or activity outside normal hours.

The difference between reactive security and real operations is the ability to answer quickly: which sites are seeing the pattern, which users are exposed, which controls are missing and which action was taken.

Controls that actually reduce risk

Password and user hygiene

It is not enough to ask for “strong passwords” once. Agencies need to review old users, supplier access, shared accounts and excessive permissions. Many operational security issues start with access that made sense six months ago and is now forgotten.

2FA where it matters

Two-factor authentication does not solve everything, but it changes the economics of the attack. If a credential is reused or leaked, the attacker has another barrier to cross. At minimum, administrators, sensitive editor accounts and maintenance users should have it enabled.

Rate limiting and IP blocking

Limiting attempts and blocking malicious IPs when appropriate helps reduce noise and operational friction. It is not a total solution: attackers rotate infrastructure. But combined with portfolio-level signals, it allows teams to react earlier and apply common criteria across sites.

Alerts that do not require opening every WordPress admin

The biggest failure in many agencies is not the absence of a specific plugin. It is that every site lives in its own bubble. If login signals stay inside each individual admin panel, someone has to open sites one by one to understand what is happening. That model breaks as soon as the portfolio grows.

The honest connection to Vulnity

Vulnity should not be sold as magic or as a guarantee that attacks will not happen. Brute force will continue to exist. The value is turning scattered signals into an operational view: monitored sites, alerts, suspicious activity, hardening status, automatic blocking of malicious IPs when applicable and reporting that explains what was seen and what was done.

For an agency, that changes the client conversation. Instead of saying “we did not notice anything unusual” because nobody looked, you can say: “we observed this pattern, these sites were affected, these controls were active and these actions were taken.” That does not promise total security. It promises something more credible: operational control.

Anti-overclaim checklist

• Do not claim that Vulnity detects CVEs or vulnerabilities in plugins, themes or WordPress core.
• Do not promise that it blocks every brute force attack.
• Do not present IP blocking as a replacement for 2FA, strong passwords or user reviews.
• It is accurate to describe centralized visibility, alerts, hardening, suspicious activity, malicious IP blocking when applicable and reporting.

Sources

• WordPress Developer Resources: Hardening WordPress
• WordPress.org: Brute Force Attacks
• OWASP Top 10
• CISA: Use Strong Passwords
• Wordfence: Quarterly WordPress Threat Intelligence Report Q1 2026