The last couple of days at work have been intense. On Tuesday details of a new PHP vulnerability started leaking online, and by Wednesday afternoon the official patches were out. Everything else on the board stopped. For two days the only questions were: where do we run PHP, which version is it, and is it patched yet?

The bug has a name, PHP2Shell, and it is one of the most serious problems the web has seen in years.

What is PHP?

PHP is a programming language that runs on the server. When you open a web page, PHP builds the HTML before it reaches your browser. It was created by Rasmus Lerdorf in 1994 and is still everywhere. WordPress, Drupal, Joomla, Laravel, Symfony, Magento, and MediaWiki (the software behind Wikipedia) are all written in it.

The numbers are impressive. According to these PHP statistics from September 2026:

• PHP runs on 70.2% of all websites whose server-side language is known (W3Techs).
• Among PHP sites, 63.4% use PHP 8, 28.7% still use PHP 7 and 7.9% are still on PHP 5.
• Packagist, PHP’s package registry, lists 466,248 packages with almost 197 billion installs since 2012.
• About 19% of professional developers worked extensively with PHP last year (Stack Overflow 2025), and 64% of PHP developers use Laravel (JetBrains 2025).

PHP may not be fashionable, but it powers a huge part of the internet. That is exactly why a bug in PHP itself is such a big deal.

What was the vulnerability?

PHP2Shell is actually two bugs, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10:

1. CVE-2026-109618: when PHP runs out of memory, for example during a huge file upload, it can be interrupted while its internal request data is only half built. The cleanup step then treats that broken data as valid.
2. CVE-2026-109619: some internal state survives after its memory has been freed. The next request on the same worker can use that stale state, and the upload progress feature is one way to reach it.

Both lead to remote code execution, which means an attacker can run their own commands on your server. Here is why it was so bad:

• No login needed. A single anonymous request is enough to attack, and it happens before any application code runs. It doesn’t matter how secure your own code is.
• It’s in PHP itself, not in a plugin or framework, so it affected PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, from PHP 5.4 all the way to 8.5.
• Attackers were early. Amazon saw an exploitation attempt on October 17, four days before the public disclosure. The details then leaked on October 20, a day ahead of schedule.
• Old versions don’t get proper fixes. PHP 7.4, 8.0 and 8.1 only received source patches, and nothing older got anything. With almost 37% of PHP sites still on PHP 7 or 5, many servers can’t simply “update”.

As a precaution, government sites in Europe and Canada, many Wikimedia services and even the Internet Archive went offline for a while. Interestingly, the bug was found with the help of AI models. One of the out-of-memory problems had been spotted back in 2024, but without a working exploit it was never fixed.

Patch everything, now

So what did we developers do? We patched as fast as we could. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you run anything with PHP, even a small blog on shared hosting, check today that it’s on a patched version.

Lets see what the next week will bring in this new crazy world of LLM driven security research and exploitation.