php2shell: Critical flaws allow code injection in PHP

Critical security flaws in the error handling and memory management of PHP, a web scripting language, could allow malicious code to run on millions of web servers worldwide. Every PHP version released over the past decades is affected, even the long-obsolete PHP 5. Anyone running a web server with the open-source scripting language should update it immediately.

The first of the two vulnerabilities, collectively named php2shell, is CVE-2026-109618 (CVSS 9.2, critical ). It lies in the scripting language’s memory management. The flaw is exploitable if certain prerequisites are met and the memory limit set in the PHP configuration file (directive: memory_limit ) is reached. PHP then generates an execution error – and should clear from memory all remnants of the script that failed to run.

But if the script has stumbled over an upload form crafted by an attacker or one containing particularly cleverly nested arrays, PHP can falter while cleaning up those remnants. The result: Attackers can read and free memory, then run their own malicious code in the web server’s user context.

A second flaw was found in error handling, the process of handling script errors. To successfully exploit CVE-2026-109619 (CVSS 9.2, critical ), an attacker needs at least two HTTP requests, in addition to prerequisites similar to those for CVE-2026-109618. The first creates an unstable state in PHP’s error handling; the second exploits it. However, not all “fatal errors”, meaning errors that cause a script to stop, are exploitable.

Neither exploit works on the first or second try; it can take several thousand requests to trigger one of the vulnerabilities. In a short video, the discoverers at Calif show how they use php2shell to run system commands on a web server running the Laravel PHP framework after 38 seconds.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes Video (TargetVideo GmbH) geladen.

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (TargetVideo GmbH) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung .

Attacks are generally possible without prior authentication – remote code execution works reliably within several thousand to tens of thousands of HTTP requests, making it suitable for automated attacks like Heartbleed. There is no known evidence that cybercriminals or other bad actors are already exploiting the flaws – but that is likely to change soon.

The underlying vulnerabilities can be exploited in various web servers and SAPIs (Server APIs) offered by PHP. Both Apache’s mod_php and PHP via FPM (FastCGI Process Manager) are vulnerable, as is LSAPI (LiteSpeed Server API). It is unclear whether FrankenPHP is affected, but PHP web servers on Windows are definitely vulnerable.

The vulnerabilities were originally scheduled to be disclosed on Oct. 22, but the date was moved up by a day because of a leak. The PHP team says it found the flaws in every PHP version since PHP 5, which reached end of life 21 years ago. Only the updates released now provide complete protection – administrators can reduce the risk of a successful exploit somewhat, but they cannot eliminate it.

Updated PHP versions are available for download on php.net for various operating systems and will be released for major Linux distributions in the coming hours. The versions are

Backports will be available for versions 7.4, 8.0 and 8.1, but anyone using an older PHP version should take this opportunity to update immediately and move to at least PHP 8.3. Support for that version runs through the end of 2027, while PHP 8.2 reaches end of life at the end of 2026. Anyone looking for the longest possible runway should update straight to PHP 8.5.12.

Applications running in Docker containers that include a vulnerable PHP version are also affected and should be updated as soon as updates become available (for example, with “ docker compose pull && docker compose up -d ”).

Anyone hosting web applications should check whether their provider plans to install the updates promptly, for example by checking its maintenance page. Some of the hosting providers contacted by heise security on Wednesday morning had already been warned and had in turn alerted their customers; Uberspace even announced that it would temporarily disable PHP services entirely at 3:45 p.m. Meanwhile, CDN and network provider Cloudflare has implemented rules for its web application firewall (WAF) that block all known attack vectors. The rules are also available to users of Cloudflare’s free plan, but are only a temporary fix, Cloudflare CTO Knecht said on social media.

The PHP team has published a series of configuration settings that can somewhat limit abuse, but warns: “They should not be considered as anything other than a temporary crutch”.

post_max_size less than one-quarter of the memory limit, or 8M as a fallback

Set max_input_nesting_level to a low value, such as 8

session.upload-progress.enabled=0

For PHP-FPM: Set pm.max_requests to a low value

Use SELinux / AppArmor,

set fatal_error_backtraces=0 and

hide the presence of PHP with expose_php=0 .

All of these measures can negatively affect the speed or functionality of a PHP installation, so they should be applied judiciously. And they are no substitute for promptly installing an update.

Web and application servers aren’t the only devices that use PHP; various network-connected devices also rely on it, for example to power their web-based management interfaces. Administrators should check all such devices when updating, including products from these manufacturers ( source )

Security appliances from Citrix, Palo Alto and Ivanti also use PHP, as well as BIGIP load balancers by F5. Network administrators should treat them as part of the attack surface, not as part of their defenses, if their management or web interfaces are exposed to the internet.

Even those who use PHP only for internal applications should not assume they are safe. Outdated PHP installations or appliances running PHP can help attackers who have infiltrated a network, for example with Windows malware, establish a persistent foothold there.

The PHP Group is working hard to secure the ecosystem. After many years, it commissioned a source code audit again in 2024, which uncovered flaws similar to the ones just disclosed. The developers themselves acknowledge in the PHP blog that there apparently was disagreement at the time how to fix them. In May 2026, the PHP Foundation launched the Ecosystem Security Team and hired three security experts. AI is also becoming part of the PHP security team’s day-to-day work.

PHP release manager Volker Dusch told heise security: “After many weeks of work, I’m very glad we got the release out.” The leak was unfortunate, but: “Through the work up to that point we were well prepared, had time to coordinate and the opportunity to protect users as best as possible”, Dusch added.

PHP has a reputation as an insecure language because, especially in older versions, it made it all too easy for beginners to cobble together web applications with extremely dangerous security flaws – the PHP-written WordPress had one such flaw just under four weeks ago. But critical security flaws in the scripting language itself have become comparatively rare. The last such issue in the language core was CVE-2017-5340 in 2017, a problem with deserializing user input that attackers could also have used to inject their own programs.

This article was originally published in German . It was translated with technical assistance and editorially reviewed before publication.