CVEs Doubled in 2026: What to Patch in Next.js, Node.js and PHP

In the space of a week in October 2026, all three of the most common web app stacks needed an urgent patch. On 14 October, Next.js shipped fixes for two critical remote code execution flaws. On 21 October, Node.js patched a bug in its Brotli decoder that can lead to remote code execution. The same day, PHP released fixes for "PHP2Shell", two flaws that let an attacker run code on a PHP server without logging in, and that were already being exploited.

That week was not a fluke. It was what 2026 has looked like all year. This post covers how many vulnerabilities were published, why the number roughly doubled, why most of them will never touch your app, and exactly what to patch now if you run Next.js, Node.js or PHP.

How many CVEs were published in 2026?

The US National Vulnerability Database (NVD) lists 86,533 CVEs published between 1 January and 25 October 2026, against 48,151 in the whole of 2025, according to an analysis of NVD data by Brandefense. At around 290 a day, 2026 is running at more than twice last year's pace.

The growth also sped up through the year. Empirical Security counted 4,335 new CVEs in January and 14,961 in September, more than three times as many in a single month. Google's threat intelligence team saw the same curve, with monthly disclosures roughly doubling between January and August.

Why vulnerabilities doubled in 2026

There is no single cause. Four things are pushing the number up at once.

1. AI is finding bugs faster than people can

This is the new one. Security teams now point AI agents at code and get back real vulnerabilities at a pace no human team could match. FIRST, the global body for incident response teams, describes 2026 as the start of an AI discovery era: Mozilla, for example, used an agent built on Anthropic's Claude models to find and fix 271 bugs for a single Firefox release.

You can see it in this month's patches. The Node.js Brotli flaw (CVE-2026-111497) was reported by OpenAI's Codex Security team. Google's researchers also found that AI-assisted discovery turns up proportionally more serious bugs, including more that lead to remote code execution, not just more noise.

2. More organisations are issuing CVE numbers

A CVE is assigned by a CVE Numbering Authority. Brandefense counts 559 of them now, up from 263 at the end of 2022. GitHub's security advisory team and others have also been backfilling CVE IDs for older issues that never had one, which adds to this year's total without any new bug being found.

3. Some projects assign a CVE to almost every fix

The Linux kernel is the clearest example. Google counted roughly 5,000 CVEs mentioning the Linux kernel between January and August 2026, and not one of them was observed being exploited as a zero-day. These are real fixes, but they inflate the count far more than the risk.

4. The database cannot keep up

NIST, which runs the NVD, says CVE submissions rose 263% between 2020 and 2025. In April it changed how it works: it now prioritises the most critical CVEs, and moved its backlog of older unanalysed entries into a "Not Scheduled" category. In practice, a growing share of CVEs will never get an NVD severity score, so if your process waits for one, it will wait forever.

Most of these CVEs will never touch your app

The useful news is that the number of vulnerabilities attackers actually use has grown far more slowly than the pile.

• Empirical Security found that of 83,167 CVEs published in 2026 up to 19 October, attackers had been seen exploiting 696, about one in 119.
• Google put it at 0.23% of 2026 disclosures, roughly one in 431, observed in active exploitation.
• CISA's catalogue of known exploited vulnerabilities, the list US federal agencies must patch, added 272 entries in 2026 to late October, against 245 in all of 2025.

Exploitation is still rising, from an average of 10.5 newly exploited vulnerabilities a month in 2025 to 18 a month in 2026 by Google's count. But it is tens a month, not thousands.

The type of flaw matters too. In Empirical's data, cross-site scripting was the biggest category of 2026, with 7,355 CVEs and only 21 exploited. Operating-system command injection had 2,016 CVEs and 68 exploited, a rate about twelve times higher. Bugs that let an attacker run code on your server are the ones to drop everything for.

One more finding is worth sitting with: of the 109 vulnerabilities first exploited in one recent week, 61 were published before 2026. Attackers go after what people never patched, not just what is new.

