At a Glance:

Product / Component	Affected Versions	Patched in
PHP 8.5	prior to 8.5.12	8.5.12
PHP 8.4	prior to 8.4.27	8.4.27
PHP 8.3	prior to 8.3.36	8.3.36
PHP 8.2	prior to 8.2.35	8.2.35
PHP 8.1 and older	affected, no official support anymore	no official release; source backports for 7.4, 8.0, and 8.1

• Vulnerabilities: CVE-2026-109618 and CVE-2026-109619 (status CVSS 9.2, critical)
• Exploit: Proof of Concept publicly available; according to Amazon, widespread exploitation, with the first attempted attack on October 17.
• Patch available since: October 21, 2026, packages for Debian and Ubuntu already available.
• BSI criticality: 3 / Orange (BITS-H 2026-297981-1132, Version 1.1)

Timeline: What has happened so far

• October 17, 2026: Amazon detects the first exploitation attempt in its honeypots (MadPot), four days before publication.
• October 20, 2026: Details on the vulnerabilities are disclosed early. The PHP project announces an emergency security release.
• October 21, 2026, 16:00 CEST: PHP releases versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 along with the technical advisories. The discoverers from Wiz Research, OpenAI Codex Security, and Calif present their research on php2shell.com.
• October 21, 2026: CERT-EU and BSI issue warnings, with BSI categorizing the situation as Orange and reporting a public proof of concept in version 1.1. Ubuntu releases patched packages (USN-8948-1), and Debian also provides packages. Some operators in Germany proactively take websites offline.
• Since October 21, 2026: According to Amazon, PHP2Shell is being widely exploited. The RUS-CERT at the University of Stuttgart has verified a public exploit on a test system.

Which software is affected?

The vulnerability resides in PHP itself, not in a specific application. Therefore, any software running on a vulnerable PHP version is affected: Content Management Systems like WordPress, Drupal, TYPO3, and Joomla, shops like Magento, Shopware, and WooCommerce, Nextcloud, Moodle, MediaWiki, and custom applications on Laravel or Symfony. According to the discoverers, even a simple „Hello World“ page on a vulnerable PHP version is sufficient. An update of the application alone does not close the gap; the crucial factor is the PHP runtime environment underneath.

The BSI also points out that PHP is included in components of proprietary products and appliances, such as in the firewall distributions pfSense and OPNsense. The Dutch NCSC maintains a list of affected products on GitHub, which is continuously updated.

According to the PHP advisory, all PHP installations processing web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP project assesses the risk as highest with mod_php : There is a demonstrated exploit where a request triggers the attack without any login, even before application code runs.

PHP-FPM is also affected. For CVE-2026-109619, Remote Code Execution has also been demonstrated against PHP-FPM via the normally active Session Upload Progress feature, although this method requires a suitable operation in the application. Red Hat assesses the vulnerability as lower for its distribution („Important“): Under Red Hat Enterprise Linux, PHP-FPM runs by default, and code execution is practically difficult there.

What attackers can achieve with the exploit

• Execute code: In the event of successful exploitation, attackers execute code with the rights of the web worker account. The discoverers demonstrated this without logging in against current container images of WordPress, Drupal, and Joomla.
• Reading memory: CVE-2026-109619 also allows reading the memory of the PHP process without executing code. According to the discoverers, this may contain passwords, authentication tokens, API keys, and certificates from other requests or the server. Such attacks are harder to detect.

The two vulnerabilities in detail:

• CVE-2026-109618 – Remote Code Execution via Out-of-Memory Error (GHSA-w8hw-w9fx-j79w): If PHP aborts a request due to lack of memory while internal request data is only partially initialized, the cleanup routine may treat this invalid data as valid. According to the advisory, the lack of memory can be deliberately triggered via crafted multipart requests.
• CVE-2026-109619 – Remote Code Execution via Outdated Global State (GHSA-6wmf-4rv5-p3rp): State associated with a request can survive in the worker process after its memory has already been freed. A later request in the same worker can use this state before it is reset (Use-after-free).

