PHP: Two Critical Core Vulnerabilities Put Millions of Web Instances at Risk.

Two critical vulnerabilities have been disclosed in the PHP core (CVE-2026-109618 and CVE-2026-109619, CVSS v4.0 score 9.2). Attackers can exploit these flaws to execute arbitrary code remotely without prior authentication. Security updates have been available since 21 October 2026, and initial exploitation attempts have already been observed. Update affected systems immediately.

As of: 22 October 2026   

Two critical vulnerabilities have been identified in PHP's core memory management and request-processing components. Both flaws carry a CVSS v4.0 score of 9.2 and enable unauthenticated Remote Code Execution (RCE). Within the security community, the vulnerabilities are collectively referred to as "php2shell."   

The scale of this issue differs fundamentally from typical appliance vulnerabilities. As PHP continues to power more than half of all websites worldwide, the global footprint exceeds one million internet-accessible systems that may be vulnerable. Measured by websites rather than servers, the impact is even broader: according to W3Techs, PHP runs on approximately 70 percent of websites whose server-side programming language is known, including widely used content management systems such as WordPress, TYPO3, Drupal, and Joomla. Since multiple websites often share a single server, the number of affected websites is likely many times higher than the number of vulnerable servers. 

The urgency is further heightened by the fact that the CVE identifiers were disclosed before the planned publication date, prompting the PHP project to release the updates earlier than scheduled. Exploitation attempts were observed prior to disclosure, and security researchers have demonstrated attacks against WordPress, Drupal, Joomla, and Magento installations. Initial proof-of-concept exploits are already publicly available. On 21 October, Germany's Federal Office for Information Security (BSI) issued a cybersecurity warning and classified the situation as Alert Level 3 (Orange). As a result, relying solely on a manual patching process across distributed web and server environments presents significant risk. 

Your immediate priorities: Identify all exposed PHP instances, upgrade affected systems to fixed versions without delay and restart all PHP processes after patching. If immediate patching is not possible, isolate affected systems and implement the temporary mitigation measures published by the PHP project. 

You are affected if you operate web applications, APIs, or third-party appliances running a vulnerable PHP version and accepting requests from untrusted networks, particularly the public Internet. All common deployment models are affected, including: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. According to the PHP project, deployments using mod_php face the highest risk. In this scenario, a single unauthenticated request can trigger exploitation before any application code is executed.

You can determine your PHP version from the command line using php -v or via your web server's package and container management tools. Note that Linux distributions frequently backport security fixes into their own package versions. Consequently, a version number lower than those listed above may still contain the fix. The authoritative source is the security bulletin issued by your Linux distributor or software vendor. For unsupported branches 7.4, 8.0, and 8.1, the PHP project has published straightforward source-code patches, and some distributors provide backports. In the medium term, migrating to a supported release branch is strongly recommended. PHP 8.2 will receive security updates only until 31 December 2026.  

The vulnerabilities affect not only traditional web servers such as Apache or Nginx with PHP-FPM. Hosting control panels (e.g., Plesk and cPanel), applications that bundle PHP, and network or security appliances may also use PHP for management consoles, portals, or API interfaces. Since customers typically cannot update the runtime environment on such systems themselves, remediation depends entirely on security updates, firmware releases, or hotfixes provided by the respective vendors. 

Please prioritize the following steps. Applying the update is the only complete remediation and takes precedence over all temporary mitigation measures. 

1. Inventory PHP Systems and Assess Exposure. 

Immediately establish a comprehensive inventory of all publicly accessible web assets. For each system, document the PHP version and its source, whether it is provided through a Linux distribution, third-party package repository, container image, hosting provider, control panel, or software that bundles PHP. This information determines when the security update becomes available and who is responsible for providing it. Attack Surface Management (ASM) and automated discovery scans are essential for identifying shadow IT, forgotten test environments, and outdated containers across your deployment pipeline. 

2. Prioritize Based on Reachability. 

In complex environments, it is rarely possible to update all systems at the same time. Assess attack paths carefully: PHP instances directly exposed to the Internet without additional security controls should be patched or isolated first. Internal systems accessible only through authenticated networks should follow in a second phase. 

