It has been a tense week for website and server administrators around the world. On October 21 the PHP project, the programming language behind a large share of the web, from content management systems to online stores, released emergency updates for two critical vulnerabilities. Dubbed PHP2Shell and tracked as CVE-2026-109618 and CVE-2026-109619, they were rated 9.2 on the CVSS 4.0 scale. According to the researchers, they could let an attacker run code on a vulnerable server remotely, with no username or password.
What made the story the talk of the industry was not only the severity of the flaws but how they were found. According to reports, researchers at security firm Wiz, owned by Google, and at AI company Calif tracked down the problems with the help of advanced models from OpenAI and Google. Wiz said it identified the first flaw in August and reported it to the PHP developers a few days later, starting a responsible disclosure process that ended with the release of the patches.
Who is at risk
According to published summaries, the vulnerability affects a wide range of versions, from PHP 5.4 to 8.5. Common ways of running PHP on a server, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, appear on the list of affected configurations, with Apache plus mod_php rated the most dangerous. Many headlines spoke of up to 70 percent of websites. That figure reflects how widely the language is used, not a count of servers actually breached.
Fixes are available in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anyone running PHP 8.1 or older will not get an official fix from the project and will need to upgrade or check whether their distribution offers its own patch. The official advisory says there is no complete workaround and that updating is the only safe option.
The clock is ticking
As with almost every high-profile vulnerability, the gap between disclosure and exploitation attempts was very short. According to the trade press, proof-of-concept code appeared on GitHub within hours. Amazon reported active attack attempts, and The Hacker News reported that an exploitation attempt was recorded four days before the official disclosure. That last detail raises uncomfortable questions: did the information leak, or did someone else find the same problem in parallel?
Two days after the emergency updates, the PHP developers announced another issue that has not yet been fixed, CVE-2026-115560. According to the advisory, it is lower risk because it only affects applications configured in an unusual way. Administrators should still keep an eye on it.
What to do now
For small site owners on shared hosting, the first step is to confirm with the host that the update has been installed. Organizations that run their own servers should map every place PHP runs, including forgotten containers and old base images, upgrade to a patched version and check server logs for signs of intrusion attempts. It is also worth making sure monitoring tools and web application firewalls have the latest signatures. They do not replace the update, but they can catch attack attempts.