What this means for you: do not try to read every CVE. Watch for three things: a flaw is being exploited, it lets someone run code or read data, and it sits on something your app exposes to the internet. When all three are true, patch the same day.

What to patch now if you run Next.js

On 14 October 2026 Next.js released an out-of-band security update for three issues:

• Remote code execution in use cache functions (GHSA-673q-mjm6-r5xr, critical, 9.5). Affects Next.js 16.0.0 to 16.4.0 using the App Router with Cache Components. There is no workaround.
• Remote code execution in the Image Optimization API with SVG files (CVE-2026-96889, critical). Caused by a memory bug in an image library that sharp uses on glibc-based Linux. Affects Next.js 10.0.0 to 15.5.27 and 16.0.0 to 16.4.0. NHS England's security team reported a public proof-of-concept exploit.
• Denial of service through Server Actions (GHSA-p3m5-59mp-jv5r, high). Crafted requests can pin the CPU and stall the app.

Fix: upgrade to Next.js 15.5.28 or 16.4.1. If you cannot upgrade straight away, make sure the sharp version Next.js uses is 0.35.5 or later, which closes the image flaw only.

npm install next@16.4.1    # on 16.x
npm install next@15.5.28   # on 15.x
npm ls sharp               # should show 0.35.5 or later

If your app is on Next.js 13 or 14, there is no patched release on those lines for the image flaw, so plan the upgrade to 15.5.28 or later. And if you never patched React2Shell (CVE-2025-55182, rated 10.0, disclosed in December 2025), you are a year behind on the most serious bug the framework has had. The Next.js team's advice after that one was to rotate every secret the app uses once patched, and it is good advice after any remote code execution fix.

What to patch now if you run Node.js

The 21 October Node.js security release fixed ten issues across the 22, 24 and 26 release lines. The one to care about:

• Brotli decoder out-of-bounds write (CVE-2026-111497). If your app decompresses Brotli data that an attacker can supply using node:zlib, the attacker can corrupt memory, which can lead to a crash, a memory leak or remote code execution. Node.js rates it high. Singapore's Cyber Security Agency scores it 9.8 out of 10.

The same release fixed two high-severity TLS hostname verification bypasses and a DNS resolution flaw that can make an allowlist check approve the wrong domain.

Fix: upgrade to Node.js 22.23.4, 24.22.1 or 26.12.1.

node -v   # check every place your app runs, not just your laptop

Three things catch teams out here:

• Node.js 20 is end of life and will not get this fix. If you are on 20, the only fix is moving to 22 or 24.
• The runtime lives in more places than you think: Docker base images, CI runners, serverless function settings and self-hosted servers. Updating package.json changes none of them. Rebuild your images.
• Managed hosting may patch for you, or may not. Vercel, for example, says it rolls patch versions for Node.js 22 and 24 but not for 20. Check your provider's notice.

What to patch now if you run PHP

PHP2Shell is the most urgent item in this post, because it is already being exploited.

• What it is: two use-after-free flaws, CVE-2026-109618 and CVE-2026-109619, that allow unauthenticated remote code execution with the web server's privileges. Sophos rates them 9.2 on CVSS v4.
• Who is affected: every PHP installation serving web requests, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The PHP project considers mod_php the highest risk, because one flaw can be triggered before any of your application code runs. That means a security plugin or in-app firewall may not stop it.
• Timeline: Amazon's threat intelligence team saw an exploitation attempt on 17 October, before the flaws were public. Details leaked on 20 October, fixes shipped on 21 October, and CISA added both to its known exploited list on 26 October.

Fix: upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every PHP worker.

php -v   # the CLI version can differ from the one serving web requests

Check the version that actually serves your site, for example with a temporary phpinfo() page that you delete afterwards, because the command-line PHP and the web server's PHP are often different installs. PHP 8.1 and older are end of life. The PHP project published source-only backports for 7.4, 8.0 and 8.1, but the real fix is moving to a supported branch.

This covers WordPress, Laravel, Magento and anything else running on PHP. If you are on shared or managed hosting, confirm with your host that they have updated, rather than assuming.

