PHP2Shell: Critical Vulnerabilities in PHP and What Website Owners Should Do

If your website, blog, or online store runs on PHP—and most websites built on WordPress or similar systems do—you should check your version. Two critical vulnerabilities in the PHP core itself, known as PHP2Shell, allow attackers to execute code on the server without logging in, under certain configurations. Patches were released on October 21, 2026. What is certain, what is debatable, and what should you do?

What happened

The vulnerabilities are designated CVE-2026-109618 and CVE-2026-109619, and both have a CVSS v4.0 severity score of 9.2, meaning they are critical. These are flaws in the PHP interpreter itself, not in a specific application. Therefore, they also affect websites whose own code is sound.

Process

• According to the timeline from security analyses, the Calif research team discovered the first ways to remotely execute code in early August 2026 and notified PHP developers a few days later. At the end of August, the Wiz team also reported the vulnerabilities.
• Details were leaked to the public on October 20, 2026, ahead of the planned coordinated disclosure.
• The PHP developers released fixes on October 21, 2026.

Which versions have been fixed

The security releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The developers’ official statement is that there is no complete workaround, and updating is the only safe option.

Older versions

According to security advisories, PHP versions 8.1 and older are end-of-life and remain vulnerable. For versions 7.4, 8.0, and 8.1, developers have released only source code fixes (backports) without ready-to-install packages. Systems running these versions must be upgraded to a supported branch. According to analyses, the vulnerability affects PHP versions starting with 5.4 from 2012.

Note on distribution packages

Linux hosting and distribution providers often incorporate fixes into their own packages, where the version number may differ from the official one. Therefore, it is not enough to simply compare the version number; you must verify whether the provider has applied the fix. This is a general observation, not a claim based on a single source.

It is already being abused

Sources differ on the details here, so we’ll share what we know:

• Security teams reported attempts at exploitation even before the patches were released: One of the major cloud service providers detected an attempt as early as October 17, and a content delivery network provider reported the first attacks on October 21, at which point it deployed temporary web firewall rules. Another security firm stated that it had observed exploitation in live environments.
• The U.S. agency CISA issued a call on October 21 for the immediate deployment of patches. As of October 22, however, according to one source, it had not included either vulnerability in its catalog of actively exploited vulnerabilities.
• An analysis from October 22 states that publicly available exploits do not work against a default PHP installation, and an attack requires knowledge of the target and specific conditions, making widespread exploitation less likely than originally expected. However, according to PHP documentation, remote code execution has been verified under default settings via Apache with the mod_php module. Sources therefore differ in their estimates of the likelihood of exploitation.

For website owners, the conclusion is simple: don’t wait for the dispute to be resolved—just implement the fix.

Which configurations are the riskiest?

According to the advisory, installations running Apache with the mod_php module are most at risk. However, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed are also vulnerable. One of the vulnerabilities relates to memory handling during a memory shortage error, and the other to an incorrect state during request cleanup. We won’t go into technical details here, as they aren’t necessary for protection.

What website owners should do

If you have shared hosting

• Ask your provider if they have applied PHP patches and for which versions. This is their responsibility.
• Check your hosting control panel to see which version of PHP your website is set to. If it’s 8.1 or older, request an upgrade to a supported version and test the website after the change.

If you manage your own server

• Update PHP to the fixed release or to a distribution package that includes the fix, and restart the relevant services.
• Upgrade older versions. Remaining on an end-of-life version poses a long-term risk.
• Partial measures, such as limiting memory and request size limits, are cited in one security analysis as a way to reduce the attack surface. They are not a substitute for updating.

After the update

• Check the server logs and look for unusual requests or new files in the website directories.
• If you suspect a security breach, change passwords and access keys and restore the website from a clean backup.

Why is artificial intelligence mentioned?

Some reports state that the vulnerabilities were discovered by artificial intelligence. The sources we found mention research teams and OpenAI among the discoverers and reporters, but the role of AI in the discovery itself is not clearly established from these sources. Therefore, we do not present this as a fact.

What we haven't confirmed

• The AI found the errors. Sources are not clear on this.
• Extent of exploitation. Sources differ, and according to one source, as of October 22, CISA had not classified these as actively exploited vulnerabilities.
• The situation on Slovak hosting providers. We do not have data on which providers have already deployed patches.

Conclusion

PHP2Shell is proof that a critical bug in a core tool can affect a huge number of websites at once. You don’t need to understand the technical details: check your PHP version, ask your provider for a fix, and stop using outdated versions. The situation changes every day, so be sure to check the latest advice from PHP developers before deploying.