# What the BSI Recommends on PHP2Shell

> BSI warning on PHP: what warning level 3 (orange) means for PHP2Shell, what the BSI recommends and how to apply it to your web servers in practice.

Source: https://phpsos.de/en/compliance/bsi-empfehlungen/  
As of: 25/10/2026  
Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**In short:** The BSI (German Federal Office for Information Security) has declared warning level 3 (orange) for PHP2Shell. The recommendation is unambiguous: update PHP immediately and, if that is not possible immediately, take the affected web servers off the network temporarily. The BSI expected rapid large-scale exploitation; confirmed successful attacks on a broad scale were initially not known.

## The BSI warning on PHP in brief

The Federal Office for Information Security (BSI) is Germany's central specialist authority for cybersecurity. It has published a level 3 (orange) warning on PHP2Shell. The occasion is two critical vulnerabilities in PHP itself: CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. They allow attackers to execute malicious code on the server without logging in.

The core statements of the warning can be summarized as follows:

| Statement | Meaning for operators |
|---|---|
| Warning level 3 / orange | serious situation, action required |
| Immediate update recommended | apply the fixed PHP versions |
| Otherwise temporarily off the network | put protection above availability |
| Rapid large-scale exploitation expected | do not wait for the first damage reports |
| Successful attacks on a broad scale initially not confirmed | no reason for an all-clear |

You will find the respective current version on the BSI's website.

## What "update immediately" means in practice

On 21 October 2026 at 14:00 UTC (4 p.m. German time), the PHP project released the fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For PHP 8.1 and older there are no more official updates, only minimal source backports for 7.4, 8.0 and 8.1.

An update is only effective once all PHP processes have been restarted. New files alone are not enough as long as old workers are running in memory. In addition: distributions and hosts sometimes apply corrections as a backport. In that case, Plesk for example continues to show 8.2.34 although the system is patched. What matters are the package state and the vendor's confirmation. And a CMS update, for example of WordPress, does not close the PHP vulnerability.

## If an update is not possible immediately

For this case, the BSI recommends taking the web servers off the network temporarily. That is a harsh measure, but a clear one. For many companies, a planned outage of a few hours is less damaging than a break-in with data outflow.

php.net also names interim measures that reduce the risk but explicitly do not offer complete protection. These include `session.upload_progress.enabled=0` in the server configuration, limited `post_max_size` values, memory limits via containers or cgroups and, on PHP 8.5, `fatal_error_backtraces=0`, each followed by a restart of all workers. Details are under [Immediate measures without a patch](https://phpsos.de/en/php2shell/sofortmassnahmen-ohne-patch/).

> **Act now:**
> If a publicly reachable web server is still running with unpatched PHP and without interim measures, the BSI recommendation means: take the server off the network until the update has been applied and all processes have been restarted.

## Putting the situation in context

The BSI is not alone in its assessment. Cloudflare reported observed attack attempts and rolled out protection rules, but warns that rules based on the request data alone are not sufficient. Palo Alto Networks (Unit 42) counted more than 22.6 million exposed, potentially vulnerable instances. According to media reports, a first attack attempt was already observed on 17 October 2026, before the patches were published.

For operators, a sober assessment follows: anyone who has not patched by today should not only patch but also check whether something has already happened. A patch does not remove malware that has been planted. There are no published, confirmed indicators of compromise; detection relies on behavioral analysis. The trade press advises keeping server logs from 20 October 2026 onward. Notes on the search are under [Am I already compromised?](https://phpsos.de/en/php2shell/bin-ich-gehackt-anzeichen/).

## What the recommendation means for those responsible

A BSI warning is not a law. But it is the assessment of the competent specialist authority and may play a role in the later evaluation of decisions, for example by insurers or auditors. Senior management should therefore document when they learned of the warning, how they assessed their own systems and which measures they took. General notes on this are under [Liability of management](https://phpsos.de/en/compliance/geschaeftsfuehrer-haftung/); this is not legal advice.

In practice it is advisable to read the warning more than once. The BSI updates its notices when the situation changes, for example with new findings on exploitation or on further vulnerabilities. Since 23 October 2026 there has also been a notice from php.net on CVE-2026-115560, which only affects unusual configurations and is likewise mitigated with `session.upload_progress.enabled=0`. Name one person who checks the BSI and php.net daily until the situation is resolved and passes changes on to the technical team and management. That way no knowledge gap arises between those who decide and those who implement.

## How does PHP SOS help?

- We compare your web servers with the BSI recommendation: version, package state, restart, reachability.
- As part of the [PHP2Shell immediate help](https://phpsos.de/en/leistungen/php2shell-soforthilfe/), we patch, restart all processes and provide evidence.
- Where an update is not immediately possible, we set interim measures and, if needed, provide a static replacement page.
- We preserve logs and check for traces so that you can assess the situation reliably after the patch.


## Frequently asked questions

**What does warning level 3 (orange) mean at the BSI?**  
The color describes an elevated, serious threat situation requiring action. For PHP2Shell, the BSI justifies this with the criticality of the vulnerabilities and the expected rapid exploitation. You will find the exact definition of the levels on the BSI's website.

**Do I have to follow the BSI recommendation?**  
A BSI warning is a recommendation, not a law. But it is a weighty assessment by the competent specialist authority, which insurers, auditors and courts can use as a guide. Anyone who deviates should document the reasons. This is not legal advice.

**According to the BSI, were there already successful attacks?**  
According to the BSI, confirmed successful attacks on a broad scale were initially not known. The BSI did, however, expect rapid large-scale exploitation. Other bodies had already reported attack attempts.

**Where do I find the current version of the warning?**  
On the BSI's website under the current security warnings. The situation can change; check the latest state there and on php.net regularly.

## Sources

- [BSI (German Federal Office for Information Security)](https://www.bsi.bund.de/)
- [php.net: Security announcements](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [TechTarget: PHP2Shell](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
