PHP2Shell: What to Do About CVE-2026-109618 and CVE-2026-109619

Liveblog closed 21:35 UTCSecurity21 October 202629 min read

PHP2Shell is fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. What the two flaws are, who's at risk, what to do, and how 21 October 2026 unfolded.

Liveblog closed at 21:35 UTC on 21 October 2026. PHP fixed both flaws in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Update, restart PHP and rotate secrets on servers that were exposed. The guidance below reflects what was known when the liveblog closed, and the live updates show how the day unfolded.

I write PHP for a living, mostly Symfony, and most bugs I deal with live in a framework, a package or our own code. This one doesn't. Two critical vulnerabilities sit in PHP itself, and their details leaked before the fix was ready. Researchers call the pair PHP2Shell.

The short version:

Two critical flaws in PHP's core, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2, that can allow unauthenticated remote code execution.
The fix is out: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Update now, and restart PHP.
Every PHP install that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php the most exposed.
PHP 8.1 and older get no release, only minimal source backports for 7.4, 8.0 and 8.1.
You can't fix this in your code or with Composer. It's the PHP runtime on the server, so it's patched on the server.
Settings only narrow it down. PHP lists measures for while you can't update, but says updating is the only safe choice.
The details are public now, and one of the bugs leaks server memory. After updating, rotate passwords, API keys and tokens on exposed servers.

Live updates

21:35 UTCLiveblog closed

That's it for today. Here's where things stand at the end of 21 October:

What was fixed: two critical flaws, CVE-2026-109618 and CVE-2026-109619 (CVSS v4.0 9.2), in how PHP handles a fatal error, usually running out of memory, in the middle of a request. Every PHP version back to 5.4 is affected by at least one of them, and both can lead to remote code execution without a login. One of the underlying bugs can also leak server memory.
Where the fix is: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, the official Docker images, Debian (DSA-6574-1, DLA-4848-1) and Ubuntu (USN-8948-1 and -2). Red Hat is rushing out fixes, with some already available, according to its bulletin RHSB-2026-013. It says RHEL 7 and older ship PHP versions that aren't affected. Remi's repository still had no update tonight. For PHP 7.4, 8.0 and 8.1 there are only source backports.
Exploitation: watchTowr and Cloudflare see active exploitation attempts, and Cloudflare saw attackers adapting their payloads, but no break-in of a specific server has been confirmed. CISA's Known Exploited Vulnerabilities catalog doesn't list either CVE yet.
What you should still do: update every PHP install, restart PHP and check the version in a web request. Rotate passwords, API keys and tokens on servers that were exposed, check for signs of compromise, and get anything on PHP 8.1 or older off the internet or onto a supported version.

Thanks for following along. This post stays up as a reference: the steps below are the ones to work through.

18:35 UTCwatchTowr now sees exploitation attempts

watchTowr, which saw none this morning, now says on its advisory page that it is "observing active exploitation attempts of both CVE-2026-109618 and CVE-2026-109619". The Hacker News dates that to 14:19 UTC, and adds that Cloudflare saw attack traffic against its customers and watched attackers change their payloads to get around its WAF rules. CERT-EU has updated its advisory as well: proofs of concept have begun to circulate, which "raises the likelihood that attackers are already exploiting the vulnerabilities".

No one has reported a confirmed break-in of a specific server yet, and CISA's Known Exploited Vulnerabilities catalog still doesn't list either CVE. If you haven't updated, don't wait for that to change.

18:35 UTCThe PHP Foundation: first signs in 2024, then a fix that stalled

In a candid post, the PHP Foundation explains how this happened. A core developer found the first signs of the out-of-memory problem behind CVE-2026-109618 during PHP's 2024 external audit, but no concrete route to code execution. The competing fixes each had a cost (compatibility breaks, new denial-of-service risks or changes to third-party extensions), and work stalled and restarted for months. "We won't pretend otherwise: the delay was a structural failure," the Foundation writes. On 11 August 2026, Calif and Wiz independently reported working remote code execution with the same root cause, and from then on the fix was the top priority.

It also sets the record straight on the leak. On 20 October only the CVE IDs leaked, with a wrong score, but that evening Calif mistakenly published a demo video, which sped up the PoCs. PHP's security team found no working exploits among them at the time of the release. And on 21 October at 07:41 UTC, more than six hours before the release, Chainguard published built images containing the fix, so attackers could study it in binary form while everyone else waited. The Foundation closes with a request: companies, hosts and governments that depend on PHP should help fund its security work.

