The US cybersecurity agency CISA added the two PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 to its catalog of actively exploited vulnerabilities on October 26, 2026. Through these flaws, attackers can execute their own code on a web server without logging in. The PHP project rates both at 9.2 out of 10 points (CVSS 4.0) and classifies them as critical in its security advisory of October 21.
Every PHP installation that serves websites is affected, whether via PHP-FPM, Apache with mod_php or LiteSpeed. Every WordPress site therefore also depends on the question of which PHP version its server is running. A WordPress update does not help here, because the flaws are in PHP itself.
What has happened since the update?
On October 21, the PHP project released the secured versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On the same day, the Federal Office for Information Security (BSI) called for the updates to be applied without delay. Since then, the vulnerabilities have been circulating under the name PHP2Shell.
PHP2Shell: from update to attack
Two critical vulnerabilities in PHP, as of October 27, 2026
- October 21, 2026PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35
- October 24, 2026Attackers execute their own commands 35 times on three test servers
- October 26, 2026CISA lists both vulnerabilities as actively exploited
- October 27, 2026Censys counts over 4 million services in Germany with a vulnerable version number
The Censys figure is based on version numbers; the scanner does not detect fixes that were backported.
Sources: PHP project, CISA, honeypot-data on GitHub, heise online
The first public evidence of successful attacks was provided on October 24 by Adel Karimishiraz, who leads threat detection at the AI company Perplexity and runs honeypots on the side, that is, deliberately vulnerable decoy servers. On three of these servers running PHP 8.4.26 and the Apache module mod_php, attackers executed their own commands a total of 35 times from two IP addresses, as his report on GitHub shows. The attackers' attempts to download additional programs failed in the test environment.
How many servers are still open can only be estimated. According to heise online, the scanner of the security firm Censys counted more than 4 million services in Germany on October 27 that report a vulnerable PHP version. Censys itself notes that Linux distributions often backport the fix into older version releases. The figure is therefore only a rough indication.
How do you find out whether your website is affected?
In WordPress, the page "Tools" › "Site Health" shows you the PHP version in the "Info" tab under "Server". The secured versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, as well as any later version of the same series.
An older number in the report does not yet prove an open vulnerability. Many hosts build the fix into their own PHP packages without changing the version number. The only way to be certain is to ask whether the two CVE numbers are closed on your server.
For PHP 8.1 and older, the PHP project no longer issues regular updates. For 7.4, 8.0 and 8.1, the security team provided only minimal fixes in the source code, which hosts have to incorporate themselves. WordPress recommends PHP 8.3 or newer anyway, and for PHP 8.2 the security updates end on December 31, 2026.
What this means for you
It's best to check the Site Health of every WordPress site you look after today and note down the PHP version. If the version is below the secured numbers, write to your host and ask specifically whether CVE-2026-109618 and CVE-2026-109619 are closed in your plan. If your host fails to give a clear answer, the comparison of shared hosting, cloud and VPS helps you find a new provider.
With many hosts, you can also switch the PHP version to 8.3 or 8.4 yourself in the customer menu. Afterwards, it's best to briefly test whether your theme and plugins run cleanly.
If you run your own server, install your distribution's PHP packages and restart PHP-FPM or Apache. The PHP project makes clear that interim workarounds such as disabling session.upload_progress do not make an installation secure; only the update fully closes the vulnerabilities.
A look under "Users" doesn't hurt either: administrator accounts that you did not create are a reason to involve your host immediately. How to set up backups and basic protection for a WordPress site is shown in the lesson Security and Backups in the WordPress course.
CISA added the two vulnerabilities to its catalog on October 26, 2026.
Sources
