Two vulnerabilities in the PHP core may allow unauthenticated remote code execution. Patches are available and initial attack attempts have been reported. Organisations now face a broader test: can they identify every exposed PHP system, including instances embedded in third-party products?

Germany’s Federal Office for Information Security (BSI) has issued a level 3 “Orange” cyber security warning, classifying the risk as exceptionally high. The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are collectively known as PHP2Shell. Under certain conditions, they could allow an attacker to execute code remotely on a vulnerable web server without authentication.

The flaws affect the PHP engine itself. Risk therefore does not depend solely on whether a shop or portal contains vulnerable application code. An application whose own code has no known flaw may still be exposed if it runs on an affected PHP runtime. This may include deployments of Magento, Shopware or WooCommerce.

The two CVEs stem from different failure conditions. CVE-2026-109618 involves an error in handling memory exhaustion. CVE-2026-109619 involves stale global state that can be reused after the associated memory has been freed—a use-after-free flaw. In both cases, incorrect handling of internal state can lead to attacker-controlled code execution.

The CVSS 4.0 score of 9.2 signals very high severity, but it does not indicate that every attack will succeed under all operating conditions. The rating also reflects increased attack complexity and specific preconditions. That does not reduce the urgency for operators: internet-facing systems running vulnerable PHP versions require immediate attention.

Runtime inventory is the first task

According to the BSI, known PHP versions are affected going back at least to PHP 5. Any installation that processes web requests may be vulnerable. This includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP Security Team identifies mod_php as the configuration with the highest risk.

Fixed releases are available in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Backport patches have also been provided for the end-of-life branches 7.4, 8.0 and 8.1. There is no patch for PHP 5. Operators of older systems must check whether their distribution or supplier provides a supported fix. Merely changing a version number is not enough: teams need to verify that the runtime actually in use includes the correction.

The larger operational challenge often comes before patching. PHP may be installed directly on a server or bundled within an application, appliance or third-party product. An asset register that records only standalone PHP packages may therefore be incomplete.

Samuel Hassine, CEO and co-founder of Filigran, identifies discovery as the central challenge. Organisations need to find every system running PHP, including instances concealed within third-party products. In some cases, taking a service offline temporarily may be less costly than continuing to operate it under acute risk. After patching, operators also need to investigate whether a system was compromised while it remained vulnerable.

Patching is not the end of the response

Cloudflare reported initial attack attempts before the updates were released. With technical details and working exploit code now public, the risk of automated scanning and targeted exploitation has increased. An observed attempt does not, by itself, confirm a compromise; it does make the review of exposed systems more urgent.

Debrah Galea, Senior Product Marketing Manager at Filigran, compares PHP2Shell with Log4Shell. Both involve widely deployed software and can enable unauthenticated remote code execution under certain conditions. The comparison has limits. PHP is often easier to identify as a technology component than a Java dependency embedded deep within an application. Updates were also available for several current PHP branches. However, public exploit code is likely to lower the technical barrier for attackers.

The city of Mainz took several municipal online services, including its central portal, offline as a precaution after the warning. Such a measure reduces exposure, but it does not replace remediation or subsequent investigation. Where an update cannot be applied promptly, temporarily isolating a system may be an appropriate protective measure.

The response must continue beyond the patch

Mathieu Rigotto, CISO at Filigran, criticises the public release of technical details before the official patch. Coordinated disclosure is intended to give defenders time to prepare before attackers gain access to usable information. Now, he argues, three questions matter most: which PHP endpoints are actually reachable from the internet; who owns each system; and what would a compromise mean for the organisation—for example, in terms of customer data, credentials or a foothold into the internal network?

For security teams, the response should follow a clear sequence:

• Map the attack surface: Identify internet-facing services and PHP installations across the infrastructure, including third-party products and appliances.
• Prioritise exposure: Address systems directly accessible from the internet and installations using mod_php first.
• Verify remediation: Apply updates and confirm that the runtime is actually on a fixed version.
• Isolate systems that cannot be patched: No patch is available for PHP 5. Such systems need a temporary measure, such as shutdown or an effective restriction of access.
• Investigate possible compromise: Review systems and logs from the period when they were vulnerable for signs of suspicious activity.

PHP2Shell is testing more than patch-management speed. It is exposing whether organisations already know which systems are reachable, who is responsible for them and how important they are to business operations. That knowledge is what turns an advisory into prioritised action—and makes it possible to determine whether the risk has been contained after patching.