PHP2Shell: our sites patched in under 3 hours

On 21 October 2026, PHP rushed out the fix for two critical flaws, CVE-2026-109618 and CVE-2026-109619, nicknamed "PHP2Shell". A single unauthenticated web request can be enough to take over a server, before the site's own code even runs. PHP powers a large part of the web: corporate sites, online shops, CMSs, business applications.

That day, we closed all our Internet-facing PHP sites and applications to the public, patched them, then reopened them in waves as the fixes were completed. Less than 3 hours after the hands-on work started, all our public websites were running patched PHP, and none of them stayed closed for more than 2 hours 15 minutes. Here is what the flaw is, what the authorities recommended, how we went about it, and what we advise if you run PHP.

PHP2Shell in brief

• Two remote code execution flaws in the PHP core. The first comes from the way PHP stops when a request runs out of memory: the request's memory can be left in an inconsistent state, which request cleanup then treats as valid; with Apache and mod_php, this can happen before any application code runs. The second comes from global state that a worker keeps from one request to the next and that still points to freed memory.
• Severity: 9.2 out of 10 according to the PHP team (CVSS 4.0), 9.8 according to the US NVD database (CVSS 3.1). The 10.0 score that circulated before the release is wrong, according to the PHP Foundation.
• Who is affected: every PHP installation that serves web pages, whatever the setup (PHP-FPM, Apache with mod_php, CGI, FrankenPHP, LiteSpeed). The PHP team considers mod_php the most exposed.
• Fixed versions: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The PHP project no longer updates the 8.1 branch and older: it only provided minimal source-level fixes for 7.4, 8.0 and 8.1, and some distributions and extended-support vendors ship their own fixes.
• Exploitation: at the time of writing, it is not confirmed by Germany's BSI, the US CISA or the PHP Foundation, but Cloudflare says it has seen attack traffic. Demonstrations were circulating even before the release.

A release brought forward after a leak

The fix was due on 22 October. In the late afternoon of 20 October, the CVE identifiers of both flaws leaked, with a wrong score and a wrong release time. PHP therefore brought the release forward to 21 October at 16:00 Luxembourg time, and announced it that evening. Shortly afterwards, according to the PHP Foundation, a demonstration video was published by mistake and then removed; copies circulated. In the end, the fixes came out around 15:30, half an hour ahead of the announced time.

Debian and Ubuntu shipped their first fixes within the hour (Debian at 15:45, Ubuntu at 15:56). Other distribution channels only followed in the late afternoon or evening: for several hours, many teams knew they had to patch without yet having the package they normally use.

What the authorities recommended

• UK NCSC: if you cannot update, apply PHP's temporary mitigations; if that is not possible or would take too long, consider taking the system offline until it is protected. If a system cannot be updated or disabled straight away, check it for signs of compromise and backdoors before updating or mitigating it.
• CERT-EU: patch immediately; where that is not feasible, consider isolating Internet-facing applications from public networks until the fix has been applied and verified.
• BSI (Germany): consider temporary disconnection from the Internet if the patches cannot be installed. The BSI notes that some operators did so during the day as a precaution.
• CIRCL (Luxembourg): for high-risk exposed services that cannot be updated, consider isolating them or temporarily removing them from public access, depending on business criticality. CIRCL warns against a step that only looks safe: disabling PHP while the source files remain reachable through the web server. A safe maintenance page or a network restriction is better.
• CERT-FR: for end-of-life branches (PHP 5 to 8.1), isolate the affected systems, then migrate.

How we patched our public websites in under 3 hours

Here is the timeline of our response, rebuilt from our servers' logs and our internal exchanges (Luxembourg time):

