On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which allow unauthenticated remote code execution. Both are now being exploited, and a third flaw followed on 23 October. For a CISO the patch is the easy bit. The real work comes down to three questions: where does PHP run (including at your suppliers), who applies the updates, and who can prove afterwards that it was done?
What exactly is PHP2Shell?
The advisory from CERT-EU, the cybersecurity service for the EU institutions, describes two vulnerabilities, each rated 9.2 on CVSS:
- CVE-2026-109618 is memory corruption during out-of-memory handling. If a request is interrupted while a form-based file upload is being parsed, cleanup can free uninitialised memory.
- CVE-2026-109619 involves stale global state. Data that survives a fatal error can be picked up by a later request on the same worker.
Both lead to remote code execution without authentication. The PHP project has demonstrated an exploit in which a single unauthenticated request triggers the attack before any application code runs, so WAF rules and application logic offer little protection.
In its warning on the Dutch government site on 21 October, the Dutch National Cyber Security Centre (NCSC) said that at least every PHP version from 5 onwards is vulnerable, that public proof-of-concept code exists and that a simple POST request is enough. It even took ncsc.nl offline as a precaution. At that point it had not seen active exploitation. That has changed: according to the Canadian Centre for Cyber Security, the US agency CISA added both CVEs to its Known Exploited Vulnerabilities catalogue on 26 October.
On 23 October the PHP project then disclosed CVE-2026-115560, a third flaw that can also lead to remote code execution and that the 21 October releases do not fix. Until the next regular release, the recommended measure is to set session.upload_progress.enabled=0 in php.ini or the FPM pool and restart every worker.
Why this is more than a routine patch cycle
PHP rarely lives only on the web servers your own team runs. It sits inside content management systems, customer portals, intranets, monitoring tools, appliances and third-party SaaS. Some Linux distributions and LTS vendors ship their own backported fixes, so a version number doesn't tell the whole story: a distribution package can keep an older upstream number and still be patched.
PHP 8.1 and older no longer get updates from the PHP project. For 7.4, 8.0 and 8.1 there are only minimal source patches, aimed at organisations that build from source or have no LTS vendor. The available mitigations, such as a fixed memory_limit, a low post_max_size or switching off upload progress, reduce exposure but do not make an installation safe. Only the update does. If a status report says "we have a workaround", push back.
Then there is regulation. Since 15 August 2026 the Cyberbeveiligingswet, the Dutch law implementing NIS2, has been in force. Organisations in scope must take appropriate and proportionate measures to secure their network and information systems, and report incidents quickly to their CSIRT and supervisor. The board approves those measures and oversees how they are carried out. A critical, widely publicised and actively exploited flaw with a patch available is exactly the sort of event where a supervisor will later want to see how you responded.
The capacity question: who does the work?
My view is that with a flaw like this, people are a bigger bottleneck than technology. The vulnerability management team already has a full queue, the Linux and middleware engineers have a backlog, and someone has to chase dozens of suppliers at once. Meanwhile each system that cannot be patched needs a decision on whether it comes offline.
These are the profiles you will need over the coming weeks:
- Vulnerability management specialist: maps every PHP instance, including container images and appliances, and tracks progress until the last host is updated.
- Security-minded Linux and middleware engineer: applies the updates, restarts every worker (a forgotten FPM pool is an open door) and checks that applications do not override the configuration.
- Third-party risk manager: sends targeted questions to suppliers and SaaS providers, records answers and patch dates, and escalates where vendors go quiet.
- DFIR or threat hunting specialist: looks for signs of exploitation on systems that were exposed for longer, so you have facts if you need to report.
- GRC specialist: documents decisions, risk assessments and timelines so they hold up in an audit or a supervisor's inquiry.
You will not hire these people permanently within a week. This is where interim capacity earns its keep: experienced specialists who are productive within days, work to a defined goal and leave once it is done. For the broader picture of the talent the Dutch law calls for, read our piece on NIS2 compliance.
What to do now
- List every internet-facing system running PHP, including appliances, container images and third-party applications.
- Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install the update from your distribution or LTS vendor, then restart every worker.
- Set session.upload_progress.enabled=0 against CVE-2026-115560 until the next PHP release, and pencil that release in now.
- For each system that cannot be patched straight away, decide whether to take it offline or isolate it from the public internet. Record the decision with a name and a date.
- Have your DFIR people review logs for unexpected processes, files, accounts and outbound connections. The flaws are being exploited, so do not assume a clean environment.
- Ask suppliers in writing which PHP version they run, when they will patch and how they will show it. Silence is an answer too, and it belongs in your risk register.
- Put the migration of systems on PHP 8.1 or older on the roadmap.
- Give the board a short update on status, residual risk and decisions taken.
If you are short of hands, we find interim specialists in vulnerability management and DFIR. If someone needs to take charge of the response, consider an interim CISO. Our NIS2 page covers what the Dutch law asks of you. Want to talk through who you need? Call or email me.