18:35 UTCDigiD, MijnOverheid, the NCSC and Tweakers are back

I checked: DigiD, MijnOverheid, ncsc.nl, Security.NL and Tweakers are back online, and the NCSC's homepage now leads with "Ernstige kwetsbaarheden in PHP: update nu". The Tweede Kamer's site blocks my automated checks, so I can't confirm that one.

16:05 UTCThe write-ups are out, and they're bad news

The researchers have published their findings. Wiz, which reported the bugs to PHP, and Calif found them together with OpenAI, with help from frontier AI models. Every PHP version back to 5.4 is affected by at least one of the bugs, and according to Calif the available paths, which depend on the PHP version and SAPI, "are always exploitable under default configurations". They all come down to how PHP handles a fatal error, usually running out of memory, in the middle of a request: the state it leaves behind can be picked up by the next request on the same worker.

Wiz describes four bugs: a use-after-free in the session upload progress unserializer, a remote memory leak, a use-after-free in fatal error backtraces, and corruption of OPcache's shared memory. Calif confirmed remote code execution without a login on WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, WHMCS, Laravel 13.11 and Symfony 8.1. The code is in PHP itself, so even a "Hello World" script can be a target. Wiz says PHP's patch fixes the problem at its core, including variants beyond these four. According to Sansec, an exploit tool is public as well, and it expects mass exploitation now.

16:05 UTCRotate secrets: worker memory can leak

One of the bugs lets an attacker read a chunk of a PHP worker's memory without logging in and without reaching code execution, Wiz writes. That memory can hold passwords, tokens, API keys and certificates from other requests or from the server itself. Aikido advises rotating passwords, API keys and tokens on internet-facing PHP systems, and I'd do the same for anything that ran a vulnerable version. Signs to look for, according to Wiz and Aikido: unusual multipart requests followed by memory-limit errors or repeated HTTP 500s, unusually large or malformed PHPSESSID cookies in responses, and PHP workers restarting for no clear reason.

16:05 UTCPackages and images are out

Docker: the official php images got their 8.5.12, 8.4.27, 8.3.36 and 8.2.35 tags around 15:40 UTC.
Debian: DSA-6574-1 fixes php8.4 in trixie (8.4.27-1~~deb13u1), and DLA-4848-1 fixes php8.2 in bookworm (8.2.35-1~~deb12u1). Unstable isn't fixed yet.
Ubuntu rates it critical priority, with fixes in USN-8948-1 and USN-8948-2: php8.3 8.3.6-0ubuntu0.24.04.13 on 24.04, php8.1 8.1.2-1ubuntu2.28 on 22.04 and php8.5 8.5.4-0ubuntu1.5 on 26.04, plus fixes for PHP 5.5 to 7.4 on older releases through Ubuntu Pro. Note the version numbers: patched, but still "8.3.6".
Red Hat rates both flaws Important rather than Critical. On PHP-FPM, which RHEL uses, it calls remote code execution through CVE-2026-109618 "difficult in practice", while mod_php is exploitable with the default configuration. That's a reason not to panic on FPM, not a reason to wait.

Exploitation is still unconfirmed. Huntress hadn't seen any in its partner base as of 14:00 UTC, Patchstack's telemetry still shows probing only, and CISA's catalog, updated at 14:04 UTC today, doesn't list either CVE.

14:10 UTCThe fix is out: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35

PHP has released the fix, with its security advisory. Both flaws can allow unauthenticated remote code execution, and every PHP install that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php the most exposed, with a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.

CVE-2026-109618 is "RCE via OOM corruption": running out of memory can interrupt PHP while internal request data is only half set up, and request cleanup then treats it as valid. CVE-2026-109619 is "RCE via stale global state": state from one request can outlive its memory and be used by the next request on the same worker. Distributions and LTS vendors got the patches in advance, so check for updated packages now. Remi's repository won't have updates today, and at 14:10 UTC the official Docker images didn't have the new tags yet. For PHP 7.4, 8.0 and 8.1, PHP published minimal source backports. I've rewritten what to do now around the release.

14:10 UTCCorrection: some settings do narrow the attack paths