• 15:34: the alert reaches us internally, just as PHP publishes its fixes.
• 15:57: decision to warn our clients, check our exposure and close the sites that are not essential. The first clients are warned from 16:00.
• 16:37: hands-on work starts.
• 16:50: all our PHP sites and applications reachable from the Internet are closed to the public, the last one at 16:52. The services keep running: only access from the Internet is blocked, and visitors see an access-denied page. PHP's recommended temporary mitigations are applied at the same time to part of our installations.
• From 16:50 to 19:00: the fixed versions were not yet available in all the images we use. As they still had not arrived, from 18:00 we rebuilt the affected images ourselves on patched PHP, some of them directly from PHP's official sources.
• From 18:12 to 19:03: sites are reopened in waves, each one only after checking the PHP version actually running, not just the version installed.
• 19:03: all our public websites have reopened, on patched PHP, and the temporary settings are removed. None stayed closed for more than 2 hours 15 minutes, and in the logs we checked, visitors only got an access-denied page during the closure, never a server error.
• 20:03: our webmail, whose PHP had to be patched separately, reopens in turn, after being closed for 3 hours 13 minutes.
• 20:12: the system PHP on our development server is updated in turn.

So less than 3 hours passed between the start of the hands-on work and the moment all our public websites were patched and reopened. Measured from the release of the fix, it took about three and a half hours: between the fixes coming out around 15:30 and our sites closing at 16:50, about 1 hour 20 minutes went by, the time it took to decide, warn our clients and get the hands-on work started.

Why close our sites to the Internet rather than stop the services

Switching a server off or disabling PHP looks safer. In practice it creates other risks: error pages, jobs cut off halfway and, as CIRCL points out, source files that can become readable if PHP is disabled while the web server keeps serving the site. We chose to close access from the Internet at the web server level:

• the public can no longer reach the flaw from the Internet, which greatly reduces exposure;
• the services keep running, and our teams keep access to patch and verify them;
• each site can be reopened separately, as soon as its own fix is verified;
• rolling back takes a single command, with no restart.

What we take away

• Be able to close your sites to the Internet in minutes: a simple, reversible closure that leaves the services running can be set up quickly on the day of the alert; prepared and tested in advance, it can be triggered faster still.
• Do not depend on a single package source: knowing how to rebuild your images from official sources saves waiting for a third party's update.
• Check the version that is running, not the one that is installed: a service that has not restarted keeps running the old code.
• Inventory everything: servers, containers, build images, development workstations. PHP hides in many places.
• Warn early: we started warning our clients nearly an hour before the sites were closed.

What to do if you run PHP

1. Inventory everything that runs PHP and answers web requests: servers, containers, CMSs such as WordPress, applications hosted by a provider.
2. Update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or to your distribution's fixed package, which may keep an older version number (the fix is backported), then restart the PHP processes and rebuild container images.
3. If you cannot update right away, apply the temporary mitigations published by PHP and close access from the Internet, which the authorities ask you to consider. Both reduce the risk without removing it: only the update fixes the flaw.
4. For PHP 8.1 and older, install your distribution's or extended-support vendor's fix if there is one, otherwise isolate; either way, migrate to a supported branch: the PHP project no longer updates these branches.
5. Check the version actually running on each site, not just the installed package.
6. Look for signs of compromise in your logs, as the NCSC asks, and get help if in doubt.
7. If your site is hosted, ask your provider when and how it patched, and get it confirmed in writing.

For an entity subject to NIS 2, this responsiveness is not optional: the directive lists among the minimum measures "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure" (Article 21). If personal data may have been exposed, the GDPR requires the breach to be assessed and, where required, notified to the CNPD within 72 hours (Article 33).

How Luxgap can help

Our managed SOC watches your systems around the clock and supports you if an incident hits. To organise vulnerability management over time, our outsourced CISO runs security policy, risk and incidents, and a cybersecurity audit maps your exposure. A question about PHP2Shell or your own exposure? Contact us.

Sources

• php.net, announcements of 21 October 2026; PHP Foundation, 21 October 2026
• CVE-2026-109618; CVE-2026-109619
• NCSC, Critical security issue affecting PHP; CERT-EU, advisory 2026-018
• CIRCL, TR-102; CERT-FR, CERTFR-2026-ALE-014
• NVD, CVE-2026-109618; Cloudflare, 21 October 2026; BSI, BITS-H No. 2026-297981-1132, version 1.1 of 21 October 2026

See also: Understanding NIS 2 · Understanding the GDPR · Managed SOC