In mid-October 2026, several critical vulnerabilities were published within a few days in components that run a large part of the web: Node.js, PHP, NGINX and the Linux kernel. Some allow code to run on a server without any authentication. For an application in production, everything then depends on how long it takes to apply the fix everywhere.
One week of alerts, October 2026
- 14 OctNGINXMemory corruptionFive vulnerabilities fixed, one of them in HTTP/3 support.
- 20 OctHTTP/3Denial of serviceA single connection can exhaust a server's memory: 7 of the 10 implementations tested were vulnerable.
- 21 OctNode.jsCode executionTen vulnerabilities fixed, including remote code execution. Node.js 20 no longer receives fixes.
- 21 OctPHP “PHP2Shell”Code executionUnauthenticated code execution, demonstrated on WordPress, Drupal and Magento. PHP runs 69% of websites whose server-side language is known.
- 21 OctLinux KSMBDCode executionTwo vulnerabilities rated 9.0 out of 10, disclosed before any fix.
- 21 OctLiteLLMKey theftA compromised release of this AI library was published to steal API keys.
The window between patch and attack has closed
A few years ago, attackers took weeks to exploit a known flaw. That delay is now counted in days, and exploitation sometimes begins before a fix exists.
Average time to exploit a vulnerability, relative to its patch
63 days after the patch in 2018–2019, five days in 2023. In 2025, exploitation precedes the patch by about a week on average, according to an estimate.
| Period | Average time |
|---|---|
| 2018–2019 | 63 days |
| 2020 – early 2021 | 44 days |
| 2021–2022 | 32 days |
| 2023 | 5 days |
| 2025 (estimate) | 7 days before |
In the third quarter of 2026, Rapid7 measured an average of three days between the disclosure of a serious vulnerability and its exploitation. A monthly update cycle therefore leaves several weeks of exposure.
AI speeds up vulnerability discovery
Models that can read code now find vulnerabilities at scale. Anthropic has reported more than 6,000 vulnerabilities in open-source projects, according to its 
CVD dashboard, and the Node.js flaw fixed on 21 October was found by OpenAI's Codex Security team. Attackers use the same tools.
The effect of AI on vulnerabilities in 2026
Vulnerabilities disclosed per month
January 20265,045August 202610,740Vulnerabilities exploited per month
2025 average10.5January–August 202618Share of flaws allowing remote code execution
Found with AI50%Other flaws26%Flaws also become public sooner: the Linux kernel's 
Security bugs guide now asks reporters to treat any flaw found with AI as public, because several researchers often discover it on the same day. Only a small share of published flaws is actually exploited, so recognising the one that matters quickly is key.
Applications that build in AI add their own risks, such as prompt injection 
LLM01 Prompt Injection or a compromised supply chain LLM03 Supply Chain. They need the same maintenance as the rest of the application.
Patch fast, and everywhere
A fix is a single update. The work lies in making sure it reaches every place where the software runs, without breaking anything.
Good practices for a critical vulnerability
- 1.Take inventoryEverything that runs, including what the admin interface does not show: services started outside it, stopped services, software installed directly on the server.
- 2.PrioritiseFirst what is exposed to the internet, and what a flaw can reach without authentication.
- 3.Patch separatelyA fix prepared from the version in production, without work in progress. The same change then joins the version under development.
- 4.Cover the copies tooTest and staging environments, backups, standby copies. A stopped service is patched before it is restarted.
- 5.Check what actually runsThe version really executed, not the one stated in the configuration, then the service's health after each change.
- 6.Keep a recordEach action and its result are written down, so the work can be resumed, explained and rolled back.
Protecting an application before the fix arrives
When a flaw is published before its fix, several layers of protection leave time to patch calmly.
Four layers of protection around the application
Expose as little as possible
Only services that must be public can be reached; administration goes through private access.
Update automatically
Operating system security updates, dependency update proposals and regular checks of the versions in service.
Filter traffic
An application firewall blocks known attacks while the fix is pending.
Limit the damage
Minimal rights, read-only files and detection of abnormal behaviour.
Your application
When no fix is available, as with this week's Linux kernel flaws, expertise makes the difference: checking whether the vulnerable service is running and reachable, then switching it off or closing its access in the meantime.
Maintain to respond fast
An up-to-date application on maintained versions can be patched in a few hours. An application left without upkeep for a long time first needs a migration, sometimes a risky one, before it can even receive the fix. That is the case for applications still running Node.js 20, which has reached end of life according to the 
Node.js Release schedule, or PHP 7, which is no longer maintained either.
A checklist for your applications
- Inventory. Do you know where each application runs, including test environments, stopped services and backups?
- Versions. Do you know which versions are actually running and when their support ends?
- Monitoring. Who receives the security advisories for your technologies, and who decides what happens next?
- Deployment. Can you put a fix into production on its own, without work in progress?
- Verification. After an update, do you check the active version and the health of the service?
- Fallback. Can you isolate a vulnerable service when no fix exists yet?
- AI features. Do your assistants have only the access they need, and can their keys be renewed quickly?
Maintenance and hosting
We maintain and host the applications we develop, and can take over applications built by other teams. To find out where your application stands against these risks, get in touch: we start with an inventory.
Sources and references
18 sourcesNode.js · NGINX · FoxIO · PHP · Help Net Security · +10
- Node.jsSecurity releases of 21 October 2026nodejs.org
- Node.jsRelease schedule and end of life of Node.js 20github.com
- NGINXSecurity advisories, including the 14 October 2026 fixesnginx.org
- FoxIOQPACK amplification attacks against HTTP/3, 20 October 2026, ten implementations testedfoxio.io
- PHPSecurity advisory of 21 October 2026 (CVE-2026-109618 and CVE-2026-109619)php.net
- Help Net SecuritySearchlight Cyber's PHP2Shell scanner, 22 October 2026helpnetsecurity.com
- W3TechsPHP share of websites whose server-side language is known, 25 October 2026w3techs.com
- Zero Day InitiativeUpcoming advisories, including ZDI-CAN-33549 and ZDI-CAN-33774 (Linux, 21 October 2026)zerodayinitiative.com
- ScyScanKSMBD flaws disclosed before any kernel fix, 22 October 2026scyscan.com
- Linux kernelReporting security bugs, including bugs found with AIdocs.kernel.org
- Google Threat IntelligenceTime-to-exploit trends 2018–2023, exploited vulnerabilities tracked by Mandiantcloud.google.com
- MandiantM-Trends 2026, incident investigations conducted in 2025, time-to-exploit estimatecloud.google.com
- Rapid7Q3 2026 threat update, 43 newly exploited high- and critical-severity vulnerabilitiesrapid7.com
- Google Threat Intelligence GroupVulnerability discovery and exploitation trends in the AI era, January 2025 – August 2026cloud.google.com
- AnthropicCoordinated vulnerability disclosure dashboard, as of 2 October 2026red.anthropic.com
- OWASPPrompt injection (LLM01:2025)genai.owasp.org
- OWASPSupply chain (LLM03:2025)genai.owasp.org
- Help Net SecurityLiteLLM supply chain attack, 22 October 2026helpnetsecurity.com
vibe coding
Swiss Made Software