Earlier today I wrote, based on Aikido, that the php.ini settings going around don't protect, and that you shouldn't set memory_limit = -1. PHP's advisory is more precise, and it's the authority here. For CVE-2026-109618, memory_limit=-1 set where applications can't override it, together with a low post_max_size, reduces exposure. For CVE-2026-109619, session.upload_progress.enabled=0 blocks the confirmed session paths, though not other variants. None of it makes an install safe, and PHP says so: "There are no complete mitigations, updating is the only safe choice." The full list is in step 4.

13:35 UTCSo far it looks like probing, not breaches

Patchstack has toned down its report. Its hosting partners reported exploitation attempts, and its own telemetry "is currently only showing probing attacks, no hard evidence of breaches yet". It adds that it's unclear whether Cloudflare and others are seeing probes or complete attacks. The Hacker News sums up where things stand: no compromise has been confirmed, the public exploit code going around hasn't been shown to work, and neither flaw is in CISA's Known Exploited Vulnerabilities catalog. I checked the catalog myself just now, and they aren't.

The code going around is a public repository presented as a proof of concept. According to Cybersecurity News, its own write-up says it needs a separate bug in the application, such as a local file inclusion, to get to code execution. An anonymous code audit cited by The Hacker News argues that the upload progress bug others describe doesn't exist in released PHP at all. Don't run any of it against your servers. That all of this is unconfirmed doesn't make you safe: once the patch is out at 14:00 UTC, it shows attackers exactly where to look.

13:35 UTCIf you block multipart, block it on every method

If you reject multipart request bodies at the web server, don't limit the rule to POST. PHP 8.4 added request_parse_body(), which parses multipart bodies on other methods too, so a POST-only rule can be stepped around. GMO Flatt Security, the Tokyo firm that first suggested turning off upload progress, has also walked that back: the setting alone isn't a complete fix, and it expects attacks that get around it. Its other advice is worth taking regardless: keep less data on the server, lower its privileges, remove stored credentials (cloud roles included) and send logs somewhere an attacker can't wipe them.

12:35 UTCDigiD, MijnOverheid and the NCSC go offline as a precaution

In the Netherlands, a long list of sites has gone dark until the patch. According to NOS, they include MijnOverheid, DigiD, the Tweede Kamer's website, RTL's news site and app, Tweakers, the National Cyber Security Centre (NCSC) and the Autoriteit Persoonsgegevens. Also offline: Notubiz, the meeting system about a hundred municipalities use, and systems at news agency ANP and in higher education. I checked a few myself: DigiD, MijnOverheid, ncsc.nl and Security.NL all show a maintenance page right now.

The NCSC hasn't seen active exploitation yet, NOS writes, but warns that until PHP is updated, every system that contains PHP and can be reached from the internet is probably vulnerable. The UK's NCSC has issued an alert too: prepare to update immediately, and where that isn't feasible, consider taking the system offline.

12:35 UTCA maintenance page only helps if PHP is out of the way

If you're taking a site offline, do it in front of PHP. Sansec points out that the maintenance modes built into Magento and WordPress don't help, because PHP parses each request before the application checks its maintenance flag. Stop PHP-FPM and have the web server serve a static page instead. If you can't go offline, Sansec suggests making the site read-only, rejecting every request method other than GET and HEAD at the web server. That shrinks what reaches PHP, but it isn't a fix. Sansec expects mass attacks within 15 minutes of the release, so have the update ready to go at 14:00 UTC.

12:05 UTCThe php.ini workarounds don't protect

The PHP settings that went around after the leak, turning off session.upload_progress.enabled and setting memory_limit = -1, don't protect against these flaws, Aikido now writes. It adds that the PHP team has confirmed the flaws can't be mitigated through configuration, and that no complete WAF rule exists yet. An earlier version of this post listed the upload progress setting as a stopgap, so I've rewritten that section. Aikido's advice until the patch: take internet-facing PHP applications offline if you can. After patching, it says to check for compromise going back to at least June 2026.

Aikido also runs a PHP2Shell checker for public URLs. Only scan sites you own. Its quick check can't tell a patched server from a vulnerable one by timing alone, and the definitive check can crash a PHP worker, so run that one outside peak hours.

Correction, 14:10 UTC: PHP's advisory does list memory_limit=-1 and session.upload_progress.enabled=0 as measures that reduce exposure to specific attack paths, though not as a fix. See the 14:10 updates.

