PHP Security & Vulnerability Fixes

Two critical remote code execution flaws in the PHP interpreter itself — together called PHP2Shell — were patched on 21 October 2026. They sit below your application, so every Drupal, WordPress, Laravel, Symfony and bespoke PHP site on an unpatched version is exposed regardless of how well the application is written. If you need someone to assess, patch and verify your estate, that is what this page is about.

PHP2Shell: what was disclosed

Incident facts below reviewed 22 October 2026 against public reporting. This is a developing situation — always confirm against the official PHP release notes before acting.

Two separate memory-safety flaws in PHP's request handling were disclosed and patched on 21 October 2026. Both allow remote code execution, and both are reported as reachable by a single unauthenticated request, before any of your application code runs. That last detail is what makes this different from the usual CMS advisory: no plugin, theme, module or framework is the vulnerable component, so no application-level fix helps.

• CVE-2026-109618 — remote code execution via out-of-memory corruption. An OOM condition can interrupt PHP while request data is only partly initialised, and cleanup may then treat that invalid data as valid.
• CVE-2026-109619 — remote code execution via stale global state. Request-owned internal state can outlive the memory backing it, so a later request on the same worker may reach it before initialisation resets it.

Both are rated critical. I am deliberately not quoting a CVSS figure here: the major outlets covering the disclosure did not publish one, and the scores circulating vary by source. The severity is not in question, but a precise decimal attributed to nobody is not a fact worth repeating.

Whether you are affected

Every PHP installation that serves web requests is reported affected — PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP security team considers mod_php the highest risk configuration. CLI-only usage is not the concern here; anything answering HTTP is.

Check what you are actually running — not what you believe you deployed:

php -v                      # CLI version, often NOT the web version
php-fpm -v                  # the FPM binary
<?php echo PHP_VERSION;     # the version actually serving requests

The third one is the one that matters. It is routine to find a server where the CLI reports a current release while the web SAPI is two minor versions behind, because an upgrade updated one and not the other.

Fixed releases

The patched versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

PHP 8.1 and earlier no longer receive updates from the PHP project. The security team did publish minimal source backports for 7.4, 8.0 and 8.1 for those who build from source or have no LTS vendor, and major distributions and some control panels have shipped backported packages. If you are on 8.1 or older, that is the real finding here — this incident is a symptom.

If you cannot patch today

The PHP security team published interim measures. They are stopgaps, not fixes — some are documented as blocking only one confirmed path — and they are no reason to delay updating. The UK NCSC advised taking offline any system that cannot be remediated promptly.

• For CVE-2026-109618 — set memory_limit=-1, ideally through php_admin_value so applications cannot override it; set a low post_max_size (8M without uploads, 32M where uploads are required); and impose a container or cgroup limit as an availability boundary.
• For CVE-2026-109619 — set session.upload_progress.enabled=0 and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0 and restart workers.
• Remove invalid or deprecated per-request settings that emit diagnostics, and fix attacker-reachable fatal errors and timeouts.
• Cloudflare has deployed WAF rules for known vectors to all plans including free. Treat a WAF as a speed bump, not a remediation.

Restarting workers is not optional with these settings. A long-running FPM pool keeps serving from processes that loaded the old configuration, which is the most common reason a mitigation appears not to have worked.

What an emergency engagement looks like

Roughly a day for a straightforward estate, longer where hosting is unusual or undocumented.

1. Inventory — every host, every SAPI, the version actually serving requests, and which ones are internet-facing. This step routinely finds servers nobody remembered owning.
2. Triage by exposure — public mod_php first, then public FPM, then internal. Patching in exposure order matters when you cannot do everything at once.
3. Patch and restart — vendor packages where they exist, staged through a non-production environment where one exists, with workers restarted and the running version re-verified afterwards rather than assumed.
4. Verify — confirm the web SAPI reports a fixed version, that opcache is not still serving stale bytecode, and that the application still works. A patched server that 500s is not a successful outcome.
5. Compromise assessment — exploitation attempts were recorded before public disclosure, so patching alone does not answer whether you were already hit. Logs, file integrity, unexpected scheduled tasks, modified webroot files and outbound connections.
6. Written report — what was found, what changed, what remains, and what to do about the versions that should never have been this old.

Beyond this incident

PHP2Shell is unusual in severity but ordinary in shape. The same work applies whenever the platform under your application turns out to be the vulnerable component:

• Legacy PHP upgrades — 5.6, 7.x and 8.0/8.1 estates moved onto a supported branch, including the application compatibility work that is the actual reason nobody has done it yet.
• Drupal and WordPress security — Drupal core and contrib advisories, WordPress core, plugin and theme patching, and sites left unsupported long enough to accumulate real risk.
• Patch pipelines — CI/CD and environments arranged so a security release is a routine deploy rather than a weekend. The reason estates stay unpatched is almost never ignorance of the advisory; it is that deploying is frightening.
• Hardening and monitoring — sane php.ini defaults, file integrity monitoring, and alerting that tells you a server is behind before a researcher does.

I work with agencies, enterprises and businesses whose platform has been let go, and the third category is where most of this lands — an unsupported PHP, an agency that moved on, and nobody certain how deployment works. That is recoverable, and usually in less time than people fear.

Common questions