Critical PHP Vulnerabilities: How We Responded

On 21 October 2026, the PHP project released emergency fixes for two critical vulnerabilities.

The two flaws are known collectively as PHP2Shell and tracked as CVE-2026-109618 and CVE-2026-109619. Either one can allow an attacker to run code on a web server without logging in!

PHP is the software that sits underneath Drupal, WordPress and most other content management systems. This was not a module or theme issue. It was a flaw in the foundation those platforms are built on.

All sites hosted and supported by Drupal Centric are protected. No action is required.

What Happened

Details of both vulnerabilities leaked online on 20 October, ahead of the planned disclosure date. In response, the PHP security team brought its release forward to 21 October.

The two flaws work differently:

• CVE-2026-109618: When PHP runs out of memory part-way through a request, it can leave invalid data behind. Its clean-up process then treats that data as valid.
• CVE-2026-109619: Internal data from one request can survive after it should have been discarded, and the next request on the same server process can reuse it.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier have reached end of life and will not receive a fix.

Why Drupal Sites Were Exposed

Drupal 10 and Drupal 11 both run on PHP. The attack is processed by PHP before Drupal executes a single line of code.

That means Drupal’s own safeguards could not stop it: user permissions, login protection and security modules all run too late.

Sites still running Drupal 7 on older PHP versions are a particular concern. Those PHP versions will not be patched.

How We Responded

• Around 9:00am, 21 October: We applied mitigation changes across our hosting, before any official fix existed.
• Early afternoon, 21 October: PHP published its security release.
• Immediately afterwards: We installed the patched PHP versions.

Clients did not need to update anything, change settings or contact us.

Why Acting Early Matters

The most dangerous period for any critical vulnerability is the gap between public disclosure and patching. During that window, attackers scan the web for servers that have not yet been updated.

With these details leaked a day early, that window opened sooner than anyone planned.

Protection was in place before the patch was even available.

If Your Site Is Hosted Elsewhere

If your Drupal site is hosted by another provider, or on your own server:

• Check your PHP version under Reports → Status report in Drupal
• Update to a fixed release, or your Linux distribution’s patched package
• If you are on PHP 8.1 or earlier, plan an upgrade to a supported version as a priority
• Make sure PHP-FPM, or your web server, is restarted so the patched version is actually running

The Bigger Picture

Security isn’t a one-off task. We monitor, patch and strengthen our servers every day.

Most of our security work happens quietly, but this incident gets a post of its own because PHP underpins so much of the web.

If you would like your Drupal site supported by a team that acts before the headlines, get in touch.