The CVSS score indicates a high attack complexity. However, in practice, this hardly matters anymore due to publicly available exploits and ongoing attacks. Unit 42 from Palo Alto Networks counts more than 22.6 million internet-accessible instances that may be vulnerable, according to its own telemetry data.

Find affected PHP systems in the inventory

Those wanting to patch quickly must first know where PHP is actually running. A complete inventory includes not only the known web servers but also subdomains, legacy systems, test environments, Docker containers, appliances with embedded PHP, and websites hosted by external providers or service providers.

How do I check the PHP version?

• On the server: php -v displays the version from the command line. The web server can use a different version. Therefore, also check the FPM version with PHP-FPM, depending on the distribution, for example with php-fpm -v or php-fpm8.3 -v.
• Installed packages: under Debian and Ubuntu with dpkg -l | grep php, under Red Hat and related systems with rpm -qa | grep php. The package version of the distribution is decisive, not the version number of PHP itself.
• Docker: The PHP version is in the image. Images must be updated or rebuilt, an update on the host is not sufficient.
• From the outside: Some servers reveal the PHP version in the HTTP header X-Powered-By. The absence of the header does not mean that PHP is not running.

Patched packages of the Linux distributions

Distribution	Package	Patched in
Debian 13 (trixie)	php8.4	8.4.27-1~deb13u1
Debian 12 (bookworm)	php8.2	8.2.35-1~deb12u1
Ubuntu 26.10	php8.5	8.5.9-0ubuntu2.1
Ubuntu 26.04 LTS	php8.5	8.5.4-0ubuntu1.5
Ubuntu 24.04 LTS	php8.3	8.3.6-0ubuntu0.24.04.13
Ubuntu 22.04 LTS	php8.1	8.1.2-1ubuntu2.28
Ubuntu 20.04 LTS and older	php7.4 and older	Correction only via Ubuntu Pro

Distributions backport the fix into their own packages. An Ubuntu server with „PHP 8.3.6“ can therefore be patched even though the version number looks older than 8.3.36. The advisory from Red Hat applies to Red Hat Enterprise Linux.

What You Should Do Now

• On PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 Update or apply the patched packages from the distribution.
• Those using the voluntarily maintained repository rpms.remirepo.net: According to the PHP project, there were no updates on the release day. The PHP project advises switching to distribution packages or building from source.
• After the update, restart all PHP workers, such as PHP-FPM pools and Apache.
• Don't forget PHP in Docker containers and appliances: rebuild images, pay attention to new firmware from manufacturers for appliances.
• Contact the hosting provider if you do not operate the web server yourself, and request immediate implementation.
• PHP 8.1 and older: The PHP project no longer provides updates for this. Minimal source code backports have been provided for PHP 7.4, 8.0, and 8.1. According to the BSI, all versions prior to 8.2 have reached their end of life, and PHP 8.2 will only receive security updates until the end of the year. Affected systems should be migrated to a supported version.
• Look for signs of an attack starting from October 17, 2026.

Where immediate updates are not possible, RUS-CERT and BSI recommend disconnecting affected systems from the internet or restricting their accessibility until the updates are installed.

How do I recognize an attack?

According to the discoverers, there is no single characteristic that reliably identifies every attack. They mention the following clues for an investigation:

• unusually large or faulty PHPSESSID cookies in server responses,
• unusual multipart requests followed by memory errors („memory limit“) or repeated HTTP 500 responses,
• unexplained crashes or restarts of PHP workers.

Amazon advises that investigations should begin not only from the publication date but at least from October 17, 2026. If such traces are missing, a system is not relieved: reading from memory may leave hardly any traces in the application logs. The BSI has not yet published binding indicators of attack. If signs of exploitation are found, one should assume that access data, tokens, and keys from the PHP process may be affected and should be exchanged. Specialized incident response service providers offer help with the investigation; the BSI maintains a list of qualified providers.

Transitional measures when the update is not yet possible

The PHP project outlines measures that make individual attack vectors more difficult. It explicitly emphasizes that only the update is a complete solution; RUS-CERT and BSI also warn that the measures can be bypassed. According to the BSI, all measures must be implemented together to significantly complicate exploitation.

