23 October 2026

 

On Wednesday afternoon, 21 October, MoveTheNeedle.news displayed a “503 Service Unavailable” message. Our IT specialist had taken the website and its Beasy content management system offline as a precaution against the PHP vulnerabilities. He restored both after applying the security update.

Across countries and industries, operators faced an urgent choice: could they protect their systems quickly enough to keep them available, or should they temporarily withdraw services? Government agencies, businesses and public institutions took websites offline while preparing emergency updates for two critical flaws in PHP, software used to run websites and web applications. 

The Netherlands’ response was particularly visible. Services including Overheid.nl, MijnOverheid.nl and DigiD were taken offline, while the National Cyber Security Centre, or NCSC, temporarily withdrew its own website. These were precautionary decisions; the interruptions did not themselves establish that the services had been hacked. 

Other countries including the UK, Finland and France also suspended services. Yet, as Dutch newspaper de Volkskrant reported on 22 October, intervention appeared less drastic in many other countries. Was the Netherlands acting decisively, or accepting unnecessary disruption?

Understanding that difference starts with the software working behind the webpage.

 

What is PHP, and why do websites depend on it?

 

PHP is a programming language used to make websites work. When someone submits a form or requests information from a database, PHP can process the request on the website’s server before sending the result to their browser. Its name stands for PHP: Hypertext Preprocessor.

Content management systems including WordPress, Drupal and Joomla depend on PHP. Organisations may therefore use it through software they install or purchase, without employing anyone who writes PHP code. 

A website can have sound application code and still be vulnerable because the software running it contains a flaw. That shared dependency explains why one security announcement could trigger action across otherwise unrelated services.

The search for affected systems also extends beyond public websites. The UK’s National Cyber Security Centre has warned organisations to check appliances and services that bundle PHP within their products.

 

How serious are the PHP2Shell vulnerabilities?

 

The vulnerabilities, collectively known as PHP2Shell, are tracked as CVE-2026-109618 and CVE-2026-109619. Both received a critical severity score of 9.2 out of 10 under version 4.0 of the Common Vulnerability Scoring System.

Both concern failures in handling memory and errors. In the first, exhausting PHP’s permitted memory can interrupt an operation before internal data has been properly initialised. The subsequent clean-up can then mishandle that incomplete information. In the second, PHP can retain references to memory that has already been freed, allowing a later request to use invalid information.

Under exploitable conditions, an attacker without a login can make the affected system execute code. The consequences depend on what information and functions the compromised process can access.

Google Cloud’s chief information security officer, Chris Betz, and Google DeepMind’s head of Gemini Security, Raluca Ada Popa, warned in a joint advisory that attackers could “steal, alter, and wipe its data”. They also noted that mitigating circumstances can make exploitation harder. A critical rating does not mean every installation is equally easy to attack.

PHP released fixed versions on 21 October: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For older branches, the route to protection may involve supplier-provided security updates or upgrading to a supported version. Although PHP 8.1 and earlier no longer receive regular project support, minimal source-code patches were also made available for PHP 7.4, 8.0 and 8.1.

 

Who maintains PHP and makes security decisions?

 

PHP is an open-source project maintained by a community of contributors. The PHP Foundation funds developers and supports maintenance, but language decisions remain with the PHP Internals community through its Request for Comments process. The foundation separately governs its funding, staff and activities. 

Its account of this incident acknowledges an organisational failure alongside the technical defects. Early signs of the out-of-memory problem emerged in 2024, but a practical attack had not been established. Proposed repairs carried difficult trade-offs. Limited specialist capacity and difficulty reaching consensus repeatedly stalled progress.

The foundation calls the delay “a structural failure”. Its security team has begun changing processes so that “decisions can be made by majority and compromises are encouraged”. It also intends difficult cases to reach foundation leadership sooner.

These reforms remain under way and concern security handling, rather than replacing PHP’s wider community governance. 

 

AI research and a disrupted disclosure

 

AI-assisted research helped establish the vulnerabilities’ danger. OpenAI says security company Calif discovered a critical PHP weakness using its models, while Wiz independently discovered and reported both vulnerabilities. PHP’s maintainers led the development of fixes, supported by research and coordination partners.

The coordinated disclosure then unravelled. According to the PHP Foundation, vulnerability identifiers circulated publicly on 20 October, prompting an earlier announcement and bringing the planned release forward by a day. A mistakenly published demonstration video subsequently revealed additional information. 

There is evidence of attempted exploitation even before those events. Amazon’s threat intelligence team identified an attempt against its MadPot decoy infrastructure dating to 17 October. It said it remained unclear how the actor obtained the information, or whether the observed attempts would have succeeded against real-world systems. 

Activity against a monitored decoy provides evidence of attempted exploitation, without establishing that a particular government or business suffered a breach.

Amazon security executive CJ Moses identified the broader pressure: “The time from patch to working exploit is shrinking for structural reasons.” AI-assisted analysis, he explained, makes it cheaper for more attackers to turn technical information into working exploits.

 

Why the Netherlands took websites offline

 

CERT-EU advised organisations to patch affected systems immediately and consider isolating internet-facing applications where that was not feasible. The Dutch government initially asked website owners to assess their risks and consider precautionary shutdowns until updates became available.

In an interview with de Volkskrant, published on 22 October, cybersecurity expert Bert Hubert argued that the Netherlands had translated warnings into action particularly quickly.

“Among computer security nerds, it was clear on Tuesday that we really needed to get to work,” he told the newspaper, in comments translated from Dutch. He said Dutch government officials began gathering information during the night from Tuesday to Wednesday.

Hubert identified the connection between cybersecurity specialists, journalists and decision-makers as an important part of that response.

“Policymakers only start taking it seriously when they see it being picked up in the news,” he told de Volkskrant.

He suggested that recent reporting about the cyberattack affecting Albert Heijn had heightened awareness, alongside an effective Dutch pipeline between the security community and the media. These are Hubert’s explanations for the response, rather than independently established causes of national differences, but his assessment makes sense: a technical warning must reach people who understand its implications and have the authority to act.

 

Expert advice on updates and website shutdowns

 

The UK’s NCSC sets out a sequence for responding to the PHP vulnerabilities: identify affected systems, prioritise those exposed to the internet and install security updates. Where immediate updating is impossible, organisations should consult the developer’s temporary mitigations. If those cannot be applied quickly enough, it advises considering taking the affected system offline until it can be protected. 

For this incident, the Dutch NCSC gives more explicit advice: keep vulnerable systems offline until updates have been installed. It cautions that temporary measures restrict particular attack routes without providing complete protection, and has published a decision tree to help organisations assess their response. 

 

Checking for compromise after the PHP update

 

In its update at 16:00 on 22 October, the Dutch NCSC said it was investigating initial indications of successful exploitation. 

For organisations that could not promptly update or disable affected systems, the UK NCSC recommends assessing for evidence of compromise, including backdoors an attacker may have installed. Where organisations cannot confidently investigate themselves, it recommends assistance from a specialist incident-response provider. A security update addresses the vulnerability; an earlier intrusion may require additional recovery work.

Both agencies also direct attention beyond the main website. The Dutch NCSC urges organisations to establish where PHP is used and follow their suppliers’ update instructions. The UK NCSC recommends monitoring for fixes to third-party products containing PHP. Website owners can use that guidance when asking providers which systems have been updated and which still require attention.

 

 

 

Liked this article? You can support our independent journalism via our page on Buy Me a Coffee. It helps keep MoveTheNeedle.news focused on depth, not clicks.

👉 https://buymeacoffee.com/movetheneedle.news