← All articles

PHP2Shell and the CRA: what to do if your product runs PHP

· 8 min read

On 21 October the PHP project released fixes for two critical vulnerabilities that let an attacker run code on the target without authenticating. Five days later, the US Cybersecurity and Infrastructure Security Agency (CISA) added them to its catalogue of exploited vulnerabilities. Most of the coverage is about web servers, but PHP also ships inside many products: management interfaces, gateways, network equipment. If you make any of these, this is probably the first serious case in which you need to think about the reporting obligations of the Cyber Resilience Act (CRA).

What happened

The two vulnerabilities, known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619), have a CVSS v4.0 score of 9.2. Both are memory flaws in the way PHP handles each request internally.

They affect every PHP installation that serves web requests, whether through PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. According to the PHP team, mod_php carries the highest risk: there is a demonstrated exploit in which a single unauthenticated request triggers the attack before any application code runs.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive updates: for 7.4, 8.0 and 8.1 there are only minimal source fixes, which you have to apply and build yourself.

Attackers did not wait. According to security press reports, attempts began before any fix was available and reached the millions, and over the weekend of 24 and 25 October the first real code execution was confirmed on honeypot servers. On 26 October CISA added both vulnerabilities to its catalogue of exploited vulnerabilities.

Why it matters if you make electronics

The CERT-EU advisory explicitly includes third-party products that embed PHP and points to the list maintained by the Dutch National Cyber Security Centre (NCSC-NL). As of 28 October that list tracked 757 products, 218 of them confirmed vulnerable and 354 still under investigation. They include appliances, network devices, management interfaces and even industrial wireless software.

Two well-known examples make the point. pfSense, Netgate's firewall and router software, has a web management interface built on PHP, and its captive portal depends on it too. Netgate released fixed packages on 21 October. And Palo Alto Networks has confirmed active exploitation against the web management interface of its firewalls. This is no coincidence: the management interface is precisely the part of the device designed to be reachable over the network.

Why a device takes longer than a server

On a server, fixing PHP means installing a package. In an embedded product, the PHP version is fixed in the firmware image, and the bottleneck is hardly ever compiling PHP: it is the whole delivery and recovery chain.

  • Building the right image for every board, product variant and configuration.
  • Signing it with the production keys, and making sure the device checks signature, integrity and version before installing it.
  • Making sure a power cut or an interrupted download does not leave the device unusable, with A/B partitions, recovery and rollback to the previous version.
  • Testing compatibility with the existing configuration, peripherals, communications, boot and updates from old versions, including the extensions and libraries that change along with PHP.
  • Distributing it over intermittent connectivity, to devices behind private networks and within maintenance windows, gradually and knowing which devices have been updated.
  • Coordinating it with the customer: approval, installation instructions and a plan for the devices that never reconnect.

Picture a Linux-based smart meter gateway. The web interface patch is ready, but it cannot be rolled out until you have checked that it works on both hardware revisions, that the image is signed with the production key and that devices with poor coverage recover if the download is cut. Even in a mature product like pfSense, the fix cannot be applied from the web interface itself: it has to be done from the console or SSH, with WireGuard reinstalled and services restarted.

Products already on the market:Design review and rescue

What the CRA has required since 11 September

Since 11 September 2026, the CRA's reporting obligations also apply to products that were already on sale. When a manufacturer becomes aware that a vulnerability in its product is being actively exploited, it must send, through ENISA's single reporting platform:

  1. An early warning within 24 hours.
  2. The notification within 72 hours, with the information available on the product, the vulnerability and the corrective measures.
  3. A final report no later than 14 days after a fix or mitigating measure is available.

It must also inform affected users about the vulnerability and the measures they should take.

One important nuance: PHP2Shell being in CISA's catalogue does not, on its own, trigger a report. According to the guidance the European Commission published in July, the clock starts when the manufacturer has a reasonable degree of certainty that it is being exploited in its product. But if your device is vulnerable and its interface is reachable, that certainty can arrive at any moment, and 24 hours is not enough to start from scratch. We cover this in more detail in our CRA guide for manufacturers.

What to do now

  1. Find out which products run PHP and which version. With a software bill of materials (SBOM) this is a query. Without one, you have to go through each firmware image.
  2. Check how it runs and who can reach it. The worst case is an interface on mod_php reachable from the internet; limiting it to the local network reduces exposure, but does not remove it.
  3. Prepare the firmware update with a fixed version, or with the source backport if you are on an old branch. If you use PHP 8.2, bear in mind that it reaches end of life on 31 December 2026.
  4. In the meantime, apply PHP's mitigations and advise your customers not to expose the interface to the internet. The PHP team itself warns that they are not enough: only updating fixes the problem.
  5. Decide and document whether you need to report, who does it and how you will inform users. If there are signs of exploitation on your devices, the 24-hour clock has already started.
  6. If you integrate third-party software (a gateway operating system, a management panel), look it up in the NCSC-NL list and ask your supplier for their fix schedule.

Firmware updates and SBOM:Embedded firmware

The design lesson

PHP2Shell is not really about PHP. Any third-party component in a connected product can have a critical vulnerability tomorrow, and the CRA turns the response into an obligation with deadlines. Whether that means an afternoon's work or a month of crisis is decided at design time: knowing what each product contains, being able to update it securely in the field, and exposing only what is essential to the network.

For a new device we would not rule out PHP on principle. It makes sense if the platform has enough resources, the runtime is supported and someone is responsible for updating it for the whole product life cycle. On many devices we prefer a small interface with a local API, on the web server and language the platform already supports. Whatever you choose:

  • Interface disabled or limited to the local network by default, and never exposed to the internet without a clear need.
  • Authentication and permissions: being reachable only on the local network does not make it secure.
  • Services, dependencies and extensions cut down to what is needed, with pinned versions.

If nobody is watching the dependencies of your products, that is exactly what our vulnerability monitoring service covers. And if you want to know how long it would take you to ship an update like this one, tell us about your product and we will look at it with you.

Sources

Email Get in touch