On 14 October 2026, Microsoft released its monthly Patch Tuesday. The figure is unprecedented: 1,413 vulnerabilities patched in a single cycle. This is the highest volume ever recorded for a Patch Tuesday, according to tallies published by SecurityWeek and BleepingComputer on 13 October 2026. Among those patches, two flaws had already been publicly disclosed before a fix was available. One of them, CVE-2026-96951, affects a Windows security feature and was being actively exploited in production before the patch was released.
This figure does not arise in a vacuum. It reflects a structural trend: since the start of 2026, the pace of vulnerability disclosures has been accelerating, and the window between patch publication and active exploitation is narrowing.
When the exploitation window shrinks to a matter of hours
During the same week, CISA confirmed that a critical flaw in the WordPress plugin Bricksforge, rated CVSS 10.0, was being actively exploited. The flaw allows an unauthenticated attacker to execute code remotely on any WordPress site running an unpatched version. The first exploitation attempts were detected within hours of the security advisory being published.
Added to this are further advisories published between 8 and 13 October: a critical flaw in SonicWall SMA 1000, a maximum-severity vulnerability in GitLab CI/CD enabling remote code execution, and an authentication bypass in Fortinet FortiSandbox. Each of these products is deployed in infrastructures belonging to organisations subject to NIS2 or DORA.
What the regulation requires: 24 hours, not three weeks
The Cyber Resilience Act (CRA), whose reporting obligations have applied since 11 September 2026, requires manufacturers of digital products to notify ENISA and the relevant national CSIRT within 24 hours of discovering an actively exploited vulnerability. The full notification must follow within 72 hours.
NIS2 applies on its side to essential and important entities. In the event of a significant incident linked to an exploited vulnerability, Article 23 of the directive requires an early warning within 24 hours. Meeting these deadlines requires the organisation to know, in real time, which software components it runs and in which versions.
This is where the practical problem lies: if your software inventory is not current, you will not know that CVE-2026-96951 affects your Windows estate until your team reads about it in the trade press. The 24-hour window then becomes unachievable. Our article on SBOM and software inventory under NIS2 and DORA explains why knowing what runs in your estate is the non-negotiable prerequisite for any patch policy that will hold up to regulatory scrutiny.
A concrete example: the WordPress plugin exploited on day one
Consider Bricksforge. This plugin is used by web agencies to build visual interfaces on WordPress. Its users are not security professionals: they are marketing teams, small businesses, local authorities. When a flaw is disclosed at CVSS 10.0, the question is not whether to patch it, but whether the organisation has an automatic mechanism to detect the presence of that plugin across its estate and trigger the update before the first exploitation attempts reach its infrastructure.
Without an automated inventory of the components installed on the sites you manage or host, that question goes unanswered for days. Meanwhile, attackers' automated scanners do not wait.
If you entrust the maintenance of your websites to a third party, verify that the maintenance contract explicitly covers security update monitoring and the deployment of critical patches within a contractually defined deadline.
Manual patch management cannot work at this volume
A Patch Tuesday exceeding 1,400 CVEs means security teams must sort, qualify, and prioritise every patch within days. At this volume, a purely manual process inevitably produces delays. Some critical patches will wait weeks because they were overwhelmed by the flow.
Operationally viable approaches combine several mechanisms.
- A software inventory kept current in real time (SBOM or equivalent), linking each CVE to the components actually present in your estate.
- A priority score that accounts for the CVSS rating, confirmed active exploitation in CISA's Known Exploited Vulnerabilities catalogue, and the actual presence of the component in your environment.
- Differentiated approval circuits: a critical patch on a component exposed to the internet must not follow the same validation cycle as a functional update.
- Automated non-regression tests for fast-track patches, so that addressing a vulnerability does not introduce a service outage.
What the CVE volume reveals about technical debt
The figure of 1,413 CVEs in one month reflects the state of the global software estate: research teams are finding more vulnerabilities, publishers are fixing more, and attackers are investing in detecting the window between disclosure and patch deployment.
For organisations subject to NIS2, this volume raises a direct documentary question. Can you produce, in the event of an audit or incident, proof that you addressed every CVE applicable to your scope within a reasonable time? A manually maintained patch log, completed sporadically, will not constitute satisfactory evidence before a national competent authority.
Strengthening your patching posture is not simply a matter of tooling. It requires an organisational decision: who owns the inventory, who decides on prioritisation, and what maximum time is acceptable for each criticality level. These three elements must appear in your formal security policy, as required by Article 21 of the NIS2 Directive.
For further guidance on setting up structured vulnerability management, our security tooling integration service covers the selection and deployment of mechanisms suited to your environment and your regulatory obligations.