What changed
The story that triggered alarm across the cybersecurity world is no longer just an unnamed “web flaw.” Current reporting identifies it as PHP2Shell, a pair of critical vulnerabilities in PHP, the server-side language reported as underpinning more than 70% of websites . The two main issues are tracked as CVE-2026-109618 and CVE-2026-109619, and TechCrunch describes them as bugs that can let an attacker break into a PHP-running online system without a password if the system remains exposed and unpatched .
That last condition matters. A headline number such as “70% of websites” is useful for urgency, but dangerous if read as “70% of sites are already breached.” The current evidence points to an enormous exposed population, a large emergency patching operation, public exploit work and scanning, but not to proof that most affected websites have been taken over . In practical terms, this is a race: defenders must identify every PHP runtime that serves web requests, apply a vendor-supported fix or mitigation, and then check whether attackers reached the system before the update.
Why the blast radius looks so large
PHP sits below many familiar web applications. A site owner may think in terms of WordPress, Drupal, Laravel, a commerce platform, a control panel or a managed hosting plan, while the vulnerable component is the PHP runtime underneath . That is why updating a content management system, theme, plugin or Composer dependency is not enough if the underlying PHP package remains unfixed .
The exposed surface also extends beyond conventional websites. PHP can be embedded in appliances, management portals, hosting stacks and product runtimes. Palo Alto Networks’ Unit 42 said its Cortex Xpanse telemetry identified more than 22.6 million exposed instances potentially vulnerable to the two PHP2Shell CVEs, while also urging organizations to review PHP’s own patching guidance and assess exposure immediately . Cloud Software Group said on October 24 that Citrix NetScaler ADC and Citrix NetScaler Gateway were affected and directed customers to mitigation guidance, illustrating how PHP exposure can show up inside enterprise products, not just public blogs or small business sites .
The technical core, in plain language
Red Hat’s updated bulletin describes the two main bugs as memory-corruption flaws in PHP request handling . CVE-2026-109618 involves an out-of-memory condition during request parsing that can leave PHP with incomplete internal state; later cleanup can then operate on invalid or uninitialized memory . CVE-2026-109619 involves stale pointers to request memory that has already been freed and may be reused during a later operation .
The security consequence is serious because the attacker does not need a login. Red Hat says an unauthenticated remote attacker can trigger memory corruption during PHP request processing and potentially achieve arbitrary code execution . But exploitation is not magic: Red Hat also notes that reliable exploitation requires precise heap manipulation and timing, and that deployment architecture changes the risk . In its assessment, Apache with mod_php is higher risk, while PHP-FPM on Red Hat Enterprise Linux 8 and later can make remote code execution harder in practice because workers exit before reaching the corrupted structures in some failure paths .
That distinction explains why the industry reaction is both urgent and nuanced. Security teams cannot dismiss the flaws because exploitability depends on configuration, but they also should not assume every PHP application has been trivially compromised.
Patches, mitigations and the “not fixed by WordPress” problem
For standard PHP branches, operators have been told to update to fixed PHP releases or to their Linux distribution’s backported package, then restart all PHP workers . Atas.AI’s October 24 update summarized the fixed upstream versions as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, while emphasizing that WordPress, Laravel or Composer updates do not fix a runtime flaw in PHP itself .
Red Hat’s guidance is blunt about the hierarchy of response: configuration changes can reduce exposure, but patching is the comprehensive solution . It says disabling session.upload_progress.enabled can protect against CVE-2026-115560 and reduce some CVE-2026-109619 exposure in specific Red Hat cases, while memory-limit and request-size changes can reduce attacker-controlled paths for CVE-2026-109618 without eliminating the bug entirely . It also stresses that workers must be restarted after changes; stale running processes can leave an environment in a false state of security .
The follow-up issue, CVE-2026-115560, adds one more operational wrinkle. Red Hat says PHP published an informational advisory on October 23 for a third issue in the session upload progress feature, but described it as an unlikely RCE vector requiring an uncommon combination of configuration and application code . The Register also reported that the PHP Foundation planned to address that third issue in the next regular release rather than with an emergency fix, with session.upload_progress.enabled=0 as the practical mitigation in the meantime .
Exploitation: scanning, attempts and caution
The exploitation picture remains unsettled. Sophos corrected an earlier assessment on October 22 and said its telemetry showed scanning and a small number of failed exploitation attempts, with no evidence at that time of successful compromise due to the PHP2Shell vulnerabilities . The company also described a failed attempt to deliver a likely Mirai-derived payload known as Potassium and said it had released additional countermeasures for its firewall and endpoint products .
Unit 42 also stepped back from an earlier interpretation. In its October 25 update, the team said it had initially believed post-compromise activity against a European government agency was related to PHP2Shell, but could not confirm the initial access was associated with the specific CVEs and retracted the October 23 update . That correction is important: in a high-pressure vulnerability event, “attack happened on a vulnerable PHP application” and “this CVE caused the initial compromise” are not the same claim.
The safest reading is therefore: exploitation attempts are real, public proof-of-concept work and scanning raise the risk, but operators should base incident response on logs and evidence rather than panic. Patching closes the known door; threat hunting determines whether anyone walked through it before the door was shut.
What site operators should do now
First, inventory PHP wherever it serves web requests: public sites, admin panels, appliances, containers, CI preview environments, legacy virtual machines and managed-hosting accounts. PHP can be a hidden dependency, so asset lists that only track application names are not enough .
Second, patch through the right channel. If PHP came from a Linux distribution, use that distribution’s security packages and do not rely only on upstream version numbers. If PHP is embedded in a product, follow the vendor advisory. If the environment is end-of-life and cannot be patched, the conservative move is to take it offline or put it behind strict access controls until it can be replaced.
Third, restart the serving layer. PHP-FPM pools, Apache processes, containers, pods and appliance services need to be restarted or replaced so that patched binaries actually handle requests .
Fourth, hunt backward. Review web server logs, PHP worker process activity, shell launches, downloads, suspicious POST requests, new files, cron jobs, credential access and outbound connections beginning before the public patch window. Sophos’ corrected reporting shows why this matters: failed attempts can still leave useful indicators, while successful compromise requires separate proof .
The bottom line
PHP2Shell is exactly the kind of internet-wide flaw that makes a simple percentage headline frightening. The “70% of websites” claim captures how foundational PHP remains, but the real work is more granular: which servers run PHP, which version is actually serving requests, which vendor owns the fix, which processes were restarted, and which logs show signs of attack .
Patch Tuesday has become patch every day. But the lesson is not just speed. It is inventory, dependency ownership and evidence-based response before attackers turn a broad vulnerability into a business-specific breach.
Comments
Be the first to comment.