A routine-looking software update has become an urgent task for website owners. PHP released security fixes on October 21, 2026, for two critical weaknesses known as PHP2Shell, moving the story from warnings about a forthcoming patch to a practical question: has the software actually running each website been updated?
The flaws, identified as CVE-2026-109618 and CVE-2026-109619, can allow remote code execution without an attacker first logging in, according to the PHP project. That does not mean every PHP website has been hacked. It means an exposed, vulnerable installation needs attention even when its pages still look normal.
Which PHP updates are available?
The project's fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Its advisory covers PHP installations handling web requests and identifies Apache's mod_php configuration as especially high risk. The team says an update, rather than a configuration workaround alone, is the complete solution.
For older installations, the distinction between upstream support and a distributor's maintenance matters. PHP 8.1 and earlier no longer receive normal project updates. The project nevertheless supplied minimal source backports for 7.4, 8.0 and 8.1 because of this incident's severity. Those exceptional patches are not a promise of renewed long-term support; administrators should check their distribution or support vendor.
Why updating WordPress plugins is not enough
Cloudflare explains that the problem sits in the PHP runtime beneath applications, not merely in a website's theme or plugin. Updating a content-management system does not by itself replace the PHP installation serving it. For a managed website, the hosting company may control that layer.
Cloudflare also says it observed attack traffic and deployed web-application-firewall protections. This is the company's account of activity on its network, not evidence that every site has been compromised. Its own guidance still tells customers to patch PHP: filtering is an additional defensive layer, not a substitute for the fix.
How the warning spread
Security company watchTowr warned publicly on X on October 20 that information about the vulnerabilities had leaked, urging users to apply patches when available. It subsequently corrected a typo in the vulnerability identifiers and clarified that it had not discovered the flaws. The episode illustrates why a widely shared screenshot is a starting point for verification, not the final authority on technical details.
CERT-EU's earlier advisory urged organisations to identify PHP applications and prepare for immediate patching. Where remediation could not happen promptly, it advised considering isolation of internet-facing applications. That advice was issued before the scheduled release; readers encountering older warnings should not mistake their future-tense wording for the current availability of updates.
What a website owner should ask now
The useful question for a hosting provider is specific: has the PHP runtime serving this website received the fixes for both CVE identifiers? Ask for the package version or vendor advisory and confirmation that the updated runtime is in use. A statement that the website's plugins are current answers a different question.
This AsiaNews Iran explainer concerns defensive maintenance, not instructions for testing exploits against websites. Avoid downloading supposed exploit demonstrations as a way to check your own status. Keep the response focused on an authorised administrator, the official update path and clear confirmation of what was fixed.
Software risk also has a policy dimension. Our report on DeepSeek and U.S. agency restrictions explains how supply-chain rules affect product use. PHP2Shell is a different problem: a technical flaw that requires maintaining the underlying runtime.
Has your hosting provider explained who handles urgent server updates? Share your experience without posting passwords, private logs or other sensitive account information.