PHP2Shell: What We Checked and Patched

It started with a video in our feed. It warned about a "huge PHP hole" but stayed vague: no CVE numbers, no versions, no technical details.

That is how many security stories begin today. This article covers what is actually confirmed about PHP2Shell, how we checked our own server, and what you can take from it. Status: 22 October 2026.

What PHP2Shell is

PHP2Shell is the name for two vulnerabilities in the PHP core. Both allow remote code execution (RCE): running an attacker's code on your server over the network, with no login required.

One flaw sits in PHP's out-of-memory handling. PHP can be interrupted mid-request while internal data is only partly set up. The other involves request state that survives after its memory has been freed, a so-called use-after-free.

According to Help Net Security, a single unauthenticated request is enough, and the attack fires before any application code runs. How well your own app is written makes no difference here.

The facts at a glance

• Severity

  PHP rates both flaws CVSS v4 9.2 (critical). CVSS is a 0–10 scale for how severe a flaw is. Figures up to 10.0 circulated beforehand.

• Affected

  All of PHP's web interfaces (SAPIs): PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Wikipedia lists PHP 5.4 through 8.5 as affected.

• Timeline

  Made public on 20 October 2026, partly through details that leaked early. Patches followed on 21 October 2026, one day ahead of the original schedule.

• Fix

  PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. End-of-life versions 7.4, 8.0 and 8.1 only get source patches, no official builds.

• Found by

  Ryan Austin of Calif and researchers at Wiz. Both used AI models, including OpenAI's (via its "Patch the Planet" initiative).

• Exploitation

  Reports differ. Huntress had seen no attacks on its customers by the afternoon of 21 October; Wikipedia reports exploitation from 21 October. Bottom line: don't wait, patch.

What we did

At FORGE, AI agents work as a team: several specialised AI programs, each with a clear job. They transcribed the video and checked every claim against expert sources. Verdict: the issue was real, the video was vague and light on technical detail.

Next came our own server. The agents found one PHP application that was affected. They then checked the distribution package's changelog to confirm the available update really contained the fix for CVE-2026-109618.

Only then did we patch and restart the PHP service (php-fpm). Downtime was a few seconds. Neo, our founder, approved each step. The agents prepared, a human decided.

Cleaning up on the side: finding legacy leftovers

While listing every PHP endpoint, we came across an old admin endpoint. Nobody needed it any more; it had simply been forgotten.

We switched it off. The logs we have, covering roughly the last 14 days, show no outside access to it.

A patch closes the hole you know about. An inventory finds the ones you forgot.

The version-number trap on Linux

Many Linux distributions pull security fixes into the version they already ship instead of jumping to the new PHP release. This is called a backport.

On Ubuntu 24.04, for example, the package is 8.3.6-0ubuntu0.24.04.13. "8.3.6" looks outdated next to the official fix 8.3.36. Yet the changelog shows this exact package includes the patch for CVE-2026-109618 and CVE-2026-109619.

If you only look at php -v, you can easily draw the wrong conclusion. Check your package's changelog instead:

# Debian/Ubuntu
apt changelog php8.3-fpm | grep CVE-2026-109618

# RHEL/Alma/Rocky
rpm -q --changelog php-fpm | grep CVE-2026-109618

If the CVE number shows up, the fix is in. Adjust the package name to your version.

Checklist: what to do now

• Check

  Is PHP serving web requests anywhere? Which version, which package? For distro packages: changelog over version number.

• Patch

  Install the update and restart the PHP service (php-fpm or the web server). Without a restart, the old code keeps running.

• Emergency

  Can't patch right away? The UK's NCSC advises taking affected systems offline. For old versions, Huntress suggests session.upload_progress.enabled = Off as a stopgap.

• Inventory

  List every PHP application and endpoint, including test and admin pages. Nobody patches what nobody knows exists.

• Clean up

  Remove what you no longer need. Every legacy endpoint you switch off is one less way in.

• Watch

  Huntress recommends watching for PHP processes that spawn shells or tools such as curl and wget. Review your logs for anything unusual.

• Sources

  Check claims from videos and social media against primary and expert sources. A warning without a CVE number and affected versions is not an action plan.

AI on both sides

PHP2Shell shows how quickly AI is changing security work. AI models helped find these flaws. According to Help Net Security, they also lower the bar for exploiting them.

For us, AI handled the legwork: transcribing, cross-checking sources, inspecting the server, reading the changelog. It was fast and every step was documented.

The decision on when to patch and what to switch off stayed with a human. We think that is the right split.

Sources

• Help Net Security: PHP2Shell vulnerabilities patched (21 Oct 2026)
• The Hacker News: PHP2Shell – two critical PHP flaws
• Huntress: PHP2Shell – leaked critical PHP vulnerabilities
• Wikipedia: PHP2Shell

Transparency: research, the server check and this text were produced with the help of our AI agents. All facts were checked against the linked sources, and a human signed off on publication.