Critical PHP flaws: what to check now and what to have tested

TL;DR

• On 21 October 2026 the PHP project shipped emergency updates for two critical flaws, CVE-2026-109618 and CVE-2026-109619. Both allow remote code execution without logging in.
• Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer get regular updates.
• The flaws sit in PHP itself, not in a plugin or CMS. WordPress, Drupal, Magento and Laravel on a vulnerable PHP version are affected too.
• Workarounds reduce exposure but do not make a server safe. Update and restart every PHP process.
• Then look for what you forgot: old servers, systems hosted elsewhere and anything reachable from the internet.

Last week, parts of the Dutch and Flemish public sector went offline on purpose. Not because of an attack, but because of two flaws in PHP, the language behind a large share of the web. The picture is still changing and the details get sharper by the day. One thing is settled: if you run PHP and have not updated yet, you have work to do. This post covers what you check yourself, and what you let someone check who looks at your systems the way an attacker does. That second part is what a penetration test is for, and if you want it faster or more often, RedSOC gives you pentesting on demand.

What happened

On 20 October 2026, PHP's security team announced an emergency release for two critical vulnerabilities. The updates landed on 21 October, a day earlier than first planned, after details leaked ahead of time. The PHP project rates both flaws 9.2 out of 10 (CVSS v4.0). Higher numbers circulated elsewhere, so the score depends on who you ask. The severity does not.

Together the two flaws are known as PHP2Shell, and they sit deep in PHP itself. CVE-2026-109618 comes from the way PHP handles running out of memory: a request that stalls halfway leaves half-built data behind, and PHP treats that data as valid during cleanup. CVE-2026-109619 is about internal state that survives after its memory is freed and gets reused by the next request on the same worker, a use-after-free. The outcome is the same either way: an attacker sends a request without logging in and runs code on your server. We are deliberately stopping there on the technical side.

Who is affected

Every PHP installation that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project singles out mod_php as the highest risk, because a working attack exists there that runs before your application code gets a turn.

Because the flaw lives in the language and not in a plugin or CMS, what runs on top does not matter. WordPress, Drupal, Magento, Laravel or a custom portal from ten years ago: on a vulnerable PHP version they are all exposed. CERT-EU warns that every version since PHP 5 may be affected.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive regular updates. The project only published minimal source patches for 7.4, 8.0 and 8.1 and points you to your distribution or vendor for the rest. If you are on one of those, this is the moment to upgrade rather than patch around it.

What to check now

Start with an inventory of every host running PHP, including the ones outside your own control. The marketing site at an external agency. The intranet someone set up in 2018. The test environment that is accidentally public. The monitoring tool with a PHP front end. During pentests we find forgotten systems like these more often than clients expect, and they rarely run the latest version.

Check the active version on each host, not the installed one. A package update writes new files to disk, but the running PHP processes keep executing the old code until you restart them. The PHP project says it plainly: restart every worker. So the question is not "did the update run" but "which version does the running FPM pool or Apache module report right now".

If any hosts run a version without a patch, plan the upgrade. Workarounds such as setting session.upload_progress.enabled to 0 and lowering the maximum request size shrink the attack surface, but the PHP project is clear that they do not make an installation safe.

Then look at what is reachable from the internet. Anything with a public IP address or a hostname in DNS goes first. And go through your logs for suspicious requests from before the update, because the details were public before the patch was. A server that was compromised in the meantime does not become clean by patching it.

What a pentest adds

A version check shows what you see. A pentest shows what an attacker sees. With this flaw, that gap is wide.

First, the external attack surface. In a penetration test we map which of your systems are reachable from the internet, including the ones missing from your inventory. That is exactly where the forgotten PHP hosts live.

Second, validation after the patch. A package manager reporting "up to date" does not prove the vulnerable code is gone. We test from the outside whether it is really closed. Every Sectricity pentest comes with a retest included, so once you have fixed the findings you get confirmation that the fix holds.

Third, speed. You do not plan a full pentest on a Wednesday afternoon. RedSOC is pentesting on demand: you spend credits when you need them, for instance on a targeted check of your PHP hosts, without starting a full engagement. How that works is in our RedSOC explainer.

Frequently asked questions

Which PHP versions are patched?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive regular updates; for those there are only minimal source patches and whatever backports your distribution provides. An upgrade is the real fix there.

Is a site on WordPress, Drupal, Magento or Laravel affected too?

Yes, if the PHP version underneath is vulnerable. The flaw is in PHP itself, not in the CMS or framework. Updating WordPress or Laravel does not fix it; the PHP version on the server has to go up.

Are the temporary mitigations enough?

No. Settings such as session.upload_progress.enabled set to 0 and a lower maximum request size reduce the risk, but according to the PHP project they do not make an installation safe. They bridge the gap until you can update, nothing more.

Why do you have to restart PHP after updating?

Because the running processes keep the old code in memory. A package update writes new files to disk, but PHP-FPM workers or an Apache module with mod_php keep running what they loaded at startup. Only after a restart does the active version report the new number.

What does a pentest do that a version check does not?

A version check looks at the systems you know about, from the inside. A penetration test looks from the outside, finds the hosts that are not on your list and tests whether the vulnerability really can no longer be exploited. Once you have fixed the findings, a retest follows.

Is the flaw already being exploited?

Reports differ. The PHP project mentions a working attack against mod_php and some parties saw attempts on the web, while other authorities had not seen active exploitation at the time of publication. The situation is still moving. Assume that every PHP host that is reachable from the internet and not yet updated is a target.

Related services and resources

If you want to be sure this flaw is closed on your side, start with a penetration test, with a retest included once you have fixed the findings. If you need to move faster, RedSOC is pentesting on demand. For background, read what a pentest actually is and our posts on why a retest is always included and RedSOC explained. If you build products on PHP, product security under the CRA belongs on your list too.