12:05 UTCExploitation reports still conflict

PHP's notice hasn't changed: the release is still set for 14:00 UTC. According to SOCRadar, PHP hasn't reported exploitation in the wild and CISA hasn't added either CVE to its Known Exploited Vulnerabilities catalog. Aikido and Patchstack do report attacks, but neither has published technical details. watchTowr says it has reproduced CVE-2026-109618 and is holding back details until the patch ships. SOCRadar also reports that the cybercrime forums BreachForums and Dread have gone offline as a precaution, and that forum users are asking around for a working exploit. If one gets passed to you, don't run it: unverified exploit code for a bug everyone is talking about is a classic way to spread malware.

10:50 UTCExploitation is now being reported

Patchstack says several of its hosting partners have reported active exploitation, the first of them at 07:34 UTC. Minutes later Cloudflare's CTO Dane Knecht posted that Cloudflare is "seeing early attacks emerging" and has deployed WAF rules for the known exploit vectors to all customers, free plans included, calling them "a STOPGAP only". Not everyone sees it yet: Huntress hadn't seen exploitation in its partner environments as of yesterday, and watchTowr's FAQ lists none confirmed. Treat your servers as targets either way.

Update, 13:35 UTC: Patchstack now describes these as exploitation attempts, and says its own telemetry shows probing only. See the 13:35 update.

10:50 UTCServices are going offline until the patch

Some teams aren't waiting. According to Patchstack, the developers of The SEO Framework took their servers offline, and Japanese outlet ITmedia reports emergency maintenance at several large services, including Kodmon, Shadowverse: Worlds Beyond and Sakura Rental Server. That's the most cautious option, and for a site that can go dark for a few hours, a reasonable one.

10:50 UTCEarly analysis points at uploads

Patchstack writes that early analysis points at PHP's session upload progress feature and multipart file-upload requests. That isn't confirmed by PHP. It adds a second stopgap to the two PHP settings below: where you don't accept uploads, have your WAF or reverse proxy reject or inspect multipart POST requests, matching loosely on "multipart" in the Content-Type header. Test it first, because it breaks forms with attachments, media libraries and checkouts wherever you apply it too widely.

Correction, 12:05 UTC: according to Aikido, the PHP settings this entry refers to don't protect. See the 12:05 update. And block multipart on every method, not just POST: see the 13:35 update. PHP's own list of interim measures came with the release: see the 14:10 updates.

10:45 UTCLiveblog opened

No early release: PHP's notice still says 14:00 UTC. CERT-EU has published advisory 2026-018. It advises preparing to patch immediately, and isolating internet-facing applications from public networks where that isn't possible. Its note that the flaws "could affect all PHP versions from PHP 5 onwards" cites a researcher's post, not PHP.

What happened

When (UTC)	What
2024	During PHP's external audit, a core developer finds the first signs of the out-of-memory problem. A fix stalls for months.
11 Aug	Calif and Wiz independently report working remote code execution with the same root cause.
20 Oct, 15:20	A Hacker News post claims two PHP RCE disclosures are coming. It's taken down, but screenshots spread.
20 Oct	watchTowr confirms the leak is real and the flaws are under embargo.
20 Oct, 19:33	PHP publishes an advance notice: a security release for two critical vulnerabilities, both CVSS v4.0 9.2.
21 Oct, 02:13	PHP core developer Gina Peter Banyard says patching is the only mitigation.
21 Oct, 07:34	Patchstack receives the first reports of exploitation attempts from hosting partners.
21 Oct, 07:41	Chainguard publishes built images with the fix, breaking the embargo, according to the PHP Foundation.
21 Oct, 07:43	Cloudflare's CTO reports early attacks against PHP sites and WAF rules for all plans.
21 Oct, 08:48	According to Sansec, the PHP Foundation warns that Remi's repository won't have updates today.
21 Oct, from 09:10	NOS reports Dutch sites going offline as a precaution, among them DigiD, MijnOverheid, the Tweede Kamer and the NCSC.
21 Oct, around 14:00	PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with its security advisory.
21 Oct, 14:19	watchTowr reports active exploitation attempts of both CVEs.
21 Oct, around 15:40	The official Docker `php` images get the fixed versions.
21 Oct, evening	DigiD, MijnOverheid, the NCSC and Tweakers are back online. Red Hat publishes bulletin RHSB-2026-013.

