PHP2Shell: not just
a website problem

On 21 October 2026 the PHP project published four fixed releases for two critical vulnerabilities in the interpreter, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both score 9.2 out of 10 on the CVSS (Common Vulnerability Scoring System) version 4.0 scale and let a remote attacker, with no credentials, execute code on the server or read the process memory. The coverage of these days talks almost only about websites, WordPress first. The missing point is another one: the flaw is in the runtime, and PHP also runs inside firewall GUIs, in captive portals, in NAS (Network Attached Storage) devices, in PBX systems and in ticketing tools. Whoever has inventoried the websites has done half the job.

What happened between 17 and 21 October

The two flaws stem from the same weak point: the way PHP handles fatal errors, out-of-memory conditions in particular, while processing a request. CVE-2026-109618 interrupts PHP while the request’s internal structures are only partly initialised, and the subsequent cleanup treats invalid data as valid. CVE-2026-109619 leaves references to freed memory in the worker’s global state, which a later request served by the same worker reuses before initialisation resets them. The vulnerable code, according to Wiz Research which discovered the flaws on 19 August and reported them on the 24th, has been there since PHP 5.4, that is since 2012.

Coordinated disclosure did not hold. On 17 October Amazon’s honeypots record a first exploitation attempt, from a commercial anonymisation network. On 20 October the technical details leak in public and the PHP project announces an out-of-band release for the next day. On 21 October at 14:00 UTC PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 come out; Cloudflare had already enabled the protections of its WAF (Web Application Firewall) at 03:02 UTC and states it observed attack traffic against its customers. The same afternoon the Italian ACN (National Cybersecurity Agency) publishes alert AL07/261021/CSIRT-ITA with systemic impact “High (65.64)”, CERT-EU advisory 2026-018, and the SANS Internet Storm Center raises its alert level to yellow. As of 22 October no compromises are confirmed on real systems, but the attempts are documented and proof-of-concept code is public.

For PHP 8.1 and earlier the project publishes no fixes: the ACN says so explicitly. The PHP security team has however made minimal source backports available for 7.4, 8.0 and 8.1, and Linux distributions and LTS vendors, notified in advance, are releasing their own packages. One detail for the calendar: PHP 8.2 leaves support on 31 December 2026.

Why updating WordPress is not enough

The malicious request is processed by PHP before the application code runs. That is why updating WordPress, the theme or the plugins changes nothing: the interpreter running the site must be updated, and on shared hosting you have to ask the hosting provider. Wiz demonstrated unauthenticated code execution on the latest official images of WordPress, Drupal and Joomla, but points out that even a “Hello World” page on a vulnerable PHP can be attacked. The highest risk, according to php.net, is on Apache with mod_php, where the attack succeeds with default settings; PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are affected all the same.

There is a second, less quoted effect: CVE-2026-109618 also allows reading the PHP process memory without reaching code execution. Passwords, session tokens, API keys and, according to Sansec, even TLS private keys pass through that memory. Whoever finds out they were exposed does not close the incident with the patch: they have to rotate the secrets.

It is the same conclusion we had reached in the article on WordPress vulnerabilities: the problem is not the single plugin, it is having an interpreter listening on the Internet to serve pages that do not change. A static site, generated at build time and delivered by a CDN, has no PHP, no workers, nothing to update this week. Our site is built that way, and so is the managed hosting we offer on Azure Static Web Apps.

PHP does not run only in websites: firewalls, NAS, PBX, ITSM

Many network appliances and many business applications have a web interface written in PHP. The vendor updates it with the firmware, so the PHP version is not chosen by the company and often nobody knows which one it is. In the two days after the patch the vendors’ advisories came in waves, and they describe four different situations.

Open-source firewalls. pfSense and OPNsense have their GUI and captive portal in PHP. Both published fixed packages on 21 October: OPNsense with a hotfix for the Community and the Business edition, pfSense with new PHP packages for the supported versions, to be installed from the shell and not from the GUI. The captive portal is the worst case: it is a PHP service designed to answer untrusted clients, in hotels, shops, waiting rooms and guest networks, and it must be restarted after the update. The GUI, by contrast, answers only on the LAN by default: if that is the case, it remains a matter of hygiene, not an emergency.

Commercial firewalls and appliances. Some large vendors have declared the web management interface of their appliances vulnerable and, as of 22 October, have no date for the fix yet; others have a long list of products “under investigation” and none confirmed. In both cases the recommendation is the same: management reachable only from trusted internal addresses and, while waiting for the fix, no management port on the Internet.

