On the night of October 21 (Korea time), website administrators around the world started updating at the same time. PHP, the software behind nearly seven in ten websites, had two holes that let someone take control of a server without logging in.

In this post:

1. What PHP does, and how widely it is used
2. The timeline
3. PHP2Shell: unauthenticated remote code execution
4. Hole 1: running out of memory and the emergency exit
5. Hole 2: traces of the previous guest (use-after-free)
6. Which servers are at risk, and the fixed versions
7. Hands-on: checking and patching a server
8. Three things to do now

How to read the numbers. [Official docs] are security notices and advisories published by the PHP project, [Community report] means press or statistics sites, and [Measured] means we ran it ourselves on a local Docker setup on a Mac. We do not cover how to attack; only how to check and defend.

1. What does PHP do?

PHP is a programming language that builds web pages behind the scenes. When you click "Order" in an online shop, PHP on the server takes the order, processes it, builds the result page (HTML), and sends it back to your browser.

How widely is it used? According to the web technology survey W3Techs, 69.3% of websites whose server-side language is known use PHP [Community report] (W3Techs, checked 2026-10-22). WordPress, which powers many blogs and company sites, is built in PHP too. So when PHP has a hole, a large part of the internet is affected at once.

Note that 69.3% is the share of sites using PHP, not the share of vulnerable sites. Some already run fixed versions, and impact depends on configuration.

2. Timeline

• October 17: Amazon's security team said its honeypot servers recorded attempts targeting these holes, four days before disclosure. [Community report] (Help Net Security; we could not find Amazon's original post)
• October 20: The PHP security team announced a critical security release for the next day. [Official docs] (PHP Foundation announcement)
• October 21, 14:00 UTC: Four fixed versions shipped: 8.5.12, 8.4.27, 8.3.36, and 8.2.35. [Official docs] (php.net)

Some said the fix was "rushed out," but it was announced a day ahead and shipped on schedule.

3. PHP2Shell: unauthenticated remote code execution

The security industry and press group the two holes as PHP2Shell (it is not an official PHP name). A shell is the window where you give a server commands, so the name means getting someone else's server command line through PHP.

• There are two officially numbered vulnerabilities: CVE-2026-109618 and CVE-2026-109619. A CVE is a unique ID assigned to each publicly disclosed vulnerability.
• Both score 9.2 on CVSS v4.0 (the standard 0–10 severity scale), rated Critical. [Official docs] (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp)

The php.net notice calls it unauthenticated remote code execution. Broken into three parts:

• Unauthenticated: someone with no username or password
• Remote: from across the internet
• Code execution: can run any command they want on your server

That means stealing customer data, defacing the site, or using the server as a launch pad for other attacks.

4. Hole 1: running out of memory and the emergency exit

The first hole (CVE-2026-109618) appears when memory runs out. Think of a restaurant kitchen.

1. PHP uses memory for every request it handles. Think of it as the kitchen workbench.
2. When the workbench fills up (out of memory, OOM), PHP stops right there and runs straight out the emergency exit.
3. In the rush, part of the workbench is left not yet prepared.
4. But the closing-shift cleaner assumes the workbench is fine and reads it as-is.

If an attacker carefully engineers that moment, they can make the cleanup do something it should not. The advisory explains that Apache mod_php calls the shutdown procedure unconditionally, even when request startup failed. The patch removes this "jump straight out the exit" behavior on OOM. [Official docs] (GHSA-w8hw-w9fx-j79w)

5. Hole 2: traces of the previous guest (use-after-free)

The second hole (CVE-2026-109619) is traces left by the previous guest. This time, think of a hotel.

• On a server, one worker process handles many requests in turn, like one hotel employee checking guests into the same room one after another.
• Normally the room is cleaned after each guest leaves. But after a fatal error, that cleaning step can be skipped.
• So when the next guest arrives, a key pointing to a room that was already returned is still lying around.

Reusing memory that has already been freed is called use-after-free. The advisory says this, too, can lead to remote code execution. Turning off error display or using @ does not protect against it. [Official docs] (GHSA-6wmf-4rv5-p3rp)

6. Which servers are at risk, and the fixed versions

The advisory's assessment depends on how PHP is attached to the web server (the SAPI). [Official docs]

The fixed versions are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. This official release starts at 8.2, so anything older needs to move to a supported version. The php.net notice is clear: "There are no complete mitigations, updating is the only safe choice." [Official docs] (php.net)

7. Hands-on: checking and patching a server

We ran a small neighborhood-bakery order site on local Docker on a Mac, deliberately pinned to the unpatched PHP 8.4.26 (php:8.4.26-apache image). [Measured]

The version visible from outside

1. The first line of the Dockerfile says FROM php:8.4.26-apache. That is the PHP version this server runs.
2. Start the server with docker compose, then fetch only the response headers from outside.

curl -sI localhost:8473 | grep -i powered
# X-Powered-By: PHP/8.4.26

The version is printed right there. Attackers can pick targets the same way. A small check script that compares against the patched version list reports vulnerable and says to upgrade to 8.4.27 or later.

Temporary mitigation

Before updating, we added what can be done right away. As the advisory suggests, we turned off session upload progress, and also stopped advertising the version number.

session.upload_progress.enabled = 0
expose_php = Off

The advisory itself notes this blocks only the one demonstrated attack path, not the others. After changing it, restart every worker. [Official docs] (GHSA-6wmf-4rv5-p3rp)

The real fix: upgrade

We changed 8.4.26 to 8.4.27 in the Dockerfile and rebuilt.

sed -i '' 's/8.4.26/8.4.27/' Dockerfile

Running the same checks again gives different results. [Measured]

• The response header no longer shows the PHP version at all (expose_php = Off).
• The check script reports PHP 8.4.27 → patched.
• Inside the server, php -i shows session.upload_progress.enabled => Off.

8. Three things to do now

1. Check the version. On a server, run php -v; on a hosting service, look in the control panel.
2. Update now and restart. If you are below 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, update and restart the worker processes that run PHP.
3. Check your distribution's security notices. Linux distribution packages sometimes keep the version number and ship only the fix (a backport). Don't judge by the number alone; check the distribution's security advisory too.

If you use web hosting, asking your host whether they have patched is the fastest route. With reports that attacks began before disclosure, don't put off today's check until tomorrow.

Limitations

• The hands-on part used a single mod_php (Apache) image on local Docker. We did not run PHP-FPM or FrankenPHP setups.
• We did not reproduce the attack or cover any PoC (proof-of-concept code). Whether a public PoC exists, or whether the bugs are on CISA's Known Exploited Vulnerabilities (KEV) list, could not be confirmed from primary sources, so we left it out.
• The October 17 attack attempts are cited via press coverage; we could not find Amazon's original post.
• Figures circulating elsewhere, such as "70–75% of the web" or "millions of hacks," could not be confirmed from primary sources and were left out.

Watch the video

We covered the same material with illustrated explanations and the real terminal in a Korean-language video, published on October 24 at 7 p.m. KST.

• Watch on YouTube: PHP's emergency patch — how PHP2Shell works and how to check and patch your server

Sources

• PHP, php.net security notice (2026-10-21)
• PHP security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• PHP security advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation, Upcoming critical PHP security release (2026-10-20)
• W3Techs, Usage statistics of PHP (checked 2026-10-22)
• Help Net Security, PHP2Shell: PHP vulnerabilities patched (2026-10-21, citing Amazon threat intelligence)