Overview
Publication date: October 21, 2026 | Category: Cybersecurity | Vulnerabilities | IT Security
On October 21, 2026, the PHP security team released emergency security updates addressing two critical vulnerabilities. Both vulnerabilities have a CVSS v4.0 severity score of 9.2 and, under certain conditions, allow an attacker to execute malicious code remotely on a server without prior authentication.
The vulnerabilities have been assigned the identifiers CVE-2026-109618 and CVE-2026-109619. They are also collectively known as PHP2Shell.
The issue deserves particular attention because PHP is widely used to run internet services, corporate web applications, e-commerce platforms, and content management systems (CMS).
The risk is not limited to a single application or website component. The vulnerabilities affect the PHP runtime itself, potentially increasing the scale of their impact significantly.
What Happened, and Why Is the Issue Critical?
On October 20, the PHP security team issued an unusual advance warning about two critical vulnerabilities. The scheduled security updates were released on October 21.
According to the official information, successful exploitation of either vulnerability could result in remote code execution (RCE): the execution of malicious code remotely on a server.
This is particularly dangerous for internet-facing systems, because certain attack scenarios do not require a user account or password.
The PHP security team also confirmed that the vulnerabilities affect various environments that handle web requests, including:
• PHP-FPM;
• Apache mod_php;
• php-cgi;
• FrankenPHP;
• LiteSpeed.
An especially high risk has been identified in the Apache mod_php configuration, where researchers confirmed an attack scenario that can be triggered even before the web application’s code begins to execute.
Given the scale of the threat, websites belonging to government bodies and other organizations in several European countries were temporarily taken offline so that administrators could install security updates.
Two Critical Vulnerabilities: A Technical Overview
CVE-2026-109618 — Out-of-Memory Corruption
Severity: Critical — CVSS 9.2
The first vulnerability concerns PHP’s memory management and its handling of out-of-memory (OOM) errors.
Under certain conditions, a failed memory allocation can interrupt PHP’s processing of the current request before internal data structures have been fully initialized.
The system may subsequently access this data as though it were valid.
Triggering this condition with specially crafted HTTP requests may create the possibility of memory corruption and, ultimately, malicious code execution.
CVE-2026-109619 — Stale Global State
Severity: Critical — CVSS 9.2
The second vulnerability involves incorrect handling of PHP’s global state and memory.
In certain scenarios, PHP’s internal structures may retain references to memory that has already been freed after a request ends.
When the same PHP worker processes a subsequent request, those stale references may be accessed. This condition could lead to the disclosure of information held in memory or to remote code execution.
Confirmed technical exploitation scenarios exist for both vulnerabilities. However, whether an attack succeeds in a particular environment depends on the system configuration, the PHP execution mode, and other technical conditions.
Which PHP Versions Are Vulnerable?
Security fixes have already been released for PHP’s four supported release branches.
PHP 8.5: security update — 8.5.12 or later; recommendation — update immediately.
PHP 8.4: security update — 8.4.27 or later; recommendation — update immediately.
PHP 8.3: security update — 8.3.36 or later; recommendation — update immediately.
PHP 8.2: security update — 8.2.35 or later; recommendation — update immediately.
PHP 8.1 and earlier: security update — official support has ended; recommendation — migrate to a supported version or obtain a vendor-provided security fix.
It is important to note that PHP 8.1 and earlier versions no longer receive regular security updates directly from the PHP project.
Because of the severity of this incident, the PHP team also released special minimal patches for PHP 7.4, 8.0, and 8.1. Their availability does not mean that support for these older versions has been restored.
In addition, some Linux distributions and commercial vendors can integrate security fixes into older packages through security backporting. Therefore, determining whether a vulnerability has been fixed requires checking the vendor’s security advisories as well as the version number.
What Does This Mean for WordPress and Other CMS Platforms?
Widely used platforms such as WordPress, Drupal, Joomla, and many other web applications depend on PHP.
One point is particularly important:
Updating WordPress, its themes, and its plugins does not, by itself, mean that the PHP2Shell vulnerabilities have been fixed.
The vulnerabilities exist in the PHP runtime itself, rather than only in the CMS application code.
Organizations must therefore check the PHP version actually used by their hosting environment or server, along with its security update status.
Customers using managed hosting services should request confirmation from their provider that the relevant security fixes have already been deployed.
What Risks Could Organizations Face?
Following successful exploitation, an attacker may be able to execute code on the server with the privileges of the affected PHP process.
Possible consequences include:
Disclosure of confidential information — access to web application configuration, files available on the server, authentication credentials, and other information.
Web application compromise — modification of application code or website content, deployment of malicious files, or installation of a web shell.
Disruption of business services — loss of availability of the web application and related services.
Further attacks — use of the compromised server to investigate additional systems or carry out other attacks, where network segmentation and access controls permit it.
Organizations whose web applications handle financial operations, customers’ personal data, or transactions, or provide critical services, may face particularly high business risks.
What Should Organizations Do Immediately?
1. Identify Systems That Depend on PHP
The first step is to inventory PHP installations and the services that depend on them across the organization’s infrastructure.
The review should cover internet-facing websites as well as internal corporate applications, test environments, containers, and third-party software products.
2. Prioritize Based on Risk
When deploying updates, prioritize internet-facing systems, especially services that process sensitive data or support critical business processes.
Internal systems should also be assessed, because an attacker who has already gained access to the organization’s network could target them in a subsequent attack.
3. Deploy Security Updates Immediately
Supported PHP installations should be updated to the officially released versions containing the security fixes.
Updates should follow the change management procedure, with the necessary preliminary checks and a recovery plan.
After updating, verify not only the installed package, but also that the PHP processes actually handling web requests are already using the patched version.
4. Apply Temporary Protective Measures
If an immediate update is not possible, the organization should assess whether the vulnerable service needs to be temporarily isolated or disconnected from the public network.
PHP’s official recommendations also include certain temporary technical measures, including:
• Setting session.upload_progress.enabled=0 and restarting the relevant PHP processes;
• Setting fatal_error_backtraces=0 for PHP 8.5;
• Applying additional controls to HTTP request sizes and PHP memory settings;
• Activating the appropriate Web Application Firewall (WAF) rules and protection mechanisms.
These changes should be implemented after a technical assessment of the specific environment, because some settings may affect application functionality and availability.
Important: temporary mitigations do not eliminate the vulnerabilities completely and are not a substitute for security updates.
5. Strengthen Monitoring and Incident Detection
Security teams should pay particular attention to Apache, PHP-FPM, and web application logs.
The following indicators should be monitored:
• Unusual system commands executed by PHP or web server processes;
• New or modified suspicious files in web application directories;
• Unexpected termination of PHP processes, memory errors, and unusual restarts;
• Unusual HTTP requests and attack attempts detected by the WAF;
• New accounts, scheduled tasks, and suspicious outbound connections appearing on the system.
Existing SIEM, EDR/XDR, and other security tools should be used to support monitoring.
If signs of compromise are identified, the organization should activate its incident response procedure and preserve the relevant evidence.
6. Review Third Parties and Hosting Providers
Organizations that use outsourced web development, managed hosting, or business applications operated by third parties should verify their suppliers’ readiness.
It is advisable to request confirmation that the relevant security updates have been implemented, together with information about any remaining risks.
Why Does PHP2Shell Matter for Information Security Management?
PHP2Shell is more than a technical vulnerability. This incident again demonstrates the importance of maintaining a complete inventory of technology assets, using supported software, and responding promptly to vulnerabilities.
Vulnerability management should be an integral part of the information security management system and should cover asset inventory, threat assessment, security update deployment, third-party oversight, and incident response.
The following ISO/IEC 27001:2022 controls are particularly relevant:
• A.8.8 — Management of Technical Vulnerabilities
• A.8.9 — Configuration Management
• A.8.15 — Logging
• A.8.16 — Monitoring Activities
• A.5.19 — Information Security in Supplier Relationships
A timely technical response to this specific incident is important. For long-term cyber resilience, however, an organization also needs clearly defined responsibilities, processes, and control mechanisms.
Conclusion
The PHP2Shell incident once again demonstrates that even a single critical vulnerability in a widely used software component can put the digital services of many organizations at risk.
Organizations’ main priorities are to identify systems that depend on PHP promptly, update vulnerable versions, introduce additional monitoring, and activate incident response processes where necessary.
Effective cybersecurity management begins with knowing which technology assets an organization owns, what risks their use involves, and how quickly the organization can respond to identified threats.
IO Consulting recommends that organizations promptly review the security of their PHP-dependent infrastructure and take a systematic approach to managing critical vulnerabilities.
Sources
PHP — Official Security Announcement, October 21, 2026 — https://www.php.net/archive/2026.php#2026-10-21-5
CVE-2026-109618 — PHP Security Advisory — https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
CVE-2026-109619 — PHP Security Advisory — https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
Cloudflare — PHP2Shell Vulnerability and WAF Protection — https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
UK NCSC — Critical Security Issue Affecting PHP — https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php