AI Is Uncovering Years-Old Security Flaws Faster Than Websites Can Be Patched
October 2026 brought one of the heaviest waves of critical security fixes on record. The cause is not a sudden decline in software quality. AI-assisted research is now finding flaws that have sat unnoticed in widely used software for more than a decade, and it is finding them faster than most websites are being updated.
Why this is happening now
AI systems can now read source code, reason about how it fails, and produce working proof of an exploit, at a scale no human team can match. The effect shows in the patch volumes:
- Microsoft fixed roughly 1,400 vulnerabilities in its October update, more than in any previous full year.
- Oracle's October Critical Patch Update addressed 1,209 CVEs.
- The researchers behind the most serious web flaw of the month, in PHP, said they used AI models in their research.
Two features make this wave more dangerous than earlier ones.
The flaws are old. The PHP code path exploited this month dates back to PHP 5.4.0, released in 2012. The nginx flaw disclosed in May affects versions going back to 0.6.27, released in 2008. These flaws have been present in production systems for years. Every website still running an unpatched version has been exposed the whole time; what has changed is that the flaws are now publicly known.
The window between disclosure and attack has collapsed. Amazon Threat Intelligence observed an attempt to exploit the PHP flaw on 17 October, four days before public disclosure, and reports that it is now being broadly exploited in the wild.
The vulnerabilities
PHP: "php2shell" (fixed 21 October 2026)
| CVE | What it is | Severity |
|---|---|---|
| CVE-2026-109618 | When PHP runs out of memory while its internal request data is only partly initialised, the cleanup that follows treats that data as valid, allowing remote code execution. | CVSS v4 9.2 (Critical) |
| CVE-2026-109619 | Use-after-free: state left over from one request points to freed memory, and a later request handled by the same worker can use it. Allows remote code execution and memory disclosure. | CVSS v4 9.2 (Critical) |
- No login needed. Both flaws can be exploited by an unauthenticated remote attacker. With Apache mod_php, a demonstrated exploit runs before any application code executes, so the website's own login and password protection offer no defence.
- Affected: every PHP installation that serves web requests, including PHP-FPM, Apache mod_php (highest risk), php-cgi, FrankenPHP and LiteSpeed. WordPress, WooCommerce, Drupal, Joomla, Magento and Laravel all run on PHP.
- Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
- Older versions:
- PHP 7.4 to 8.1 receive only source-code patches, with no official release.
- PHP 5.4 to 7.3 receive no fix at all.
- No complete workaround. The PHP security team states that updating is the only complete fix. The configuration changes it lists reduce exposure to specific attack paths but do not make an installation safe.
.NET / ASP.NET Core: October security update (13 October 2026, 46 CVEs)
| CVE | What it is | Severity |
|---|---|---|
| CVE-2026-105016 | Heap overflow in Microsoft QUIC (HTTP/3 on Windows); no authentication required. | CVSS 9.8 (Critical) |
| CVE-2026-88092 | Kestrel HTTP/1 request smuggling: an aborted connection can cause unread body bytes to be parsed as a new request. Highest risk when Kestrel sits behind a reverse proxy or load balancer. | CVSS 9.4 |
| CVE-2026-70188 | Kestrel HTTP/2 accepts newline characters in trailers and HPACK values. | CVSS 9.1 |
| CVE-2026-70175 | ASP.NET Core Identity can send a password-reset email to the address typed in the request rather than the address stored on the account. | CVSS 8.1 |
- Fixed in: .NET 10.0.13, 9.0.21 and 8.0.32. As of 14 October, Microsoft had not marked any of the 46 as exploited.
- Two catches:
- The Identity fix does not reach account pages generated from the Blazor template into an application's own code. Those pages must be changed by hand.
- .NET 8 and .NET 9 reach end of support on 10 November 2026. After that date, new flaws on those versions will not be fixed.
nginx: "NGINX Rift" (CVE-2026-42945, disclosed May 2026)
| CVE | What it is | Severity |
|---|---|---|
| CVE-2026-42945 | Heap buffer overflow in nginx's rewrite module, triggered by an unauthenticated HTTP request. | Critical |
- Conditions: the flaw is exploitable only when the configuration uses
rewrite,iforsetwith unnamed regular-expression captures (such as$1) and the replacement string contains a question mark. Many real-world configurations do. - Impact:
- Most likely: repeated crashes of nginx worker processes (denial of service).
- Possible but much harder: remote code execution, which requires bypassing memory-randomisation defences.
- Fixed in: nginx 1.30.1 and 1.31.0. Versions 0.6.27 to 0.9.7 will not receive a patch.
- Hidden copies: products that bundle their own copy of nginx do not update when the operating system's nginx package is updated. Each one needs its own update.
Which websites are affected
The three products above are the ones with the most serious web-facing flaws this month. They are not the only software a website depends on. A website is a stack of components, and any of them can carry the same kind of long-hidden flaw. If your site does not use PHP, .NET or nginx, that does not make it safe. It only means this article does not cover the components you rely on.
Most exposed (covered above)
- WordPress, WooCommerce, Drupal, Joomla, Magento or custom PHP sites on a server or hosting plan that has not been updated recently, especially those still on PHP 8.1 or earlier.
- Custom web applications built on ASP.NET Core 8 or 9, particularly those deployed in containers that have not been rebuilt since 13 October.
- Websites on a virtual or physical server where nginx was installed and configured by a developer who is no longer involved.
Not covered here, but worth checking
Every layer below can have its own security advisories, and the same AI-assisted research that found the flaws above is being applied to all of them. This article did not assess them, so check each one against its vendor's own security notices.
| Layer | Examples | What to check |
|---|---|---|
| Other languages and runtimes | Node.js, Python, Ruby, Java, Go | The runtime version, and whether it is still supported |
| Application frameworks | Django, Rails, Spring, Express, Laravel, Next.js | The framework version and its published security releases |
| Other web servers and proxies | Apache, IIS, Caddy, HAProxy, Traefik | Updates to the server itself, not only its configuration |
| Libraries and dependencies | npm, pip, Composer, NuGet and Maven packages | Dependency audit results; bundled and transitive packages are often forgotten |
| Operating system and base images | Ubuntu, Debian, RHEL, Windows Server, container base images | Pending OS updates; containers do not update until they are rebuilt |
| Database and cache | MySQL, PostgreSQL, SQL Server, MongoDB, Redis | Version, and whether the database is reachable from the internet |
| Control panels and admin tools | cPanel, Plesk, phpMyAdmin, hosting dashboards | Whether they are exposed publicly; these are frequent targets |
| Plugins, themes and extensions | WordPress, Joomla, Drupal and Magento add-ons | Abandoned or unmaintained add-ons are the weakest point |
| Third-party scripts and services | Payment, chat, analytics, form and booking widgets | Who maintains them, and what they can access on your pages |
| Network and infrastructure | VPNs, firewalls, routers, load balancers, remote-access tools | Firmware and software updates on any device that faces the internet |
Two points hold across the whole stack:
- Age is not safety. Software that has run without trouble for years is not proven secure. It may simply not have been examined by anyone, or anything, capable of finding the flaw.
- Unmaintained software is the highest risk. Anything that no longer receives security fixes, such as the PHP 5.4 to 7.3 and nginx 0.6.27 to 0.9.7 versions mentioned above, stays exposed once a flaw is public.
Usually not affected at the engine level
- Fully hosted platforms such as Wix, Squarespace and Shopify. These providers update their own infrastructure. Third-party apps, custom code and embedded scripts you add on top remain your responsibility.
Depends on the host
- Shared and managed hosting. Many hosts apply patched PHP packages themselves, sometimes under a version number that looks old. Only the host can confirm whether the 21 October fixes have been applied to your site. The same applies to every other component the host manages for you.
What to do
- Identify what your website runs on: every layer in the table above, not only PHP, .NET and nginx. Your hosting provider or developer can tell you; if neither can, treat that as a risk in itself.
- Update PHP to a fixed version, or obtain written confirmation from your host that the fixes have been applied.
- If you cannot update immediately, take the website offline or isolate it from the public internet until it is fixed, as CERT-EU recommends. A few days offline costs less than recovering a compromised server.
- For .NET applications: update the runtime, rebuild and redeploy any container images, and plan the move to .NET 10 before 10 November.
- For nginx: update to a fixed version, and check any product that bundles its own copy of nginx.
- Treat CDN or firewall rules as a stopgap only. They filter only the traffic that passes through them and do not fix the flaw underneath.
- For every other component, subscribe to its vendor's security notices and keep a list of what you run and who is responsible for updating it. Replace anything that no longer receives security fixes.