PHP2Shell: what CISOs must do now after the PHP flaws

On 21 October 2026 the PHP security team 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. The Dutch National Cyber Security Centre (NCSC) advises treating every internet-facing PHP system as vulnerable until it is patched, and went as far as taking ncsc.nl offline temporarily. For CISOs, the patch itself is the easy part. The real work sits in three questions: where does PHP run (including at your suppliers), who applies the updates this week, and who can prove afterwards that it was done?

What exactly is PHP2Shell?

According to the official security announcement from the PHP project, there are two vulnerabilities, both rated 9.2 under CVSS v4.0:

• CVE-2026-109618: remote code execution via out-of-memory corruption. Out-of-memory handling can interrupt PHP while internal request data is only partially initialised, after which request cleanup treats that invalid data as valid.
• CVE-2026-109619: remote code execution via stale global state. Request-owned internal state can survive after its backing memory has been freed, and a later request handled by the same worker can then use that stale state.

The PHP project names every PHP installation that serves web requests as at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php, where a demonstrated exploit exists in which an unauthenticated request triggers the attack before a single line of application code runs. In that scenario, your WAF rules and application logic offer little protection.

In its warning published on Rijksoverheid.nl on 21 October, the NCSC stated that at least all PHP versions from version 5 onwards are considered vulnerable, that public proof-of-concept code exists, and that a simple POST request is enough to exploit the flaws. At that point the NCSC had not yet observed active exploitation. That is no reason to relax: it is a window you need to use.

Why this is more than a routine patch cycle

PHP rarely lives only on the web servers your own team manages. It runs inside content management systems, customer portals, intranets, monitoring tools, appliances and third-party SaaS services. In its alert, the NCSC points out that many users depend on their software vendor for an updated PHP version, and that Linux distributions and LTS vendors ship their own updates. A version number therefore does not tell the whole story: a distribution package can keep an older upstream number and still be patched, or the other way round.

Two further complications apply. First, PHP 8.1 and older no longer receive regular updates from the PHP project; for 7.4, 8.0 and 8.1 only minimal source patches are available. Second, the PHP project explicitly describes the available mitigations as incomplete: settings such as session.upload_progress.enabled=0 or changes to memory_limit and post_max_size only block specific attack paths. Only the update fixes the problem. If a status report says "we have a workaround", ask more questions.

Then there is the regulatory layer. Since 15 August 2026 the Dutch Cybersecurity Act (Cyberbeveiligingswet), the Netherlands' implementation of NIS2, has been in force. Organisations in scope have a duty of care to manage risks to their network and information systems and a duty to report significant incidents. The board is ultimately responsible for managing cyber risk. A critical, widely publicised vulnerability with a patch available is exactly the kind of situation in which a supervisor will later want to see how you responded.

The capacity question: who does this work this week?

As a cybersecurity recruiter, we see the same pattern every time an event like this hits. Technology is not the bottleneck; people are. The vulnerability management team is already at full stretch, the Linux and middleware engineers have a backlog, and the supplier manager has to chase dozens of vendors at once. Meanwhile someone has to make the risk call on which systems go offline, as the NCSC advises where patching cannot happen straight away.

The profiles that will make the difference over the coming weeks:

• Vulnerability management specialist: maps every PHP instance, including those in container images and appliances, and tracks progress per system 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 configuration is not overridden by applications.
• Third-party risk manager: sends targeted questions to suppliers and SaaS providers, records answers and patch dates, and escalates where vendors stay silent.
• DFIR or threat hunting specialist: checks systems that were exposed for longer for signs of exploitation, so that if you ever need to report, you have facts rather than assumptions.
• GRC specialist: documents decisions, risk assessments and timelines so they stand up to an audit or a question from the supervisor.

These are not roles you hire permanently within a week. This is where interim capacity is at its strongest: experienced professionals who are productive within days, work to a defined goal and leave once it is done. See also our earlier analysis of the talent you need to demonstrate NIS2 compliance; PHP2Shell is a real-world test of exactly that.

What to do now

1. Build the inventory today. List every internet-facing system running PHP, including appliances, container images and third-party applications. The NCSC refers to its technical overview page listing PHP-related products for this.
2. Patch to the right version. 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.
3. Decide on what cannot be patched immediately. The NCSC advises keeping vulnerable systems offline until they are patched and making a risk assessment per system. Record that assessment, with a name and a date.
4. Question your suppliers in writing. Ask which PHP version they run, when they will patch and how they will demonstrate it. No answer is also an answer for your risk register.
5. Plan the end of end-of-life versions. Systems on PHP 8.1 or older no longer receive regular updates. The PHP project also notes that PHP 8.2 reaches end of life on 31 December 2026. Put the migration on the roadmap now.
6. Secure capacity. Identify which roles you cannot fill internally and bring in interim specialists in vulnerability management and DFIR in good time.
7. Brief the board. Under the Dutch Cybersecurity Act the board is ultimately responsible. A short update on status, residual risk and decisions avoids surprises later.

Our view: PHP2Shell is a stress test for your security organisation

These vulnerabilities reveal how your organisation performs under time pressure. Organisations with an up-to-date asset inventory, firm agreements with suppliers and a flexible layer of security professionals are done within days. Organisations without that foundation fall weeks behind and only discover the gaps in the middle of the crisis. Use this week's lessons learned to fix structurally what was missing, whether that is an interim CISO to set direction or a vulnerability management team brought up to strength. Our NIS2 page summarises what the Dutch Cybersecurity Act requires of your organisation.

Frequently asked questions

Which PHP versions are safe from PHP2Shell?

The PHP project fixed the vulnerabilities in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you use PHP through a Linux distribution or LTS vendor, check that vendor's advisory, because the version number of a patched package may differ. PHP 8.1 and older no longer receive regular updates from the PHP project.

Are the mitigations enough if I cannot patch straight away?

No. The PHP project states that the mitigations only restrict specific attack paths and do not make an installation safe. The NCSC calls them insufficient and advises keeping vulnerable systems offline until they are patched. Only the update is a complete fix.

Do I have to report PHP2Shell under the Dutch Cybersecurity Act?

A vulnerability on its own is not an incident. The reporting duty under the Dutch Cybersecurity Act applies to significant incidents. If you find indications that a system has actually been exploited, assess immediately whether this amounts to a significant incident and involve your legal counsel and your CSIRT. In every case, record which measures you took and when.

Need capacity to close out PHP2Shell this week? MVPeople Group provides experienced interim specialists in vulnerability management, DFIR and GRC. Get in touch for an initial conversation about your situation.