NAS. The operating systems of some NAS devices use PHP in their web components and applications; as of 22 October one very widespread vendor marks all versions as “being fixed” and asks to take the NAS off the Internet, use the VPN and stop unneeded services. Other NAS platforms do not use PHP in the system, but the installed apps do, such as a file cloud or a CMS: there you update the app, not the firmware.

PBX, ITSM and the rest. Open-source PBX systems have their administration GUI in PHP: recent versions on a supported distribution get the fixed PHP from the distribution’s repositories, old ones run on unsupported PHP branches and stay exposed. The same goes for ticketing systems, wikis, monitoring frontends, webmail and hosting panels: it is not the application that needs updating, it is the PHP underneath, with the distribution’s or vendor’s package; in cloud versions managed by the vendor, the vendor takes care of it.

For every appliance not covered by an advisory there is one question to ask the vendor: does the GUI run PHP, which version, and from where is it reachable?

What to do in your company, in this order

• Inventory of where PHP runs. Sites and portals, including the “forgotten” ones; firewall and router GUIs; captive portals; NAS and video surveillance; PBX; ITSM, wiki, monitoring, webmail; containers and apps installed on the NAS. For each one: the PHP version serving the requests (not the command-line one, which can differ) and from which networks it can be reached.
• Close what is exposed. No management interface and no captive portal directly on the Internet. Remote access goes through a VPN or a Zero Trust access, and the GUI answers only trusted networks and addresses. If a vulnerable service can be neither updated nor protected, the ACN recommends considering taking it offline until the update.
• Update and restart the workers. PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the distribution or vendor package that backports the fixes. The new binary takes effect only after restarting PHP-FPM or the web server, and the captive portal where there is one. Then verify the version from the web side, not only from the shell.
• Temporary mitigations, only if there is no patch. The settings indicated by php.net reduce exposure to specific paths and do not make an installation safe: memory_limit with no limit enforced by the administrator, a low post_max_size, session.upload_progress.enabled disabled with a worker restart, fatal_error_backtraces disabled on PHP 8.5. Do not use RLIMIT_AS or RLIMIT_DATA, which trigger the very vulnerable path.
• Rotate the secrets, if there was exposure. Where a vulnerable service stayed reachable between 17 and 21 October, treat application passwords, session tokens, API keys and certificates held in memory as potentially read, and rotate them.
• Plan the exit from old branches. PHP 7.4, 8.0 and 8.1 will get no official releases; PHP 8.2 leaves support on 31 December 2026. An application stuck on an old branch is a problem to solve in the next two months, not at the next emergency.

What to look for in the logs, even if you have already updated

The ACN alert asks for a retrospective analysis of the logs “regardless of the application of the updates”, and the reason is the timeline: four days of attempts before the patch, which nobody was watching. The window to cover starts at least on 17 October. The signals converge across ACN, Wiz, Amazon and the PHP advisories:

• Anomalous multipart POST requests: very long filenames, many headers per part, sizes close to the limit, PHP_SESSION_UPLOAD_PROGRESS field present.
• Recurring out-of-memory errors, repeated HTTP 500 responses, “Maximum execution time exceeded”, unexpected restarts or churn of the PHP workers.
• Anomalous PHPSESSID response cookies, too large or malformed: that is the trace of the memory disclosure.
• On the system: unexpected processes started by the web worker, modified application files, new cron jobs or accounts, unexplained outbound connections.

One warning that comes from the PHP advisories and is worth more than the whole list: the absence of errors in the logs is not proof of safety. Historical logs may have been collected without deprecations, and the failure can happen before PHP writes the message. Whoever has to sign a report should know it before signing. If something does not add up, it is time for incident response, not for another grep.

The structural point: fewer exposed runtimes, fewer emergencies

PHP2Shell is not the first case and will not be the last: Heartbleed in 2014 and Log4Shell in 2021 had the same shape, a component shared by everyone with a flaw nobody saw. What a company can decide is not whether the next one will come, but how much surface it offers. Three choices that reduce the surface permanently: a static site instead of a CMS with an interpreter, which takes PHP out of the perimeter; a cloud-managed firewall with the GUI never exposed, where administration goes through a controller and not through a port open on the WAN; a Zero Trust access instead of published management ports. Downstream, a periodic vulnerability assessment from the outside tells which interfaces really answer on the Internet, which is often different from what was believed.