Critical PHP vulnerabilities: what to ask whoever runs your website today

Status as of 22 Oct 2026. Updated 22 Oct: the article now covers the state of attack attempts, a warning about half-measures and a list of questions for your developer; the first version appeared on the morning of 22 Oct. We removed: the names of the AI models Wiz used, the claim about 70% of websites, Wiz’s claims about adapting the attack within hours and about the affected-versions window of the last decade, and the email template; a list of questions replaces them.

In short. On 21 October 2026 PHP released a security update for two critical flaws. They can let an attacker run their own code, without logging in, on the server that runs your website. The flaw is in PHP itself, not in application code, so updating plugins is not enough: PHP has to be updated. Today, ask whoever maintains your website whether that has been done, and make sure the answer is complete, not partial.

What happened

On 21 October the PHP project announced that versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that can allow remote code execution without authentication (PHP.net). Both are rated 9.2 out of 10 (CVSS v4.0) (Tenable). Every PHP installation that serves web requests is at risk. The PHP team sees the highest risk in setups using mod_php (one way PHP is attached to the Apache server), where the attack can fire before the application itself starts running.

The flaws were found by researchers at security company Wiz together with Calif and OpenAI (as Wiz writes). Wiz demonstrated a working attack against the latest ready-made installations (container images) of WordPress, Drupal and Joomla at the time of testing and writes that even a bare “Hello World” page on an unpatched PHP version can be vulnerable (Wiz Research). Wiz also showed that, even without running code, an attacker can read the server process’s memory, which can hold passwords, authentication tokens and API keys. Sansec writes that the vulnerable code dates back to PHP 5.4.0 (2012) (Sansec).

The AI part: Wiz says it used AI models to find the flaws and build the attack. Wiz also claims that one researcher did in a week what, in their view, would previously have taken a world-class team months. Wiz’s conclusion: complexity may no longer be a barrier to attack.

Are attacks already happening?

Sources report real exploitation attempts. Amazon’s honeypot network (decoy systems set up to attract attackers) recorded an attempt as early as 17 October, four days before disclosure (Help Net Security). On 21 October Cloudflare said it was seeing attacks beginning to emerge (Tenable). Tenable writes that Amazon believes PHP2Shell is now being broadly exploited, and Datadog cites multiple reports of active exploitation and broad untargeted scanning (Datadog). At the same time Amazon says it is unclear whether the 21 October attempts would have succeeded against real systems (Tenable). We did not verify the scale of attacks ourselves; what matters is that attempts have been documented since 17 October, so there is no reason to postpone updating.

Two things where half-measures and sources confuse

1. “Switch off one setting and you’re safe.” A widely shared tip is to disable session.upload_progress.enabled. The PHP announcement itself lists it as a partial temporary measure that closes only the confirmed session paths, not other variants and not the other flaw. PHP says only updating gives full protection, and Datadog says the same about this tip (Datadog). If your developer’s answer is “we switched off one setting”, the job is not done.

2. Mechanism and numbers. On this point the sources themselves disagree. Wiz and Sansec attach the upload-progress flaw to CVE-2026-109618, while the PHP announcement, Datadog and Tenable attach it to CVE-2026-109619 (they describe 109618 as an out-of-memory flaw). So don’t rely on any post claiming to know exactly which setting to switch off for which flaw. Before the official announcement, CVE numbers also circulated with an incorrect score of 10; the PHP team rates both 9.2 (as Tenable writes, citing the PHP Foundation). The practical conclusion is the same in every source we read: update PHP.

Cloudflare says it has deployed initial rules for the known attack vectors, available to all customers including the free plan (Help Net Security). Cloudflare itself calls this a stopgap, and the rules cover only traffic passing through Cloudflare (Tenable). That does not replace updating PHP.

What to ask your developer or hosting company

You don’t have to update servers yourself. You need clear answers:

1. “Does our site run on PHP?” WordPress, Drupal, Joomla and Magento run on PHP; Sansec also names Laravel and Symfony.
2. “Which PHP version is on the server?” The answer must be a specific number, not “the latest”.
3. “Is the version installed on the server at least the patched release of its series: 8.5.x → 8.5.12, 8.4.x → 8.4.27, 8.3.x → 8.3.36, 8.2.x → 8.2.35?” If the number is lower, the job is not done. If PHP comes from a Linux vendor’s package, the version number may differ; then ask them to confirm this security fix is included.
4. “Was this an update, or only a settings change?” A settings change on its own is not finished work.
5. If the version is 7.3 or older: the PHP project releases no fix for these versions in any form, neither a release nor a source patch (Tenable, CIQ). Move to a supported version, or ask your vendor for a fix if it offers one.
6. If the version is 7.4 to 8.1: the PHP project no longer ships updates for those versions. Minimal source-only fixes were released for 7.4, 8.0 and 8.1, but they are intended for those who build PHP themselves or have no access to a long-term-support vendor. Our assessment: this is a separate job to plan, not a five-minute question.

If you can’t update today, the UK’s National Cyber Security Centre (NCSC) urges organizations to consider taking any system that can’t be fixed right away offline (Help Net Security). The PHP announcement lists technical temporary settings for your developer; they do not give full protection.

After updating, ask about keys: if passwords and keys (payments, email, other services) are stored on the server, ask whether they should be changed, since Wiz writes that the readable memory can contain such data. That is our precautionary recommendation.

Sources

• Security advisory: Critical remote code execution vulnerabilities, update now — PHP.net (21 Oct 2026)
• PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet — Wiz Research (21 Oct 2026)
• PHP2Shell: Critical PHP vulnerabilities patched, update now! — Help Net Security (21 Oct 2026)
• PHP2Shell: frequently asked questions — Tenable (21 Oct 2026)
• PHP2Shell: critical vulnerabilities in PHP — Datadog Security Labs (21 Oct 2026)
• PHP2Shell: Critical PHP RCE — Sansec (21 Oct 2026)
• PHP2Shell mitigation — CIQ (21 Oct 2026)