The popular image of a website being hacked involves someone at a keyboard, carefully probing a specific target. For most WordPress sites, the reality is different. Attacks come from distributed bot networks executing automated scripts that run continuously, methodically, and without any human attention directed at your site specifically. Your store is one entry in a list of millions.
Understanding how this works makes it easier to understand what protection actually accomplishes and what it does not.
The login page
WordPress's login endpoint is located at the same URL on every WordPress installation: wp-login.php. Automated bots know this. They cycle through lists of usernames, starting with the most common defaults like "admin", "administrator", and your domain name, then pairing them against password lists harvested from previous data breaches.
Without rate limiting or lockout rules, a WordPress login page will accept these attempts indefinitely. A bot can test thousands of combinations per hour from a single IP, or spread attempts across a botnet to avoid any per-IP threshold.
At EasWrk, login rate limiting is enforced at the server level. After a threshold of failed attempts from a single source, that source is temporarily blocked. This handles a significant share of basic credential-stuffing traffic, though it is not a complete defense against distributed attempts that use large numbers of IP addresses.
xmlrpc.php
WordPress includes a remote access endpoint at xmlrpc.php, originally designed for external publishing tools and mobile apps. It has a specific property that attackers exploit heavily: it accepts credential tests in batches, meaning a single request can test hundreds of username and password combinations at once. This allows attackers to bypass per-request rate limiting on wp-login.php entirely.
Many WordPress administrators who do not use the features xmlrpc.php enables disable it entirely. This is a common and reasonable hardening step. If you do not publish from a mobile app or use an external blog publishing tool, you probably do not need xmlrpc.php open.
Disabling xmlrpc.php removes one of the most commonly abused WordPress attack surfaces. If you are unsure whether your site uses it, WrkPilot can check your plugins for anything that depends on it.
Plugin vulnerability scanning
Automated scanners regularly probe WordPress installations to identify which plugins and themes are installed and what version they are running. Once identified, that version is cross-referenced against public vulnerability databases. Security researchers publish CVE records for WordPress plugin vulnerabilities. WPScan maintains a widely used database specifically for WordPress-related vulnerabilities. Both are publicly accessible.
Any site running a known-vulnerable plugin version becomes a specific, prioritized target. Bots execute the known exploit, whether that is an unauthenticated file upload, a SQL injection, or a remote code execution path, depending on what the vulnerability allows.
This is why the gap between "plugin update released" and "update applied on your site" is a meaningful security variable. A plugin with a critical vulnerability that has been patched still poses risk to every installation still running the old version.
What you can see in your logs
If you look at your PHP error log or server access log during a typical week, you will usually find evidence of this activity: repeated requests to wp-login.php, probes for wp-config.php and other sensitive files, requests testing for specific vulnerability patterns that correspond to known CVEs.
Most of it is background noise that your WAF is already blocking at the edge. But reviewing logs periodically is still useful. Unusual patterns, high error rates, or unexpected 500 responses can indicate something worth looking into.
WrkPilot can retrieve and summarize your error logs directly from your account. Asking it to check what is in your error log is a low-effort way to stay on top of what is happening, even when nothing obvious has gone wrong.
The goal is to be a harder target, not an impossible one
No configuration makes a WordPress site immune to attack. The practical goal is to make your site a meaningfully worse target than an unprotected install, and to ensure that when something does get through, the damage is contained and recovery is fast.
Rate limiting, current plugin versions, WAF rules, and regular backups in combination cover most of the realistic attack surface for a small to medium WooCommerce store. None of them individually is sufficient. Together, they represent a practical and maintainable security posture.