php2shell: two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619 — businesses must update now

On 21 October 2026, the PHP project released emergency patches for two vulnerabilities that the security community collectively calls php2shell: CVE-2026-109618 and CVE-2026-109619. PHP rates both 9.2/10 (Critical), and both let an attacker run code remotely without logging in on a web server that uses PHP. If your company's website, management software or portal runs on PHP — WordPress, Laravel, Magento, Drupal, Joomla or custom code — the short answer is: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 today, restart every PHP process, and only then worry about the rest.

What happened to PHP?

This is an out-of-band security release from the PHP project, after details of the vulnerabilities leaked ahead of disclosure. On 20 October 2026, the PHP security team posted an advance notice on the php.announce mailing list, scheduling patches for 14:00 UTC on Wednesday 21 October 2026 for two vulnerabilities "both rated CVSS v4.0 9.2, Critical". According to Tenable, the original date was 22 October but it was brought forward a day because the CVE IDs had spread on Hacker News and social media — along with an incorrect CVSS score of 10.0.

Huntress recounts how it unfolded: on the morning of 20 October, a Hacker News post claimed two critical PHP vulnerabilities were about to be disclosed; the post was removed, but screenshots had already circulated. VirusTotal recorded that the archive mentioned in the leaked analysis was first uploaded at 02:29 UTC on 21 October, a few hours before the patches were available.

According to Sansec's timeline, the Calif research team found multiple code execution paths starting 1 August 2026 and reported the first bug to PHP on 11 August; Wiz Research reported the vulnerabilities to PHP on 24 August. The GitHub advisories credit four reporters and four developers who fixed the issues. Google Cloud also wrote that its Gemini 4 Argon model contributed to finding the vulnerabilities and developing exploit code — a detail showing that AI is now being used on both sides of the security problem.

The name "php2shell" was not coined by PHP. PHP's official pages use only the CVE and advisory IDs; the name appears in CISA's alert and in researchers' write-ups.

How do the two vulnerabilities work?

In short: both are memory management bugs inside PHP that occur while PHP parses and cleans up the data of a web request — that is, before your application code even gets to run. That is why login mechanisms, access control or application-layer firewalls cannot stop them.

CVE-2026-109618 — memory corruption on out-of-memory. According to advisory GHSA-w8hw-w9fx-j79w, PHP uses longjmp() to bail out immediately when a request exceeds the memory limit. If an allocation fails just as internal data is half-initialised, PHP does not correctly record that early exit; the cleanup step afterwards then treats the half-built data as valid. Attackers trigger this condition with specially crafted multipart requests (the request type used for forms and file uploads). Rapid7 notes that these requests can exhaust memory "even when their size appears to meet PHP's configured limits". The confirmed impact is unauthenticated remote code execution, under the account of the web process.

CVE-2026-109619 — use-after-free. According to advisory GHSA-6wmf-4rv5-p3rp, one request can leave internal state pointing to memory that has already been freed; the next request handled by the same process then reuses that stale state before PHP can reinitialise it. The two confirmed exploitation paths are configuration notices raised before request initialisation, and the session upload progress feature. Impact: memory disclosure and remote code execution. Sansec adds that the upload progress handler can return freed memory to the browser inside the PHPSESSID cookie, even when the application never calls session_start().

Who is affected, and which versions are safe?

Every PHP version from 5.4 up to the patches of 21 October 2026 is affected if it is serving web requests. The security notice on php.net states clearly that the at-risk group is "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed", and that the highest risk is mod_php, where proof-of-concept exploit code has shown that an anonymous request can trigger the attack before any line of application code runs. Google Cloud sums it up: affected is "All versions of PHP from 5.4 through 8.5.11".

For end-of-life branches, php.net says the security team has provided "minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1" for people who compile PHP themselves or have no long-term support vendor — these are code branches on GitHub, not releases. CISA goes further: organisations still using PHP 8.1 or older "should take PHP-based systems offline until they can be patched or updated".

A common point of confusion: the version number does not always tell you the true patch status. Datadog and Red Hat both warn that Linux distributions sometimes backport fixes without changing the upstream version number. Conversely, Red Hat says RHEL 8, 9 and 10 are affected, while RHEL 7 and earlier ship PHP versions that are not vulnerable to these two bugs. Users of the Remi repository (rpms.remirepo.net) should take note: according to Sansec, it did not yet have the patch on 21 October.

As for applications: Tenable cites Calif's findings confirming pre-authentication remote code execution on certain specific versions of WordPress, Drupal, Joomla and Magento. Datadog puts it more simply: any PHP file opens a path to the bug, even a file that just prints a single line of text.

How severe is it really?

Serious, but different parties score it differently and also disagree on how hard it is to exploit. PHP scores it 9.2 under CVSS v4.0, with Attack Complexity set to High and Attack Requirements set to Present. Red Hat rates it "Important" rather than Critical, with a CVSS v3 score of 8.1, and writes that reliable exploitation "requires precise heap manipulation and timing", making remote code execution "difficult in practice" — especially with PHP-FPM, the default configuration on RHEL.

