the php bug that put most of the web at risk.

PHP runs a large share of the web. Estimates put it at around seven in ten websites, including WordPress, Drupal, Joomla and Magento.

This week, the PHP project confirmed two critical flaws in the language’s core, and the situation developed faster than anyone had planned for. Security researchers have started calling the pair PHP2Shell. The name is a nod to Log4Shell, the 2021 vulnerability that forced organizations worldwide into emergency patching.

What the two flaws are

The bugs are tracked as CVE-2026-109618 and CVE-2026-109619. Both were rated 9.2 out of 10 on the CVSS v4.0 scale, which is critical severity. Both can lead to remote code execution, meaning an attacker could run commands on a server without logging in.

The first flaw involves how PHP handles running out of memory. In certain conditions, PHP can stop processing a request while its internal data is only partly set up. The second is a use-after-free bug, where leftover request data can still be accessed after the memory behind it has been released.

Both sit in the PHP interpreter itself. That matters because it means the problem is not in a plugin, a theme or a piece of application code. Updating a CMS will not remove it. The PHP runtime on the server has to be updated.

How the disclosure went wrong

The flaws were meant to be disclosed on Thursday, October 22, under a coordinated embargo. That plan ended on October 20, when a post on Hacker News claimed two critical PHP flaws were about to be published. The post was later removed, but researchers at watchTowr confirmed the flaws were real and said they had reproduced one of them.

The PHP security team published an advance notice that same day and moved its release to October 21 at 14:00 UTC. A proof-of-concept appeared online before the patch did. The SANS Internet Storm Center described it as unreliable and incomplete at the time, but said it showed defenders what to look for.

“Every other measure only buys time.”

CybelAngel, on why patching PHP itself is the only complete fix

Was it exploited?

Early reports differed. Some security firms said they had seen no attacks as of October 20. By the morning of the release, Aikido reported exploitation in the wild, citing Cloudflare, which had pushed emergency firewall rules aimed at these flaws. Until PHP or the affected providers publish more detail, the extent of real-world attacks is still unclear.

Reporting from Field Effect said Apache servers running mod_php carry the highest risk. In that setup, the demonstrated attack path runs before the application’s own code is processed, so protections inside the application may not get a chance to act.

Itdaily also reported that some sites went offline during the response, including a university and several hospitals. That outage appears to have come from the scramble to respond, not from attackers.

The fix, and who is left out

PHP released patched versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The builds immediately before them, including 8.5.11 and 8.2.34, are not fixed.

PHP 8.1 and older are end-of-life and will not receive an official patch. Researchers believe the flaws reach as far back as PHP 5, though that detail comes from an unverified report.

The scale of that gap is large. According to Shodan-based counts cited by CybelAngel, about 2.24 million internet-facing hosts advertise PHP. Of the roughly 1.5 million that reveal their version, about 59 percent run a branch that will not get a fix. These figures count servers, not websites, and about 740,000 hosts hide their version, so the real number is likely higher. Some Linux distributions, including Debian, Ubuntu and RHEL, may backport fixes to older packages, which would reduce the exposure for their users.

WordPress shows a similar picture. Figures reported by The Repository, based on WordPress.org statistics, say 35.1 percent of WordPress sites run a PHP version that is no longer patched, with 16.46 percent on PHP 7.4.

What to do

For anyone running their own servers, the guidance from security firms is consistent:

Update PHP to one of the fixed versions, then restart PHP-FPM or the web server so the new version is loaded.
Check your distribution’s notice. Some distributions apply the fix without changing the upstream version number.
If you cannot patch yet, early guidance suggested turning off session.upload_progress.enabled as a partial mitigation. It is not a complete fix.
Check for compromise. CybelAngel recommends looking for web shells, modified PHP files, new admin accounts and unusual outbound connections, going back to at least June.
On unsupported PHP versions, restrict access with a VPN or IP allowlist and plan an upgrade.

For anyone on shared or managed hosting, the step is to ask the host whether the update has been applied, and to take a fresh backup before it is.

What this shows

The more lasting issue is the time between a vulnerability becoming known and attackers using it. In this case, that time was measured in hours. Sansec expected mass exploitation within minutes of the release.

It also shows how much of the web runs on software that is no longer maintained. Millions of servers are still on PHP versions that will not get this fix, and for them the only real answer is to upgrade.

Rafay

I write on whatever I want to write, mostly because I can.