Your hosting provider flags suspicious files, your site suddenly redirects visitors to an unfamiliar domain, or Google search results start showing pages that nobody on your team ever created. The instinctual first reaction is usually to change the administrator password, install a security plugin, and run every update WordPress suggests.
Each of these steps makes sense, but none of them necessarily removes the underlying cause of the breach. An attacker often does not need access to the admin dashboard at all. All it takes is a vulnerability in a single installed plugin that allows them to execute arbitrary operations without authentication.
That is why WordPress security should never come down to just a strong password and updates run once a month. You also need to know exactly which component versions are running in production and whether any new vulnerabilities have surfaced that require immediate action.
Most WordPress vulnerabilities lie within plugins
The WordPress core is only one part of the overall environment. A typical website also relies on a dozen or several dozen plugins, an active theme, and often custom code written specifically for that site.
According to the Patchstack State of WordPress Security in 2026 report, 11,334 new vulnerabilities were reported across the WordPress ecosystem in 2025—a 42% increase compared to the previous year. 91% were tied to plugins, 9% to themes, while only six vulnerabilities-all rated low priority-were reported in the WordPress core itself.
Even more critically, 46% of these vulnerabilities had no patch available when they were publicly disclosed. Simply running regular updates is no longer enough to keep a site secure. In many cases, the vulnerability is already public knowledge, but an updated version of the plugin does not yet exist.
When this happens, you must assess the risk specifically for your setup. Sometimes disabling a vulnerable feature is enough; in other cases, you can deploy a targeted WAF rule, while more severe flaws may require temporarily deactivating or replacing the plugin altogether.
A strong password cannot protect a vulnerable plugin
Strong, unique passwords and two-factor authentication should be standard across all administrative accounts. They primarily protect against account takeovers and unauthorised logins.
However, they offer zero protection against vulnerabilities that can be exploited without logging in. If the flaw lives within a public form, a REST API endpoint, or a function accessible to unauthenticated visitors, an attacker never needs to touch the WordPress login screen.
The more third-party code running on your site, the larger the attack surface you have to manage. This is especially evident in WooCommerce, where the core store is typically surrounded by integrations for payments, shipping, warehouse management, marketing automation, invoicing, product feeds, and other services.
Updating WordPress once a month is no longer enough
Scheduled maintenance windows are still essential. They provide dedicated time for updates, regression testing, log reviews, backup verifications, and pruning unused components. The problem arises when this monthly check is your sole line of defence.
If you run updates on the first day of the month and a critical vulnerability in one of your plugins is disclosed a few days later, you are over three weeks away from your next scheduled review. The vulnerable code remains live and exposed in production the entire time.
You also cannot assume that a disclosed vulnerability immediately comes with an available update. If the developer has not yet pushed a fix, WordPress will not show any pending updates—even though a component you rely on has a publicly documented security flaw.
That is why it pays to separate routine maintenance from vulnerability monitoring. You can schedule standard updates at set intervals, but critical vulnerability alerts require prompt evaluation as soon as they arise.
AI is accelerating vulnerability discovery
The pace of security research has fundamentally shifted. AI-assisted tools are increasingly used to scan massive code repositories, uncover potential flaws, verify their exploitability, and draft patches.
Automated red teaming and security analysis can process vastly more code than manual audits ever could. For software developers, this means finding bugs earlier. For site owners, however, it means disclosure notices are landing faster and in greater volume.
Your maintenance workflow needs to be built around this reality. If vulnerability discovery is automated, relying on an administrator manually opening the WordPress updates screen once every few weeks is an outdated strategy.
No available update does not mean no vulnerability
The WordPress dashboard answers one specific question: is there a newer version available for this component? It does not tell you whether the version you are currently running contains a known vulnerability.
You might be running the latest release of a plugin, yet a new zero-day or unpatched flaw was just disclosed before the author could issue a fix. The same blind spot applies to abandoned plugins: WordPress will never prompt an update because no new versions are being developed.
To accurately evaluate your security posture, you need an inventory of the exact versions of WordPress, your theme, and all active plugins, cross-referenced against databases of known vulnerabilities. This surfaces threats that the update dashboard cannot see.
Vulnerability monitoring can be automated
This is precisely how we built DockRay. The monitoring agent tracks the active version of WordPress along with every installed plugin and its release. This data is continuously checked against known vulnerability databases.
If a vulnerability impacts a version running on your site, DockRay triggers an immediate alert. Your team does not have to wait for the next maintenance cycle or manually track security advisories for every single extension.
An alert does not replace remediation or patching, but it drastically reduces the window between vulnerability disclosure and human response. Once notified, you can check whether a patch is out, evaluate the real-world risk to your setup, and take targeted action.
Automatic updates require supervision too
Enabling auto-updates helps reduce patch deployment lag, but it should not be treated as a complete security solution. An update cannot protect you if the developer has not published a fix yet. Furthermore, on complex, custom-built sites, automated unattended updates can easily trigger fatal conflicts with your theme, other plugins, or bespoke code.
There is also an overlooked technical catch: depending on your server setup, WordPress may silently skip automatic updates entirely, even if your dashboard indicates they are active.
A Git repository can halt automatic updates
WordPress checks whether the installation resides inside a version-controlled directory. The internal method WP_Automatic_Updater::is_vcs_checkout() scans for directories like .git, .svn, .hg, and .bzr. If detected, background automatic updates may be suppressed.
This commonly occurs on VPS instances and dedicated servers where WordPress is deployed directly from a Git repository. Because the .git folder may be located a level above the public web root, the reason updates are not firing is rarely obvious.
While WordPress may alert administrators about this during core update checks, the issue often goes unnoticed for plugins and themes. In the admin panel, the toggles may still appear as if auto-updates are enabled.
You can verify your status under Tools → Site Health, where WordPress runs background update diagnostics. For managed environments, it is also worth reviewing your wp-config.php definitions:
php
AUTOMATIC_UPDATER_DISABLED
DISALLOW_FILE_MODS
WP_AUTO_UPDATE_CORE
If your platform deploys through Git and CI/CD, running updates through a controlled version-bumping, testing, and staging pipeline is far safer and more reliable than letting WordPress write directly to production files.
Delete plugins and themes you do not use
Deactivating a plugin leaves its files on your server. Its PHP files do not disappear when you click "Deactivate", which means dormant code can still be accessed and exploited. Unused components should be permanently deleted.
This audit is also a great opportunity to review whether your active plugins are still actively maintained. An absence of updates could mean your installed version is current—or it could mean the developer abandoned the project years ago.
For every critical component, you should know the date of the last release, verified compatibility with modern WordPress versions, and any known vulnerability history. Pay special attention to abandoned plugins handling public inputs, file uploads, payments, or REST interactions.
Audit accounts and permissions
Once the codebase is secured, audit your user directory. Accounts belonging to former contractors, agencies, or employees should be deleted or deactivated immediately, and Administrator privileges reserved exclusively for those who need unrestricted access.
Enforce strong passwords and 2FA across all administrative accounts. Do not overlook WordPress Application Passwords, which grant authenticated access to endpoints like the REST API. Changing an account password does not automatically revoke existing application passwords.
You can add another layer of protection by disabling the built-in file editor directly from your configuration:
php
define('DISALLOW_FILE_EDIT', true);
While this will not stop every route to code execution, it prevents an attacker who gains access to an admin account from immediately editing PHP files directly inside the WordPress dashboard.
Backups must live offsite
Storing backups solely on the same server hosting your WordPress installation leaves you entirely unprotected in a severe breach. If an attacker gains full server or filesystem access, they can wipe or corrupt your backups right alongside your live site.
Maintain at least one verified offsite backup stored completely independent of your hosting environment. Regularly test your recovery process as well. Just because a scheduled script generates an archive does not guarantee that the site, database, and integrations will restore cleanly without errors.
A WAF and security plugin are an extra layer of defence
Security plugins and Web Application Firewalls (WAF) help filter malicious traffic, curb brute-force login attempts, monitor file integrity, and provide audit trails. They are valuable tools, but they cannot substitute for core updates, proactive vulnerability tracking, and ongoing component audits.
A WAF is particularly effective in the gap between vulnerability disclosure and patch deployment. If an exploit pattern is known and detectable in HTTP request headers or payloads, a targeted firewall rule can block incoming attacks until an official vendor patch is safely applied.
What to do if WordPress has already been hacked
Restoring a recent backup can quickly bring the site back online, but it does not resolve the breach. If the backup contains the same vulnerable plugin version that enabled the compromise, you are simply restoring the backdoor alongside the site.
Before scrubbing the installation, take a full snapshot of the infected environment. Server logs and altered files are crucial forensic evidence to determine how and when the intrusion occurred.
Next, invalidate all active sessions, regenerate WordPress security keys and salts, and reset credentials across the board—including WordPress admin accounts, hosting panels, SFTP/SSH, and the database. Inspect and revoke all existing Application Passwords.
Verify core files against official releases using WP-CLI:
bash
wp core verify-checksums
For plugins installed from the official repository, run:
bash
wp plugin verify-checksums --all
Checksum verification flags modified core files, but it does not paint a complete picture. Custom themes, bespoke plugins, or premium tools bought outside the WordPress repository do not have public checksums for comparison.
The database requires equal attention. Malicious redirects are frequently injected into wp_options, post content, or automated cron events—none of which appear during filesystem checksum comparisons.
Once malicious modifications are cleaned, identify the entry point. Examine web access logs leading up to the incident and compare them against the software versions running at the time. Only eliminating the vulnerable component or sealing the exploited attack vector guarantees the site will not be reinfected.
Security scanners cannot catch everything
Automated scanners excel at flagging files that deviate from clean repository baselines or match documented malware signatures. They struggle, however, with custom themes, proprietary business logic, code placed in mu-plugins, or third-party premium extensions.
The database is another blind spot. Modifications inside wp_options, scheduled cron tasks, or raw database records do not register during basic file checksum scans.
A scanner can alert you to an infected file or known signature, but it rarely reveals how the malicious payload got onto the server in the first place. Pinpointing root causes demands deep log analysis and cross-referencing the vulnerabilities present across your plugins at the time of the breach.
What does proper WordPress maintenance look like?
Regular maintenance windows remain vital. Updates can be verified in staging, backups captured, changes deployed predictably, and core checkout or enquiry flows thoroughly checked.
However, routine maintenance cannot be the only time your team evaluates security. In between scheduled releases, your production versions must be continuously monitored against new vulnerability advisories.
When a serious vulnerability is disclosed, the response depends on the context. If a patch is available, deploy it promptly. If no patch exists, evaluate workarounds: disable the vulnerable feature, add a WAF rule, or temporarily replace the plugin.
In practice, modern WordPress security pairs structured maintenance cycles with continuous real-time monitoring. The schedule handles orderly upkeep, while vulnerability alerts trigger targeted interventions whenever new threats arise.
WordPress security demands continuous monitoring
Under our Technical support and development agreements, we go far beyond hitting the update button. We audit installed versions, root out abandoned plugins, fine-tune update pipelines, check backups, and monitor vulnerabilities that require action ahead of the regular maintenance cycle.
Much of this process can be automated. DockRay actively monitors your WordPress core and installed plugins, alerting our team the moment a version in production matches a newly discovered vulnerability. This lets us react immediately instead of leaving your site exposed until the next scheduled review.
If your hosting provider reported suspicious files, your site is acting erratically, or you want to ensure your platform is properly hardened, get in touch. We can audit your installation, verify its current security posture, and implement ongoing maintenance and monitoring to keep it secure.
