On March 7, 2017, the Apache Software Foundation released a fix for a flaw in Struts, a web framework Equifax used for its online dispute portal. Equifax administrators were told to apply it two days later. The portal stayed unpatched, attackers entered in mid-May, and by the time the company noticed them at the end of July they had taken personal records on about 147 million people. The settlement that followed was worth up to $700 million, over a fix that had been free to download since the first week of March.
Time Between a Fix and an Attack
Mandiant’s analysis of vulnerabilities exploited in 2023 put the average time to exploit at 5 days. The same measure was 32 days for 2021 and 2022, and 63 days for 2018 and 2019. Of the 138 vulnerabilities in that analysis, 97 were zero-days, attacked before any fix existed. For the remaining 41, a patch was already out, and the outcome depended on who acted on it first.
Once a fix is public, comparing the old code with the new code shows attackers where the flaw was, and every site still running the old version is exposed to anyone who reads the release notes. In Mandiant’s data, 12% of the flaws exploited after a patch existed were attacked within a day, and 56% within a month.
A site owner who updates once a quarter is therefore relying on attackers being slower than the published averages.
Plugin and Theme Exposure
WordPress runs on about 40% of all websites, and for those sites the core software is the smaller part of the risk. The security firm Patchstack counted 7,966 new vulnerabilities in the WordPress ecosystem in 2024. Of those, 96% were in plugins and 4% in themes, with only 7 in WordPress core. Patchstack gave 11.6% of the year’s vulnerabilities its high priority score and 18.8% a medium score, and the remaining 69.6% were rated low. Low-priority flaws still accumulate on a site that is never updated.
Of the 2024 vulnerabilities, 43% could be exploited without logging in, which makes them suitable for automated scanning, and 33% were still unfixed by the developer when the flaw became public. An attacker who writes one working exploit for a popular plugin can test it against every site that runs the plugin without any manual effort.
Automatic Updates and Managed Plans
WordPress has installed minor core releases automatically since version 3.7 in 2013. Version 5.5, released in 2020, added optional automatic updates for individual plugins and themes, and that setting is switched off for each plugin until the owner turns it on. An owner who never opens the plugins screen can run code with a published flaw for months.
A managed plan from a wordPress hosting provider typically applies core releases and security patches on the owner’s behalf, and some plans extend that to plugins on a fixed schedule. The owner still decides which plugins are installed, and no provider can update a plugin whose developer has stopped releasing fixes.
Automatic plugin updates have a small risk of their own, since a new release can conflict with another plugin or with the theme. A recent backup limits that risk to the time it takes to restore, and a known flaw left in place has no such limit.
Abandoned Plugins and Unused Code
Patchstack’s 2024 count included 1,614 plugins and themes removed from the official repository because of unpatched security issues, and 1,450 of them had high or medium priority flaws. A removed plugin receives no further fixes, so a site that keeps it installed stays exposed to that flaw for as long as the files remain.
A deactivated plugin still has its files on the server, while a deleted one does not, and deleting plugins that are no longer used shortens the list of things that need updating. A quarterly review of the plugin list that checks the date of each plugin’s last release will catch most abandoned code, and the official plugin directory shows that date on every plugin’s page. Unused themes need the same review, because an inactive theme left in place is code on the server with no purpose for visitors.
Server Software Beneath the Site
The application depends on a programming language runtime that needs its own updates. W3Techs usage statistics for PHP in September 2026 show that 28.0% of sites using the language run version 7 and 7.8% still run version 5. PHP 7.4, the last release of version 7, stopped receiving security fixes in November 2022. The version a site uses appears in most control panels and in the Site Health screen that WordPress added in version 5.2.
Every PHP version older than 8.2 is now missing from the project’s list of supported versions, so newly found flaws in those versions will not be fixed, and security support for 8.2 itself ends on December 31, 2026. On a managed plan, the runtime is usually the provider’s job. On a self-managed server, it is the owner’s, and a runtime upgrade needs the same testing as a plugin update, since older plugins can break on a newer version. The web server software and the database need the same attention, and on a self-managed server they are updated through the operating system’s package manager.
A Workable Update Routine
A routine that holds up starts with a backup before each update round, stored away from the server so an intruder cannot delete it along with the site. Updates are then tested on a staging copy of the site before visitors see them, and a broken copy can be thrown away without affecting the live site. Security releases should go on the day they appear. Everything else can follow a weekly schedule, so no published fix waits longer than 7 days, which is close to Mandiant’s five-day average. Core updates go first, then plugins and themes, since plugin developers test against the current core release. A short log of what changed and when makes it possible to trace which update broke a feature.
Verizon’s 2026 Data Breach Investigations Report found that enterprises face a vulnerability glut, and exploited vulnerabilities were the most common way attackers first got into breached organizations, at 31% of cases. The median time to resolve a known-exploited flaw rose to 43 days from 32, and only 26% of those flaws were fully fixed during 2025. The report studies larger organizations, and automated scanning reaches small sites in the same way.
The Struts Patch in Hindsight
Equifax applied the Struts patch on July 30, 2017, 145 days after its release and a day after its security team noticed suspicious traffic on the portal. In September the Apache Software Foundation attributed the breach to Equifax’s failure to install patches that had been available since March. A small business site faces the same sequence at a smaller scale, with a fix published on day one and, on Mandiant’s 2023 average, a working attack by day five.