The real-world picture is what is worrying. Datadog wrote that its team built an exploit before disclosure, and that PHP's default memory limit is still exploitable; the tuned version returned HTTP 200 and completed in 3.10 seconds in the lab (single process, OPcache disabled). Rapid7 noted multiple signs that the research is being independently reproduced and expects a working exploit to become public soon. Sansec, after the patches and analyses were out, wrote that "the writeups and an exploit tool are public".

Whether attacks have already happened is something the sources do not yet agree on. Sansec cites Cloudflare reporting early attacks at 07:43 UTC on 21 October, before the patch release; Datadog wrote that as of 21 October there had been multiple reports of in-the-wild exploitation, along with widespread scanning. On the other side, CISA had not observed exploitation at the time of its alert, and Huntress said that as of 16:30 US Eastern time on 21 October it had still not seen exploitation across its customers' systems. Some organisations did not wait: Sansec noted that several websites in the Netherlands, including the country's House of Representatives and NCSC, proactively went offline on 21 October; Unit 42 said at least one European government temporarily took down websites as a precaution.

What should businesses do in the next 24 hours?

The only complete fix is to update PHP — every source agrees on this. Rapid7 recommends updating "on an emergency basis, outside of normal patch cycles". The order Namtech recommends for businesses:

1. Inventory. List every website, internal application and portal running PHP — including old servers few people remember, containers and applications that bundle their own PHP. Datadog's reminder: don't rely only on the command-line PHP version on the machine.
2. Identify the version actually serving the web, not just the command-line version: check the hosting control panel, the server's PHP info page, or ask your provider. Compare against Table 2.
3. Update to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, then restart or replace every PHP process still running the old version; for containers, rebuild the image and redeploy.
4. If you can't patch yet, reduce the risk with the configurations in Table 4, and consider putting the system behind a WAF or VPN, or temporarily disconnecting it from the Internet. Sansec is blunt: if you can shut down the PHP server, do.
5. Check for signs of compromise (see the next section) and rotate passwords, API keys and certificates on any suspect server, because the bugs can expose data in memory.

On shared hosting (cPanel, DirectAdmin…), the ability to update PHP usually lies with the provider. Ask your provider directly whether they have applied the patch and when, rather than just switching the PHP version in the control panel and assuming you are safe. On Google Cloud, Google says App Engine standard (PHP 8.2 and later) is updated automatically while App Engine flexible is not; Cloud Run is only patched automatically if automatic base image updates are enabled, and on GKE you must update the image yourself and redeploy.

php.net itself writes that these measures "reduce exposure to specific attack paths but do not make an installation safe", and the advisory states plainly that "there is no complete generic configuration mitigation". VirusTotal adds an easily overlooked point: expose_php = Off only hides the version header, not the vulnerability.

How do you know if a server has been attacked?

Logs alone cannot tell you for certain, but there are a few signs worth checking right away. Datadog describes a PHP error log pattern like "Allowed memory size of … bytes exhausted … in Unknown on line 0" — the "Unknown on line 0" location means PHP failed during the request initialisation phase. When an exploit guesses an address wrong, Apache may log AH00052: child pid … exit signal Segmentation fault (11). A suspicious request may carry a field name about 3.5 MB long. The clearest sign of a successful attack is the web process spawning a shell.

But don't take comfort in seeing nothing: Datadog notes that a successful exploit does not necessarily crash the process or produce errors, and Rapid7 writes that "the absence of relevant log entries is not proof that an installation is safe". For CVE-2026-109619, Rapid7 advises reviewing early configuration warnings, shutdown notices, fatal errors and timeout errors. Because the bugs can expose passwords, session tokens, API keys and TLS private keys from other requests (according to Sansec), any suspect server should be treated as if its secrets have leaked, and those secrets replaced.

Lessons for businesses in Vietnam

php2shell is a reminder of an old truth: the biggest risk often sits in underlying software that nobody in the company pays attention to. PHP is used by 69.3% of websites whose server-side language can be identified (Tenable citing W3Techs), so almost every business has at least one PHP system — a company website, an online store, HR software, an internal portal. VirusTotal's figures are even more concerning: about 4 in 5 PHP servers hide their version, and about 758 thousand IP addresses still run end-of-life branches — systems that will never get an official patched release.

Three things worth doing for the long term, not just for this incident: (1) keep an up-to-date inventory of every system, its version and its owner; (2) don't leave systems running on end-of-life versions — the 8.2 branch reaches end of life on 31 December 2026, which means systems just patched to 8.2.35 also need an upgrade plan within the next two months; (3) keep internal systems off the public Internet when they don't need to be there. This is also why Namtech deploys internal AI on dedicated infrastructure that is not exposed to the Internet: the smaller the attack surface, the less panic episodes like php2shell cause.

php2shell (CVE-2026-109618 and CVE-2026-109619) is a pair of unauthenticated remote code execution vulnerabilities in PHP itself, affecting every version from 5.4 up to the patches of 21 October 2026; the only complete fix is to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every PHP process.

Frequently asked questions

Note: This article compiles public sources checked on 22 October 2026 and reflects the situation at that time — the story is still developing and information may change. Figures on the scale of impact are third-party measurements, with their sources and scope stated; figures on real-world attacks differ between sources. This information is for reference only and does not replace the assessment of the security team responsible for your systems.