3. Apply Security Updates Immediately. 

Upgrade all affected systems to the fixed releases or vendor-supplied patched packages as soon as they become available. Afterwards, restart all PHP-related processes (PHP-FPM, Apache, php-cgi), otherwise vulnerable code may remain loaded in memory. In containerized environments such as Docker and Kubernetes, rebuild and redeploy base images accordingly. Organizations relying on packages from rpms.remirepo.net should note that no updates are currently available there and should temporarily switch to distribution-maintained packages.  

4. If Immediate Patching Is Not Possible: Isolate and Mitigate. 

If immediate patching is not possible, remove internet-facing applications from public access or isolate them until remediation has been completed. This recommendation is also supported by CERT-EU. In addition, the PHP project has published temporary mitigation measures, including configuration changes in php.ini (for example, session.upload_progress.enabled=0) and request size and rate limits at the web server or proxy layer. Web Application Firewall (WAF) rules can provide an additional layer of protection by blocking exploitation attempts. However, PHP explicitly states that none of these measures fully secures an affected system; they merely reduce exposure and buy time until the necessary updates can be applied. 

5. Check for Compromise and Improve Detection Time. 

Review web server and access logs dating back to 17 October 2026 for signs of suspicious activity. Common indicators include PHP or web server processes launching shells, script interpreters, or download utilities such as curl and wget, as well as newly created files or web shells within web directories, new cron jobs, or unexpected user accounts. If compromise is suspected, immediately isolate the affected system, preserve relevant log data, and engage the Bechtle Security Incident Response Team (SIRT). Because one of the vulnerabilities may expose sensitive memory contents, any passwords, API keys, or certificates stored on the affected server should be rotated following a compromise. Given that automated attacks can reduce exploitation windows to a matter of minutes, Security Operations Centers (SOCs) should ensure that detection and response capabilities are configured to react rapidly to alerts originating from the web perimeter. 

1. Inventory Appliances and Software. 

In addition to your own web applications, identify all perimeter security and networking appliances that provide web-based interfaces. Use software inventories or Software Bills of Materials (SBOMs) to determine whether vulnerable PHP components are present. 

2. Remove Management Interfaces from the Internet. 

Review the accessibility of administrative interfaces exposed by gateways, firewalls, and load balancers. Administrative management interfaces should never be directly accessible from the public Internet. Restrict access to dedicated management networks or enforce access through secure VPN and ZTNA connections. 

3. Closely Monitor Vendor Advisories (PSIRT). 

Contact vendors to determine whether their products are affected and track their security bulletins closely. Pay special attention to temporary workarounds, such as disabling vulnerable functionality, and deploy firmware updates immediately upon release. 

4. Implement Compensating Controls and Virtual Patching. 

If portals hosted on third-party appliances must remain publicly accessible, deploy compensating security controls. Use Web Application Firewalls with up-to-date generic exploit signatures to detect and block malicious payloads before they reach the appliance. Virtual patching is not a substitute for vendor-provided updates.  

Unlike previous incidents involving products such as Citrix NetScaler or BeyondTrust, which affected a comparatively limited set of identifiable gateways, PHP is deeply embedded in web servers, content management systems, e-commerce platforms, hosting control panels, and appliances, often without the knowledge of the IT organization operating them. Exploitation attempts were observed before public disclosure, and security vendors have reported active attacks since 21 October 2026.  

In addition, attackers can use AI-assisted analysis to rapidly convert newly disclosed vulnerabilities into large-scale scanning and exploitation campaigns. Organizations that continue to rely exclusively on manual patch cycles spanning several weeks risk having systems compromised before the next maintenance window begins.

BSI: Cybersecurity Warning "PHP: Critical Vulnerabilities Threaten Web Applications Worldwide"

PHP: Security Advisory and Fixed Releases

CERT-EU: Security Advisory 2026-018

You can implement the required mitigation and patching measures independently. If resources, expertise, tooling, or capacity are limited, Bechtle can provide vendor-neutral support. Customers of the Bechtle Cyber Defense Center (CDC) should contact their usual CDC representatives.