PHP Security Vulnerabilities CVE-2026-109618 and CVE-2026-109619: What Every PHP Website Needs to Patch Now

The Short Version:

Two critical PHP security vulnerabilities, CVE-2026-109618 and CVE-2026-109619, let an attacker run code on a PHP website with one crafted web request and no login. Here is the state of play:

• Both carry a CVSS v4.0 score of 9.2. Researchers nicknamed the pair PHP2Shell.
• The PHP patch landed on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• PHP 8.1 and older are end of life and get no fix. Those sites need a version upgrade.
• The bugs are in the PHP engine, so WordPress, Magento, Drupal, Joomla and Laravel sites are affected even when their own code is clean.
• Palo Alto Networks counted more than 22.6 million exposed instances in its telemetry.
• Attack attempts started before the fix shipped. Amazon dates the earliest to 17 October.
• PHP says no configuration change fully blocks either flaw. Updating is the only complete fix.

How The PHP News Broke

The schedule was decided by a leak. On 20 October 2026, details of two unpatched PHP security vulnerabilities surfaced online ahead of the coordinated disclosure date. The PHP security team posted an advance notice that evening and moved the release forward, saying it could ship even earlier if active exploitation appeared.

On 21 October at 14:00 UTC, PHP published the advisory and released 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The GitHub advisories went live 26 minutes before the announced time. Fixed Windows builds appeared on downloads.php.net at 13:47 UTC.

The bugs were found in August 2026 by the researcher Calif, with Wiz Research and OpenAI reporting independently. Calif filed the first report to PHP on 11 August. Sansec traced the vulnerable code back to PHP 5.4.0, which shipped in 2012, so this is roughly fourteen years of exposure.

CVE-2026-109618 VS CVE-2026-109619 PHP Vulnerability

CVE-2026-109618 abuses PHP’s memory limit. While PHP sets up an incoming request, it marks some internal state as ready before every allocation it needs has succeeded. Send a request big enough to exhaust the memory limit and PHP gets interrupted partway through, leaving that state half built and never rolling it back. The cleanup routine then treats the leftover memory as valid, which is a use after free (CWE-416). From there an attacker can corrupt memory and run their own code. On top of that, the flaw can leak server memory back to the attacker.

CVE-2026-109619 works differently. Internal state tied to one request survives after its memory is freed, so a later request handled by the same worker picks up the stale data. Both end in the same place: remote code execution without credentials.

Severity ratings vary by setup. Red Hat rates CVE-2026-109618 Important rather than Critical for its own distributions, on the basis that standard Red Hat Enterprise Linux builds run PHP-FPM, whose workers exit on early initialization failures before reaching the corrupted structures. Red Hat says exploitation there is difficult in practice and usually needs non-default behaviour, such as parsing a second request body during script execution. That is a reason to check your own stack, not a reason to skip the PHP patch.

Is Your PHP Website Affected?

If PHP serves web requests anywhere in your stack, assume yes until you have checked the version. PHP says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Because the flaws live in the engine, the application on top does not protect you. Sansec reports that an attacker without a login can run code against stock installs of Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3 and Nextcloud 35.0.1.

Run php -v on each server, and remember the places PHP hides: container images, staging boxes, cron workers, CI pipelines and old client sites nobody has touched in two years.

Is Anyone Exploiting It Yet?

Reports conflict, which is normal this early. Amazon says its MadPot honeypot network logged the first exploit attempt on 17 October, four days before disclosure, with more on 21 October carrying varied payloads that it reads as several different actors. watchTowr reported exploitation across its own honeypots on 21 October. Cloudflare’s CTO described early attacks and the company pushed temporary WAF rules as a stopgap. Patchstack said it had confirmed multiple active incidents.

On the other side, CISA said it had not observed exploitation when it published its 21 October alert, and Huntress saw none in partner environments as of 20:30 UTC that day. Researchers speaking to CyberScoop described mostly reconnaissance, scanning to find out which servers are still exposed. As of 22 October, neither CVE had been added to CISA’s Known Exploited Vulnerabilities catalog.

The NSA was blunter: it expects attackers to weaponize both flaws, and CISA advises taking systems offline if they cannot be patched quickly. Sansec had predicted mass attacks within fifteen minutes of the release. Treat the quiet period as a head start, not an all clear.

Applying The PHP Patch

1. Inventory every PHP install. Web servers, containers, staging, build images, anything that answers HTTP.
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, whichever matches your branch. Debian, Red Hat and Ubuntu have shipped fixed packages, and cPanel and Plesk have published their own guidance.
3. Restart PHP after updating. An unrestarted PHP-FPM pool keeps serving requests with the old binary in memory.
4. Rebuild and redeploy container images. Patching the host does nothing for a vulnerable image.
5. Verify with php -v on the running service, not on the shell default, which can point at a different build.
6. Review logs and traffic from mid-October onward. Attempts predate the fix, so a server patched today could already have been hit.

Sites on PHP 8.1 or older cannot patch. The PHP project is not backporting fixes to end of life branches, so the only real answer is a migration to a supported version. CISA has issued separate guidance for unsupported PHP.

If You Cannot Patch Today

PHP’s advisory is clear that no configuration change fully mitigates either flaw. The settings below narrow the attack paths and each one costs you something. Set them in php.ini, the PHP-FPM pool config or the web server config, then still patch as soon as you can.

A WAF helps at the edge but will not fix the engine. If a server is internet facing, unsupported and unpatchable, CISA’s advice is to take it offline until it can be replaced.

Short On Hands This Week?

Patching one site is an afternoon. Patching forty, across hosts, containers and client environments, with a few stuck on PHP 7.x, is a different problem.

Arpatech has been building and running PHP websites since 2003. Our web development, managed hosting and support teams can check which PHP version each of your sites is actually running, apply the patch, restart services properly, and map out a migration for anything left on an end of life branch.

Talk to our team about your PHP stack