The other half: your npm dependencies

Patching known CVEs protects you from bugs. It does nothing about packages that were malicious from the moment you installed them.

In August 2026, Microsoft described ChainDrop, an npm supply chain attack that affected more than 400 packages. Its self-spreading malware ran from a preinstall script, stole npm, GitHub and cloud credentials from developer machines and build servers, then used stolen publishing tokens to push infected versions of other packages.

The practical defences:

• Commit your lockfile and install with npm ci in CI, so builds only use versions you have reviewed.
• Use the minimum release age setting in recent npm CLI versions, which Microsoft recommends, so brand-new versions of a package are not installed the moment they appear.
• Run CI installs with --ignore-scripts where your build allows it, since lifecycle scripts are how this kind of malware gets in.
• If you installed an affected version, treat that machine or build runner as compromised and rotate every credential it could reach.

A patch routine for a team without security staff

You do not need a security team to keep up with this. You need a routine.

1. Know what you run. For each app, write down the runtime version (Node.js, PHP), the framework version, where it is hosted, and who updates the runtime: you or your host.
2. Subscribe to the right feeds. Turn on GitHub Dependabot alerts, and follow the security pages for Next.js, Node.js and PHP. Add CISA's known exploited vulnerabilities catalogue for anything internet-facing.
3. Triage by exposure, not count. Same day: anything exploited, or anything that allows remote code execution on an internet-facing service. Within a week: other high-severity issues in code you actually use. Monthly: everything else, in one batch.
4. Automate the boring part. Dependabot or Renovate for update pull requests, a dependency audit in CI, and container images rebuilt on a schedule so they pick up base image fixes.
5. Rotate secrets after a code execution fix. If an attacker could have run code on the server, assume they could have read its environment variables.
6. Stay on supported versions. Node.js 20 and PHP 8.1 are already out of support. Put the end-of-life dates for your stack in the calendar.

Who is most exposed: apps nobody is watching

The apps most at risk from all this are not the big ones with a security team. They are the ones nobody is maintaining: the MVP that launched and then lost its developer, the app an agency handed over with no support plan, and especially apps built with AI coding tools like Lovable, Bolt or Cursor, which are pinned to whatever package versions the AI picked on the day it wrote the code.

If that sounds like your app, our free audit for vibe-coded apps includes a dependency scan against known CVEs, with the exact versions to move to, in under 24 hours. Our vibe coded app security checklist covers the rest of what to check yourself. And if you would rather hand the whole routine to someone, the Pyramidions app development team offers maintenance plans that keep apps patched, monitored and backed up.

FAQ

How many CVEs were published in 2026?

The NVD lists 86,533 CVEs published between 1 January and 25 October 2026, according to Brandefense's analysis, compared with 48,151 for the whole of 2025. Monthly volume more than tripled between January and September.

Why are CVEs increasing so fast?

Four reasons: AI tools are finding real bugs at a scale people cannot, more organisations are now allowed to issue CVE numbers, some large projects such as the Linux kernel assign a CVE to almost every fix, and older issues are being given CVE IDs retroactively. The first one also means more of the new bugs are serious.

Do I need to patch every CVE?

No. Only a small fraction, under 1% of 2026 CVEs by every count above, has been seen exploited. Patch first anything that is being exploited, allows remote code execution, or affects a service exposed to the internet. Batch the rest on a regular schedule.

Is my Next.js app affected by the October 2026 vulnerabilities?

If you run Next.js 10.0.0 to 15.5.27 or 16.0.0 to 16.4.0, at least one of the three October issues applies to your version. The image optimization flaw affects both ranges when Next.js runs on glibc-based Linux, and the use cache flaw affects 16.x apps using Cache Components. Upgrading to 15.5.28 or 16.4.1 fixes all three.

How do I check if my server is affected by PHP2Shell?

Check the PHP version that serves web requests, not just the command-line version: a temporary phpinfo() page is the reliable way. Anything below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 is affected, as is every version of PHP 8.1 and older. If you use managed hosting, ask your host to confirm they have patched.