The original embargo pointed at Thursday 22 October. PHP moved the release a day earlier after the leak.

What PHP has confirmed

PHP published the details with the release, in its security advisory:

CVE-2026-109618, RCE via OOM corruption (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partly initialised. Request cleanup may then treat that invalid data as valid.
CVE-2026-109619, RCE via stale global state (GHSA-6wmf-4rv5-p3rp): internal state that belongs to a request can survive after its memory has been freed. A later request handled by the same worker may use it before normal initialisation resets it.
Both are rated CVSS v4.0 9.2 and can allow unauthenticated remote code execution. The 10.0 that went around came from the leak.
At risk: every PHP installation that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers the risk highest for mod_php, where it has a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.

PHP's changelog sums up the fix as "Avoid state corruption via bailout". A bailout is how PHP's engine jumps out of a request on a fatal error, such as hitting the memory limit, which is where both flaws come in.

What the researchers add. Wiz and Calif, who found the bugs together with OpenAI:

Every PHP version back to 5.4 is affected by at least one of the bugs. Ubuntu even ships fixes for PHP 5.5.
Wiz reported four bugs under the two CVEs: a use-after-free in the session upload progress unserializer, a remote memory leak, a use-after-free in fatal error backtraces, and corruption of OPcache's shared memory. PHP's patch fixes the underlying problem, including other variants.
The memory leak needs no login and no code execution, and can expose passwords, tokens and API keys from other requests.
Calif confirmed remote code execution without a login on WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, WHMCS, Laravel 13.11 and Symfony 8.1.

How exposed FPM is is where vendors differ. According to the PHP Foundation, remote code execution through CVE-2026-109618 was demonstrated on mod_php with default settings and also confirmed on PHP-FPM, through code paths in the application. For CVE-2026-109619, a use-after-free and worker crash were confirmed, and remote code execution was shown on mod_php. Calif says the paths are always exploitable under default configurations, depending on version and SAPI. Red Hat rates both flaws Important rather than Critical, because on PHP-FPM remote code execution is "difficult in practice". Either way, mod_php is the easiest target, and FPM is not safe.

Exploitation in the wild: attempts, no confirmed break-ins yet. watchTowr is observing active exploitation attempts of both CVEs, Cloudflare has seen attackers adapt their payloads to its WAF rules, and CERT-EU warns that circulating PoCs make exploitation more likely. Huntress hadn't seen any in its partner base as of 14:00 UTC, Patchstack's telemetry showed probing, and when the liveblog closed, CISA's Known Exploited Vulnerabilities catalog didn't list either CVE. With the write-ups public, that's a matter of time: when CVE-2024-4577 went public in June 2024, exploit attempts showed up within a day.

Which PHP versions get a fix

PHP releases fixes for its supported branches:

Branch	Fixed in	Support
8.5	8.5.12	Active until 31 Dec 2027, security until 31 Dec 2029
8.4	8.4.27	Active until 31 Dec 2026, security until 31 Dec 2028
8.3	8.3.36	Security fixes until 31 Dec 2027
8.2	8.2.35	Security fixes until 31 Dec 2026

Everything older (8.1, 8.0, 7.x and 5.x) is end of life and gets no release. Given the severity, PHP did publish minimal source backports for 7.4, 8.0 and 8.1 (see step 5). That's a lot of servers: security firm Mallory counted about 884,000 internet-facing hosts on Shodan whose banner reported PHP 8.1 or older, 59% of the hosts that showed a version.

What to do now

1. Find every PHP install

Don't stop at your main web server. Think of staging servers, old client sites, Docker images, control panels like cPanel and Plesk, and appliances or vendor software that ship their own PHP.

The PHP your web server runs is not always the PHP on your command line, so check both:

php -v                          # the command-line PHP
ls /etc/php/                    # Debian/Ubuntu: every installed version
php-fpm8.3 -v                   # the FPM binary of one version (use yours)
rpm -qa 'php*'                  # RHEL, Rocky, AlmaLinux
docker ps --format '{{.Image}}' | sort -u   # images to check one by one

2. Update PHP

Internet-facing servers first, then the rest. Where the update comes from depends on how PHP got there:

Distribution packages: Debian (DSA-6574-1 for trixie, DLA-4848-1 for bookworm) and Ubuntu (USN-8948-1 and -2) have fixed packages out. For RHEL, Red Hat is releasing fixes per product: see RHSB-2026-013. Distributions often backport fixes without moving to the new version number, so check the package changelog for the CVEs instead of the version string: Ubuntu 24.04's patched PHP is still called 8.3.6.
Remi's repository (common on RHEL-based servers): PHP said it wouldn't have updates on 21 October, and it still had none that night. Check Remi's blog before relying on it, or switch to your distribution's packages or a source build.
Docker: the official php images have had 8.5.12, 8.4.27, 8.3.36 and 8.2.35 tags since around 15:40 UTC on 21 October. Rebuild with --pull and redeploy, and bump pinned tags such as php:8.4.26-fpm. A running container keeps its old PHP until it's replaced.
FrankenPHP embeds PHP, so you need a FrankenPHP build or image with the patched PHP, not just a PHP package.
Managed hosting: ask your provider whether they've updated, and when.
Source builds: the releases are on php.net.

3. Restart PHP and check the version where it matters

Restart PHP-FPM, Apache with mod_php or whatever runs PHP for your site, so every worker runs the new binary. Then check the version in a web request handled by that PHP, not just php -v on the command line.

4. If you can't update yet

"While only an update is a complete solution," PHP writes, its advisory lists measures that "reduce exposure to specific attack paths but do not make an installation safe."

For CVE-2026-109618 (OOM corruption):

Set memory_limit=-1 in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. That removes PHP's own memory cap, so use a container or cgroup limit as the boundary instead, preferably one that kills only the affected worker. Don't use RLIMIT_AS or RLIMIT_DATA for that: those can cause the very allocation failure the flaw needs.
Set a low post_max_size: 8M for applications without file uploads, 32M if you need them. Keep upload_max_filesize below it.
Enforce limits at the web server or proxy on decoded request size, input field count, multipart part count, header count and nesting depth, including for requests without a usable Content-Length.

For CVE-2026-109619 (stale global state):

Set session.upload_progress.enabled=0 in php.ini, an FPM pool or the server configuration, and restart every worker. Not with ini_set() or an FPM .user.ini, which apply too late. This blocks the confirmed session paths, not other variants.
On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
Remove invalid or deprecated settings applied per request that emit diagnostics before initialisation. Hiding diagnostics with error_reporting, display_errors or @ doesn't help.
Fix fatal errors and execution timeouts an attacker can trigger, including in callbacks, upload or import processing, and cleanup.

For an FPM pool that doesn't take file uploads, the settings part comes down to this:

; In every pool that serves web requests, then restart PHP-FPM
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 2M
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5 only
php_admin_flag[fatal_error_backtraces] = off

An earlier version of this post, following Aikido, said not to set memory_limit = -1 and that the upload progress setting didn't help. PHP's advisory says otherwise for the paths above.

If you'd rather not depend on settings, the options from this morning still stand. Take the site offline, with PHP out of the path: stop PHP-FPM and let the web server serve a static page, because a CMS's own maintenance mode runs after PHP has already parsed the request. Or limit who can reach it, with a VPN, an IP allowlist or authentication at the reverse proxy. A WAF such as Cloudflare's is a stopgap that only helps if your origin refuses traffic that doesn't come through it.

And limit the damage in case a server does get hit: keep less data on it, lower its privileges, remove stored credentials such as cloud roles, and send logs somewhere an attacker can't wipe them.

5. End-of-life PHP

PHP 8.1 and older get no release. Given the severity, PHP published minimal source backports for PHP 7.4, 8.0 and 8.1 as branches in its GitHub repository, such as PHP-8.1-CVE-2026-109618-109619, meant for people who build PHP from source and have no LTS vendor. Some distributions and LTS vendors ship backported fixes, so check with yours. Otherwise upgrade to 8.2 or later, or take the site off the internet until you can. CERT-EU advises considering isolating internet-facing applications from public networks until a fix can be applied.

6. Watch what PHP starts

When PHP gets exploited, it usually shows up as the PHP process starting things it never should. Alert when php-fpm, php-cgi, httpd or apache2 launches:

shells: sh, bash, cmd.exe, powershell.exe
interpreters: python, perl
download and network tools: curl, wget, nc, certutil.exe
quick recon: whoami, id, uname -a

Also look out for reverse-shell patterns like /dev/tcp/, fsockopen and mkfifo in command lines.

7. Check for compromise

Patching doesn't remove what an attacker left behind. Aikido advises looking back to at least June 2026 for web shells, unexpected files, new admin users, unusual outbound connections and modified PHP files, and for new cron jobs or scheduled tasks. The exploits leave few traces in application logs, so also look for what Wiz and Aikido name as signals: unusual multipart requests followed by memory-limit errors or repeated HTTP 500s, unusually large or malformed PHPSESSID cookies in responses, and PHP workers restarting without a clear cause. If you find something, isolate the server and keep the web server and PHP logs before you clean up.

Because one of the bugs leaks worker memory without leaving much behind, rotate passwords, API keys, tokens and other secrets on internet-facing servers that ran a vulnerable PHP, even if you find nothing.

What this means for Symfony and Laravel projects

Calif confirmed remote code execution without a login on Symfony 8.1 and Laravel 13.11, and that's not because of a bug in either framework. Your framework version doesn't matter here, and neither does your composer.json. A "php": "^8.2" constraint doesn't protect anything: it's the PHP binary on the server that has the bug. composer audit won't flag it either, because PHP isn't a Composer package.

What does matter is where your PHP comes from. In most of the projects I work on, that's a Docker base image or the server's packages, so the work today is in the Dockerfiles, the deploy pipeline and the servers, not in the application. If you deploy through CI, make sure the next build actually pulls the patched image instead of a cached layer. If you run FrankenPHP, as more and more Symfony and Laravel projects do, it's on PHP's list of affected setups too.

One more Symfony connection: Symfony core developer Nicolas Grekas is one of the five developers PHP's changelog credits with the fix.

Frequently asked questions

Is my site vulnerable to PHP2Shell?

If it runs PHP that serves web requests (PHP-FPM, mod_php, php-cgi, FrankenPHP or LiteSpeed) and isn't on 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a patched distribution package, assume yes. PHP rates mod_php the most at risk.

Which PHP version fixes PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Distribution packages may carry the fix under an older version number, so check their changelog for CVE-2026-109618 and CVE-2026-109619.

Can I fix it in my code or with Composer?

No. The flaws are in PHP itself, so the fix is updating PHP on the server or in your container image. Application code and Composer packages don't change your exposure.

Does Cloudflare protect my site?

Partly. Cloudflare's WAF rules can block known exploit attempts, but only for traffic that goes through Cloudflare, and Aikido says no complete WAF rule exists yet. If attackers can reach your origin server directly, the rules don't help. Patching is still required.

Do php.ini changes protect against PHP2Shell?

Partly, and only against specific attack paths. PHP's advisory lists memory_limit=-1, a low post_max_size and request limits at the web server for CVE-2026-109618, and session.upload_progress.enabled=0 for CVE-2026-109619. It also says there are no complete mitigations: updating is the only safe choice.

Why were DigiD and MijnOverheid offline?

As a precaution against PHP2Shell. According to NOS, Dutch organisations including DigiD, MijnOverheid, the Tweede Kamer, Tweakers and the National Cyber Security Centre took their sites offline on 21 October, until PHP's fix was out and installed. PHP released it around 14:00 UTC, 16:00 Dutch time, and DigiD, MijnOverheid, the NCSC and Tweakers were back online that evening.

Is there a public exploit for PHP2Shell?

The researchers' write-ups are public, from Wiz and Calif, and according to Sansec an exploit tool is too. Wiz and Calif demonstrated remote code execution without a login on WordPress, Drupal, Joomla, Symfony, Laravel and more. Before the release, fake or broken "exploits" circulated as well, so don't run code from forums or unknown repositories on your servers.

Should I rotate passwords and API keys?

On internet-facing servers that ran a vulnerable PHP version, yes. One of the bugs lets an attacker read part of a PHP worker's memory without logging in, and that memory can hold passwords, tokens and API keys. That kind of read leaves few traces, so rotate after updating even if you find nothing.

Will PHP 7.4 or 8.1 get a fix?

Not as a release. PHP published minimal source backports for PHP 7.4, 8.0 and 8.1 for people who build PHP from source, and some distributions and LTS vendors backport fixes too: Ubuntu, for example, ships fixes for PHP 7.4 and older through Ubuntu Pro. The safe route is upgrading to PHP 8.2 or later.