WordPress Patch Window: 5 Hours to Attack

Security was traditionally explained through the sheer volume of vulnerabilities. That volume keeps growing: in 2025 alone, the Patchstack annual report recorded 11,334 new WordPress vulnerabilities, a rise of about 42 percent over the previous year (Patchstack, 2026). Of these, 1,966 were rated high - an increase of 113 percent in serious flaws (Patchstack, 2026). But volume alone does not explain the risk. What matters is how quickly a published flaw turns into a running attack.

This is exactly where something shifted fundamentally in 2026. Once a vulnerability and often a sample exploit are public, automated tools begin scanning the internet for vulnerable installations - the first opportunistic scanning for a newly published flaw typically starts after around 15 minutes (Palo Alto Networks Unit 42). The window between disclosure and exploitation has collapsed accordingly: for the most exposed, actively targeted flaws the median time from disclosure to mass exploitation is now zero days - exploitation begins on the very day a vulnerability becomes public (GreyNoise, 2025). Attackers operate with automation at machine speed, while the defense often still runs at the cadence of manual maintenance.

The term zero-day is often misleading here. Most successful attacks on online shops do not use secret, unknown flaws but already published and even patched vulnerabilities - so-called N-day flaws, where only the deployment of the available patch is missing. The combination of 11,334 new flaws per year (Patchstack, 2026) and a median of five hours to exploitation means that what matters is less exotic attacks than the plain discipline of applying known updates quickly and reliably. That discipline is hard to sustain in the daily business of a shop, because it has to work around the clock and independently of holidays, illness or the end of the working day.

For an online shop this weighs especially heavily. Here not only availability but also payment data and personal customer data are at stake. A compromised shop means, in the worst case, leaking order data, manipulated payment pages or a complete outage during live operation. How expensive such an outage gets is shown in our breakdown of downtime costs for online shops - recovery after an incident is usually considerably more elaborate than applying a patch in time.

The dynamic after a disclosure follows a recurring pattern. First automated systems evaluate the new vulnerability, then broad scanning begins, finally mass exploitation. Among heavily attacked flaws, Patchstack puts the distribution at 20 percent within six hours, 45 percent within 24 hours and 70 percent within seven days (Patchstack, 2026). This means anyone who only responds at the weekly maintenance slot regularly arrives too late for the most dangerous flaws.

What makes it worse is that the flaw is often not even fixed at the time of disclosure. 46 percent of vulnerabilities were still unpatched at disclosure (Patchstack, 2026) - in these cases there is initially no update to apply, only an open window. Commercial extensions are especially affected: 76 percent of vulnerabilities reported in paid components were exploitable in real-world attacks (Patchstack, 2026), and such components often have to be updated outside the automatic update channels.

From this follows an uncomfortable insight: in 2026 the risk lies less in whether a flaw is discovered than in how fast your own shop responds. Two shops with identical software can sit in completely different risk - depending solely on whether someone notices the disclosure within the first hours and acts. The patch window shifts the competitive edge from pure technology toward the response organization. Whoever has the organization to patch in hours rather than days lowers their risk regardless of how many new flaws are added per year.

A managed maintenance contract reverses the logic: instead of an operator checking occasionally, a continuous process runs with clear ownership and fixed response times. The first building block is ongoing monitoring of the relevant vulnerability feeds, matched against a complete inventory of all components in use. When a new flaw hits an extension used in the shop, it triggers a defined response - not at the next routine slot, but immediately. The principles of this orderly approach are described in detail in our article on CVE and patch management for online shops.

The second building block is risk assessment. Not every one of the more than 11,000 annual flaws (Patchstack, 2026) is equally urgent. An actively exploited, highly rated flaw in an externally reachable component is brought forward, an uncritical one in a non-exposed module is bundled into the regular rhythm. This prioritization ensures the scarce response time is spent where the window is truly burning.

The third building block is controlled deployment. Even a rush patch is first tested on a staging environment against the business-critical paths - checkout, payment, search and cart - before it goes live. Before go-live, a database snapshot and a file system backup are created so a rollback is possible within minutes if needed. For actively exploited flaws there is a shortened emergency path with the minimum necessary testing and close monitoring after deployment.

A fourth, often underestimated building block is the follow-up. After every rush patch, it is recorded which flaw was closed, when it was published and when it was applied - and above all how large the actual window between disclosure and closure was in the specific case. Over time this produces a measurable metric for your own responsiveness. This metric is valuable not only for internal steering but also as solid evidence toward auditors, payment providers and insurers, who increasingly ask for documented patch processes. The mere closing of a flaw thereby becomes a traceable, verifiable operation.