WebAziz
About UsHire DevelopersBlogsContact Us
PHP2Shell and the Vercel Outage: What Actually Happened in October 2026

PHP2Shell and the Vercel Outage: What Actually Happened in October 2026

Sameer Ahmed Oct 22, 2026 9 min read

If your phone filled up with "is our site safe?" messages this week, you were not alone.

On Wednesday, 21 October, school platforms, hospital websites and government portals across Europe started showing maintenance pages. None of them had been hacked. They were patching PHP, the language that still runs a huge share of the web, after two critical flaws nicknamed PHP2Shell went public.

Nine days earlier, on 12 October, Vercel had its own bad afternoon. Builds and deployments failed or sat in a queue for more than six hours, and teams that needed to ship a fix could not.

These were very different events. One was a security emergency where site owners chose to go offline. The other was a platform incident where live sites mostly carried on but nobody could deploy. It is worth separating them, because the lessons are different.

On 21 October, many PHP sites went into maintenance mode while their owners patched.
On 21 October, many PHP sites went into maintenance mode while their owners patched.

Part 1: PHP2Shell

What the bugs are

PHP2Shell is two vulnerabilities, both rated 9.2 (CVSS v4.0) by the PHP project:

  • CVE-2026-109618, "RCE via OOM corruption". When PHP runs out of memory at the wrong moment, it can be interrupted while internal request data is only partly set up. The clean-up code then treats that half-built data as valid.
  • CVE-2026-109619, "RCE via stale global state". Some request data can outlive the memory behind it. A later request handled by the same worker may pick up that stale state before it is reset.

In both cases an attacker can run their own code on your server without logging in. That is what "RCE" (remote code execution) means. Calif, the research firm that found the first bug, says the attack works by shaping requests to push PHP's memory use, for example large lengthless multipart uploads or thousands of nested empty file fields. That is why sites without any upload form were still exposed.

Who is affected

The short answer is nearly everyone who runs PHP on a web server. The PHP project lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and says the risk is highest for mod_php. Calif traced the earliest vulnerable code back to PHP 5.4 and says the bugs are exploitable "under default configurations".

Censys counted about 2.58 million internet-facing hosts and 54.9 million web properties running PHP. That covers WordPress, WooCommerce, Magento, Drupal, Laravel apps, cPanel tools and countless internal admin panels.

Why sites went offline

The fixes came out on 21 October at 14:00 UTC in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Cloudflare said it had already seen some exploitation and had pushed firewall rules at 03:02 UTC that morning. Its CTO called those rules a stopgap.

Belgium's Centre for Cybersecurity and CERT-EU advised taking sites offline or isolating them if they could not be patched right away. Many organisations did exactly that. The Brussels Times reported that Smartschool, Flemish government websites, the Flemish Parliament, the Belgian Ministry of Foreign Affairs and AZ Monica hospital all went offline. Reuters reported government sites elsewhere in Europe doing the same.

So "the internet going dark" headlines were overblown. Most of these sites chose short, planned downtime because it was the safe call. A maintenance page that lasts two hours is far cheaper than a web shell that stays on your server for two months.

The AI angle

This is the part people will keep talking about. Calif says it found the first bug in August, a few days into an audit, using generally available AI models with no special setup. The work ran under OpenAI's "Patch the Planet" programme, with Wiz also credited. Wiz said the flaws had been in PHP for years but were very hard to exploit until AI models "substantially reduced that barrier".

The uncomfortable takeaway is that attackers have the same tools. Old, boring code that nobody looked at closely is now cheap to look at. Expect more disclosures like this, and expect shorter gaps between a patch and working exploits.

What to do if you run PHP

  1. Find every PHP install. Not just the main website, but the staging server, the old microsite, the admin panel someone set up in 2019, and any PHP-based tools like phpMyAdmin.
  2. Patch PHP itself. Updating WordPress or its plugins is not the same as updating PHP. Check the version your server actually runs (php -v or a phpinfo page you then delete), and confirm it is 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a distribution package with the fix backported. Ubuntu has already shipped one.
  3. If you are on PHP 8.1 or older, the PHP project no longer ships fixes. Use your distribution or host's backported package if there is one, and plan the upgrade now. PHP 8.2 itself reaches end of life on 31 December 2026.
  4. On managed hosting, get it in writing. Ask your host to confirm the fix is installed, not just scheduled, on every site and server you have with them.
  5. If you cannot patch today, the PHP project lists partial mitigations: set session.upload_progress.enabled=0 and restart every worker, keep post_max_size tight, and cap request size, part count and header count at your web server or proxy. It is clear these reduce risk but do not make you safe.
  6. Check for signs of compromise. Look for unfamiliar PHP files in upload and cache folders, new admin users, and odd outbound connections since around 21 October.

