What CERT-EU and CERT-Bund Advise on PHP2Shell

In short: According to reports, CERT-EU advises recording PHP installations, patching immediately and isolating publicly reachable applications if they cannot be patched promptly. CERT-Bund (the German government CERT) and the BSI (German Federal Office for Information Security) recommend in their warning updating immediately and, if that is not possible, taking affected web servers offline temporarily. The recommendations agree at their core: update first, isolation as a fallback, interim measures only as a supplement.

Who is warning, and for whom?

With PHP2Shell, several official bodies reacted within a few hours. For companies in Germany, the BSI with its computer emergency response team CERT-Bund is the first port of call. CERT-EU is the cybersecurity service of the EU institutions; its advice is addressed first to them but is read across Europe. According to BleepingComputer, the British National Cyber Security Centre has also issued a warning. From the private sector, Huntress and Cloudflare, among others, spoke up.

For you as an operator, the origin matters less than the agreement. When several independent bodies advise the same thing, that is a strong signal.

CERT-Bund, CERT-EU and others: the PHP warnings compared

None of the bodies recommends relying on a web application firewall or on settings in php.ini alone. All of them name the update as the actual solution. What the BSI advises beyond that in detail is on the page What the BSI recommends on PHP2Shell.

The version question: what "from PHP 5 onward" means

According to reports, CERT-EU considered it possible that versions from PHP 5 onward are affected. According to specialist reports, the body relied on information that circulated before the official announcement. The trade press speaks of almost all versions going back to PHP 5.4.

In practice, the exact boundary changes little. For PHP 8.1 and older, the PHP project no longer ships official updates. There are minimal source backports for 7.4, 8.0 and 8.1, but no releases. Anyone still running PHP 5 or 7 depends on distributions, third-party providers or a migration. Whether your distribution has shipped a fix is shown by its own security pages, such as the Debian Security Tracker, the Ubuntu Security Notices or Red Hat's advisories. Commercial long-term offerings for old PHP versions also exist; whether they cover PHP2Shell, you should have the provider confirm in writing. Details on the branches are under Which PHP versions are affected? and PHP 8.1 and older.

Isolating: how to implement the recommendation

"Isolating" sounds abstract. What is meant is that requests from the internet no longer reach the vulnerable PHP application. Depending on the application, there are several levels:

1. Shut down completely: The website is replaced by a static emergency page without PHP. This is the safest variant.
2. Restrict access: The application stays in operation but is only reachable via VPN or for defined IP addresses, for example for internal portals.
3. Upstream login: A login at web server or proxy level in front of the application. Caution: with mod_php, an exploit was shown before application code runs. The login must therefore take effect before PHP, not in the application.
4. Block direct access to the origin: Anyone using a proxy or CDN service should make sure that the server is not additionally reachable directly.

A restriction in the web server can look like this, as a harmless configuration for Apache:

# Allow access only from the internal network (adjust the example range)
<Location "/">
    Require ip 192.0.2.0/24
</Location>

Test the effect from outside, for example over a mobile connection. An isolation that has only been tested from the office network is not a tested isolation.

What the recommendations have in common: an inventory

All official bodies assume that you know where PHP is running. That is exactly where many companies fail: microsites from old campaigns, a forgotten customer portal, a test system with a public address, an application on a NAS. CERT-EU expressly names recording the PHP installations as the first step.

Forgotten systems are most likely to be found in three ways: the DNS zones of your domains, the list of issued TLS certificates and the contracts with agencies, hosting providers and software vendors. Every entry about which nobody can immediately say what runs behind it belongs on the checklist. Such systems are particularly dangerous in a situation like PHP2Shell, because nobody patches them and nobody misses them if they are compromised.

A usable inventory contains, for each system: address, purpose, operator, PHP version and operating mode, source of the packages and the contact person for updates. How to build it and keep it current is shown in the article Inventory of all websites and servers.

How does PHP SOS help?

• Recording: We identify your publicly reachable PHP systems and rank them by risk.
• Patch or isolation: We install updates or isolate applications that cannot be patched immediately, and we check the effect from outside.
• Old versions: For systems with PHP 8.1 and older, we plan the path to a supported level with you.
• Proof: You receive documentation of the recommendations implemented for each system.

How we bring old applications up to supported versions is described in the service PHP migration for legacy systems.

Conclusion

CERT-EU, CERT-Bund, the BSI and the PHP project speak with one voice: update, and where that is not immediately possible, isolate. The differences lie in details such as the version boundary. For your practice, the first step that all of them assume is what counts: knowing where PHP is running everywhere.

Frequently asked questions

Sources

• BSI: German Federal Office for Information Security
• php.net: security announcements
• BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws