October 26th 2026
Reading time approx. 20 min. php2shell from an attacker's perspective: affected and demonstrably exploitable, priority, testing area and reach. According to the PHP project,
On October 21, 2026, PHP closed two critical vulnerabilities known as PHP2Shell. On the same day, the state of Baden-Württemberg, the university hospitals of Freiburg, Heidelberg, and Mannheim, the Charité hospital, and other institutions took their websites offline as a precaution. The German Federal Office for Information Security (BSI) classified the situation as alert level 3 (orange).
For CEOs, CIOs, and CISOs, this isn't a matter of a single website, because PHP runs on WordPress, Typo3, Drupal, Moodle, e-commerce platforms, and many custom developments. Anyone using PHP—and that's most companies somewhere—is potentially affected.
Therefore, it is crucial to know which systems in your company are running PHP, which version, and who maintains them.
(Information as of October 22, 2026, morning. The situation is evolving.)
These are two memory vulnerabilities in PHP itself, not in a single CMS. According to the PHP security team, both can be exploited remotely without login or user interaction. With Apache and mod_php, the attack occurs before any application code even runs.
The PHP security team rates both vulnerabilities using CVSS 4.0. 9,2A previously circulated value of 10,0 was incorrect.
Current status of the investigation: Amazon is now observing widespread exploitation by multiple actors, while Cloudflare and watchTowr are reporting attempted attacks. A successful breach has not yet been publicly confirmed. Whether a working exploit exists is disputed: the PHP Foundation found none at the time of release, while HelpNet Security reported one.
The vulnerabilities were discovered twice independently, and both times with AI support:
Neither source specifies which of the two CVEs is based on which find.
The flaws had been embedded in the code for a long time. According to Wiz, the underlying architectural decisions date back more than ten years, with the oldest affected code originating from PHP 5.4 from 2012. OpenAI clarifies that, to their knowledge, the vulnerabilities were previously unknown.
The lesson learned: AI finds vulnerabilities that have been overlooked for a decade. This helps defenders, but the same tools are also available to attackers. The fact that an attack was launched four days before the patch, despite the embargo, shows how narrow the window of opportunity has become.
The defensive perspectiveOur sister company demonstrates how companies can protect themselves against PHP2Shell and which countermeasures are effective. ProSec Defense in the article on PHP2Shell and the WAF emergency patch.
CVE-2026-109618 This is a bug in how PHP handles limited memory. If PHP runs out of memory while the data for a request is not yet fully prepared, PHP still cleans up this incomplete data as if it were valid. An attacker can deliberately cause this situation.
CVE-2026-109619 This is a so-called use-after-free. A residual from a request points to memory that has already been released. A subsequent request to the same PHP process can then utilize this memory. Additionally, PHP confirms that memory contents can be read in this way.
In practical terms, this means that a single, specially crafted web request can be enough to execute arbitrary code on the server. Afterwards, the attacker has access to databases, configuration files, and customer data, and the web server becomes the starting point for further attacks on the network.
Any PHP installation that handles web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The highest risk is with mod_php. The oldest affected code found by the Calif research team was in PHP 5.4.0 (2012), which is about 14 years old. The often-cited "20 years" refers not to the exploitable code, but to the underlying class of vulnerabilities, which dates back to 2004.
| Version | Status |
| 8.5.x | Patched from version 8.5.12 |
| 8.4.x | Patched from version 8.4.27 |
| 8.3.x | Patched from version 8.3.36 |
| 8.2.x | Patched from version 8.2.35 |
| 7.4 – 8.1 | No official release, only minimal source backports and distribution packages. |
| 5.4 – 7.3 | End-of-life, no fix from PHP |
Linux distributions and LTS providers received the patches before the official release. Users who obtain PHP from distribution packages should check for updated packages there and not rely solely on the PHP version number.
BSI: The BSI has issued a warning level 3 (orange) and advises considering a temporary disconnection of the web server from the internet if the patch cannot be installed immediately.
Baden-Württemberg: The state took numerous government websites offline, including those of ministries and regional government offices. The Ministry of the Interior classifies the vulnerability as highly critical and emphasizes that no successful attack occurred. The systems will be gradually restored after an update by the state service provider BITBW.
Hospitals and universities: The university hospitals in Freiburg, Heidelberg, and Mannheim took their websites offline; in Freiburg, this also included the website for the patient app. All three emphasize that patient care is not affected. At the University of Freiburg, the ILIAS learning platform and web access to student email accounts were affected.
Other facilities according to dpa: In Berlin, the Charité hospital, the Berlin Fire Department, and the Berlin Food Bank; the Free University and Humboldt University of Berlin warned of potential restrictions. In Brandenburg, the University of Potsdam, the Ernst von Bergmann Hospital, and the Dahme-Spreewald district issued warnings. In Mainz, the city portal mainz.de.
There is no complete official list.
These shutdowns demonstrate the high cost of a lack of transparency. Anyone unsure which systems are affected must proactively take everything offline that might be using PHP. Those with a well-maintained inventory can patch selectively and remain accessible.
In addition, there are two points that go beyond the individual case:
A compromised web server provides precisely the data criminals use to make money: customer data for credible phishing attacks, email login credentials for business email compromise, and database passwords for the next step. If the website is connected to CRM, ERP, or single sign-on systems, it becomes the boundary between the internet and internal business processes.
The wave of attack attempts shows the typical pattern: first, a broad scan is conducted, then the promising leads are selectively expanded. Anyone who establishes access today might later see it sold to another player.
The regulatory perspectiveOur sister company outlines which documents, reports, and decisions are required subsequently. ProSec Governance regulatory.
1. Clarify inventory
2. Patching
3. Bridging the gap where a patch is not yet possible
4. Replace old versions
5. Check for compromise
A patch that has been installed is not proof that a system is clean. The crucial factor is whether all affected systems were found and whether anyone was logged in before the patch was applied.
PHP2Shell affects almost every organization that runs web applications. The organizations that had to take everything offline yesterday didn't have a patching problem, but an inventory problem.
Those who know where PHP is running can patch specifically and remain accessible. Those who don't know have to shut down and still can't be sure that no one has previously compromised their system.
PHP2Shell is the name given to two critical vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619) that allow attackers to execute code on web servers without authentication. The name is similar to Log4Shell.
Yes, if WordPress is running on an unpatched PHP version. The vulnerability lies in PHP itself, not in the CMS. A WordPress update alone will not close it.
A programming error where software accesses memory that has already been released. Attackers can fill this memory with their own data and thus take over the program's execution.
The update closes the vulnerability, but only after restarting the PHP workers. Since attacks were already occurring before the patch, you should also check whether the system has already been compromised.
There is no fix for PHP versions 5.4 through 7.3. For versions 7.4 through 8.1, there are only minimal backports. These systems should be replaced or taken offline.
Reading time approx. 20 min. php2shell from an attacker's perspective: affected and demonstrably exploitable, priority, testing area and reach. According to the PHP project,
OpenAI Agent and Hugging Face: What companies and decision-makers should know now. An autonomous AI agent from OpenAI is to be used during a cybersecurity test.
WordPress supply chain attack, IT security for businesses, plugin security, cybersecurity, supply chain attack. What at first glance appears to be a WordPress plugin problem is actually...