Part 2: The Vercel outage

During the 12 October incident, the problem was shipping new code, not serving the code already live.
During the 12 October incident, the problem was shipping new code, not serving the code already live.

What happened

On 12 October at 13:35 UTC, Vercel's status page reported that some customers were seeing build failures or deployments that would not start. The affected components were Builds and Git integrations.

The timeline from the status page:

Time (UTC)Update
13:35Investigating build failures and deployments failing to start
14:08Issue identified, fix in progress
14:57Failure rate down, but builds still queued and slow to start
16:10A GitHub incident is still breaking some GitHub-connected builds
18:33Deployment events, such as PR status updates, delayed while a backlog clears
19:56Backlog processed, monitoring
20:11Resolved, about 6 hours 36 minutes after the first update
← Scroll horizontally to view full table →

Vercel has not published a root cause for the first failures. The only cause it named was the upstream GitHub incident, which kept GitHub-connected projects failing for longer.

It was not a one-off either. Vercel's status history for the past month also shows a 16-minute login failure for pages with Deployment Protection (6 October), delayed logs, drains and Workflow runs in the Washington region (10 October), and a short Edge runtime build issue that caused some 500 errors (28 September).

Why it still matters if your site stayed up

The status page scoped this incident to builds and Git integrations, not to serving sites already in production. For most visitors, nothing looked wrong.

For the team behind the site, it was a different story. If you had a broken checkout, a typo in a price, or, say, a security fix to ship that afternoon, you could not. Imagine a security emergency like PHP2Shell landing on the same day your deploy pipeline is down. The trouble is not the outage itself. It is having no other way to ship.

Two very different bad days. PHP2Shell was a planned emergency; the Vercel incident was an unplanned pipeline outage.
Two very different bad days. PHP2Shell was a planned emergency; the Vercel incident was an unplanned pipeline outage.

What to set up before the next one

  • Know how to roll back without a build. On Vercel you can promote or roll back to a previous production deployment from the dashboard or CLI. That does not need a new build, so practise it once while things are calm.
  • Have a CLI deploy path. If Git integrations are the problem, vercel deploy --prebuilt from a machine or CI runner that can build locally may still get a fix out. Test it before you need it.
  • Subscribe to status pages. Vercel, GitHub, your DNS provider and your database host. Five minutes of setup saves an hour of "is it us?".
  • Don't let your provider's dashboard be your only monitor. A cheap external uptime check on your key pages and your checkout will tell you what your users actually see.
  • Write a one-page runbook. Who decides to roll back, who talks to customers, and where the status update goes.

The common thread

PHP2Shell and the Vercel incident have almost nothing in common technically. One is a decade-old memory bug in a language runtime. The other is a modern deploy platform having a rough afternoon. What they share is the question every team should be able to answer quickly: what do we run, who keeps it patched, and how do we ship a fix when the normal path is broken?

If the answer is "the developer who built it in 2021 might know", that is the real risk.

How WebAziz can help

We help companies in India, the US, the UK and the Middle East look after the sites and apps they already run. That means patching PHP, WordPress and Laravel stacks, upgrading out of unsupported PHP versions, hardening Next.js and Vercel deployments, and writing the runbooks that make the next incident boring. If you are not sure whether your servers are patched against PHP2Shell, talk to our team and we will check, or hire a dedicated developer to own it going forward.

Frequently Asked Questions

What is PHP2Shell?

PHP2Shell is the name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026. They let an attacker run code on a PHP web server without logging in, and they affect PHP versions going back to 5.4.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer get fixes from the PHP project, so you need a backported package from your Linux distribution or host, or an upgrade.

Is my WordPress site affected?

If it runs on PHP, which every WordPress site does, then yes until the server's PHP is patched. Updating WordPress core or plugins does not fix it. Ask your host to confirm the PHP version on your server.

Why did websites go offline for PHP2Shell?

Because security agencies advised that sites which could not be patched immediately should be taken offline or isolated, and attacks had already started. Most of the downtime was planned maintenance, not sites being hacked.

What caused the Vercel outage on 12 October 2026?

Vercel reported increased build and deployment failures from 13:35 to 20:11 UTC, affecting Builds and Git integrations. It has not published a root cause for the initial failures, but said an upstream GitHub incident kept some GitHub-connected builds failing.

Were sites on Vercel down during the outage?

The incident was listed against builds and Git integrations, not against serving live traffic, so sites already deployed generally kept working. The main impact was that teams could not ship new deployments for several hours.

Sources