• Against CVE-2026-109618: memory_limit=-1 set it so that applications cannot overwrite the value (e.g., via php_admin_value in the FPM pool or in the Apache configuration), and post_max_size keep low (8M without file uploads, otherwise 32M). Additionally, set size and number limits for requests on the web server or proxy.
• If the application does not need multipart forms, the PHP project recommends blocking such requests at the frontend before they reach PHP.
• Against CVE-2026-109619: session.upload_progress.enabled=0 in the php.ini or set in the FPM pool and restart all workers; ini_set() and .user.ini are not enough. Under PHP 8.5 additionally fatal_error_backtraces=0. Those who do not need session upload progress should leave the feature disabled according to the PHP project even after the update.
• If performance does not matter, the PHP project mentions pm.max_requests=1 as another option: Then each FPM worker only processes one request, and obsolete state cannot carry over to the next request.
• Check error logs with error_reporting=E_ALL for warnings before script start, fatal errors, and „maximum execution time exceeded“ and fix any found errors. An unobtrusive log, according to the PHP project, is not proof that a system is secure.
• Web Application Firewalls: Providers like Cloudflare have published rules against known attack vectors. According to the BSI, only the update or disconnection from the internet provides complete protection.
• Regardless, the BSI recommends using SELinux or AppArmor to limit the consequences of a successful code execution.

DACH and EU Context

For entities in the scope of NIS-2: If exploiting these vulnerabilities leads to a significant security incident, the reporting obligations under Art. 23 of the NIS-2 Directive apply, in Germany under § 32 BSIG. In Austria and Switzerland, the respective national reporting obligations apply. The BSI has issued a BSI IT security advisory (BITS-H 2026-297981-1132) with a criticality level of Orange; this can be shared freely as TLP:CLEAR.

How LocateRisk Addresses Exposed Assets

LocateRisk supports External Attack Surface Management by providing visibility of externally accessible systems and deployed software. In this incident, it can help find publicly accessible web servers and PHP installations in the asset inventory, including those not listed in any internal list, and prioritize the update sequence.

LocateRisk does not replace patch management and makes no statement about whether a vulnerable PHP version is running on a detected system. This requires matching the deployed version with the PHP advisory or the package status of the distribution.

For outsourced web applications or customer portals, vendor risk management can additionally help document feedback from service providers regarding the patch status.

Am I affected?

Affected are PHP versions before 8.2.35, 8.3.36, 8.4.27, and 8.5.12, as well as any older PHP version; the vulnerability is fixed in 8.5.12, 8.4.27, 8.3.36, and 8.2.35, or in the patched packages of the distributions. Anyone wanting to know if PHP is at all visible in their externally accessible infrastructure can check the CVE Quick Check Use the tool at the end of this article: It shows exposed systems and the software that is visible from the outside.

It is not always possible to determine the specific version that has been installed from the outside—the key factor is comparing it with the manufacturer's advisory.

Sources and further information

• PHP / php.net: Security advisory: Critical remote code execution vulnerabilities, update now
• PHP / GitHub: GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618)
• PHP / GitHub: GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619)
• Wiz, OpenAI, Calif: PHP2Shell – Research page of the discoverers
• BSI: BSI IT security advisory 2026-297981-1132: PHP: Critical vulnerabilities threaten web applications worldwide
• Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure in MadPot
• RUS-CERT University of Stuttgart: Critical vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619)
• NCSC-NL: php2shell – List of affected products
• Debian: Security Tracker CVE-2026-109618
• Ubuntu: USN-8948-1: PHP vulnerabilities
• Red Hat: CVE-2026-109618
• Unit 42: CVE-2026-109618 and CVE-2026-109619
• CERT-EU: Security Advisory 2026-018: Critical Vulnerabilities in PHP

As of: October 22, 2026. This contribution is for general informational purposes and is not legal, security, or action advice in individual cases. The security situation and patch availability may have changed since publication; the linked vendor advisory is always authoritative. Despite careful research, we do not guarantee the timeliness, accuracy, and completeness.

---