PHP2Shell (CVE-2026-109618/109619): What Changed and What to Check (Updated 30 Oct)

Shortly after noon on 21 October 2026, DigiD (the Dutch government login) and MijnOverheid (the personal portal for government messages) started disappearing from the internet. So did the website of the Tweede Kamer, the Dutch lower house, and even the site of the National Cyber Security Centre (NCSC) itself.

None of this was caused by an attack. It was a precaution taken before any attack. Two critical vulnerabilities had been found in PHP, the programming language behind a large share of the world's websites, and many organisations chose to switch their sites off for the few hours until a fix arrived.

This article compares the primary sources published on 21 and 22 October (the Dutch NCSC, the PHP project, the UK NCSC and national CERTs) with coverage from outlets that international residents read. It separates what is confirmed from what is still unclear. The first half covers what this meant for daily life in the Netherlands. The second half is a practical checklist for anyone who runs a website for their business or for clients. It does not describe how the flaws are exploited. On 30 October we added what has changed since, under "What we learned after 22 October".

Main sources behind this article

• The NCSC warning "Ernstige kwetsbaarheden in PHP" on the Dutch government site (published 21 October 2026, 13:59) and the NCSC Community timeline
• The PHP project's release announcements, its supported-versions table and the two GitHub security advisories
• The UK NCSC notice "Critical security issue affecting PHP" (21 October 2026)
• Alerts from Japan's IPA and JPCERT/CC (22 October), used here as a comparison point
• NOS live coverage, two NL Times articles from 21 October, DutchNews.nl and Dutch IT Leaders

What this article answers	Short answer
What happened on 21 October?	A timeline from the late-morning warning to DigiD's return that evening (section 1)
What is actually confirmed?	CVE numbers and fixed versions are firm. Exploitation status and scope vary by source (section 2)
What changed after 22 October?	CISA KEV listing, further releases, recovery status (see "What we learned after 22 October")
What should residents do?	Nothing on your devices. Watch out for scams (sections 5–6)
Is my website affected?	Check the exact PHP version and compare it with the fixed releases (sections 7–9)
What about old PHP versions?	8.1 and older need migrating. 8.2 ends this year (section 10)
How do we prepare for next time?	A four-step update routine: inventory, monitor, test, apply (section 14)

Update history

First published on 22 October. On 30 October we added the developments since then and a vendor status table, and revised the title and key takeaways.

Date	Change
22 October 2026	First published (breaking coverage)
30 October 2026	CVE numbers checked against the CVE Program records and the php-src GitHub advisories. Added "What we learned after 22 October" and "Vendor status by product". Updated the FAQ on exploitation and recovery

Both CVE-2026-109618 and CVE-2026-109619 appear in the CVE Program records (published 21 October 2026, CVSS v4.0 score 9.2) and in the PHP GitHub advisories (GHSA-w8hw-w9fx-j79w for 109618). The NVD page could not be read when we checked on 30 October, so it was not used for the cross-check.

What we learned after 22 October

This section lists what moved after the first version, checked against the NCSC, the PHP project and CISA, plus news coverage. Where we could not confirm something, we say so. Everything was checked on 30 October 2026.

Exploitation: CISA added both flaws to KEV

The table lists the exploitation developments by date and separates primary sources from reports.

Date	What happened	Source type
About 17 Oct	Amazon reported an exploitation attempt four days before the fix	Report (quoted by the Drupal Association blog)
23 Oct	PHP published a notice on CVE-2026-115560 (below)	Primary (PHP)
24 Oct	A Perplexity researcher reported working shells on honeypots	Report (BleepingComputer)
26 Oct	CISA added both CVEs to KEV; federal due date 29 Oct	Primary (CISA KEV)
27 Oct	Wiz said it had not seen end-to-end success in its own telemetry	Researcher (Wiz)

The takeaway: "not exploited" is no longer an accurate description. The 24 October case was on what the researcher called a favourable single-worker mod_php setup. We found no official statement that a real company or agency was breached, and the NCSC Community page showed no update reporting observed exploitation.

Recovery: we could not confirm when overheid.nl returned

DigiD and MijnOverheid returned on the evening of 21 October, as in the first version. Binnenlands Bestuur reported on 21 October that municipal sites and MijnOverheid were back within hours.

For overheid.nl, NOS's report was still saying the site was offline when it was updated at 06:53 on 22 October, and the Ministry of the Interior gave no return date. We found no official statement or report giving a later recovery date. For NotuBiz we only found the expectation of recovery on the morning of 22 October, not a confirmation.

Further fixes: no release newer than 8.5.12 and its siblings

As of 30 October, php.net showed nothing newer than 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 from 21 October. On 26 October the Windows builds were rebuilt with a Brotli library fix (CVE-2026-111497). The "-1" suffix marks a dependency rebuild; the PHP versions are unchanged.

There is also a notice PHP issued on 23 October: CVE-2026-115560, a remote code execution vector that needs session upload progress enabled and a specific session setting combination. PHP calls it unlikely, and advises setting session.upload_progress.enabled=0 until the next regular release. A fixed version for it has not been released.

Old PHP on Dutch public-sector sites

Binnenlands Bestuur reported on 23 October that BNR had checked just over 900 municipal websites and found more than fifty that may still run outdated PHP. Most were subpages on topics such as asylum or tourism rather than main homepages. BNR passed the addresses to the NCSC and VNG without publishing them, and a security researcher cautioned that scanners can flag sites that are not actually vulnerable.

On 26 October the same outlet reported research by MindYourPass on 494,416 web applications used at work. Of 60,362 confirmed to run PHP, 28,615 (47 percent) ran an outdated, unsupported or affected version. The firm did not test for the new flaws and said the sample is not representative. We looked for a NOS report on this and did not find one.

The product list: how many products are still unassessed

The NCSC-NL GitHub project keeps a status list of products that embed PHP. In its update of 30 October, 09:14 CET, it tracked 929 products: 217 vulnerable, 165 fixed, 345 under investigation and 201 not affected (the remaining one has no status entered). Under investigation is the largest group, which means many products are still unclear.

Vendor status by product (30 October)

The table covers well-known PHP products and includes only those where we could confirm the vendor's own statement. Where we could not, it says "not published", with the NCSC list's rating in the notes. The NCSC list is a third-party assessment, not a vendor notice.

Product	Vendor statement	Status
WordPress.com, WordPress VIP, Pressable and others	Automattic (21 Oct)	Protected; no action needed
WordPress (self-run)	Automattic (same)	Updating WordPress, themes or plugins does not fix it; update PHP
WP Engine	22 Oct	All customer sites on fixed PHP; no action needed
Drupal	Drupal Association (22 Oct)	The flaw is in PHP; update PHP. It does not say a Drupal core update fixes it
Nextcloud All-in-One	Release 14.4.1 (21 Oct)	Fixed; PHP dependencies updated
Nextcloud (self-run)	Not published (not found)	NCSC list: vulnerable; a fixed PHP is required
Zabbix frontend	Not published (not found)	NCSC list: vulnerable; an assessment, not a vendor notice
Joomla	Not published (not found)	NCSC list: vulnerable; same

The common rule is that raising the product's version is not enough; the PHP actually serving requests must be a fixed one. If your host manages PHP, confirm through the host's announcement. Products not in the table were not checked for this article.

1. What happened on 21 October

Ten hours from warning to recovery

According to the NCSC Community timeline, the NCSC first reported the two critical PHP vulnerabilities at 11:03 Dutch time on 21 October. No fix existed yet, so the NCSC told organisations to prepare for a PHP patch expected at 16:00.

The warning appeared on the government's news site at 13:59. It rested on three points: public proof-of-concept (PoC) code existed but no active exploitation had been seen; any internet-facing PHP system should be treated as probably vulnerable until patched; and organisations should consider extra measures, including shutting systems down.

The figure below puts the main events in order, based on the NOS live blog and the NCSC Community record.

The release time varies slightly by source

Sources give slightly different release times. NOS logged the fix at 15:43, the NCSC Community update recording the patches is timestamped 15:50, and NL Times wrote "around 4 p.m." All agree it came a little before the planned 16:00.

Time (Dutch)	Event	Main source
21 Oct 11:03	NCSC reports two critical flaws	NCSC Community
21 Oct 13:59	NCSC warning published on the government site	Rijksoverheid
21 Oct 15:43–16:00	PHP publishes fixed releases	NOS / NCSC / NL Times
21 Oct 18:11	MijnOverheid back online	NOS
21 Oct 20:27	DigiD website back online	NOS
22 Oct	overheid.nl and parts of NotuBiz still down	NOS

The table shows that recovery after the fix ranged from a few hours to more than a day. NL Times quoted the NCSC's deputy director as saying some sites can "flip a switch", while for others it takes longer, depending on the version they run.

2. The vulnerabilities: what is confirmed and what is not

Two CVEs and the name "PHP2Shell"

The two vulnerabilities are CVE-2026-109618 and CVE-2026-109619. A CVE is the global identifier assigned to a vulnerability; according to the NCSC-NL summary on GitHub, these were assigned by CERT-EU, the EU's cybersecurity service.

According to PHP's advisories, the first involves an inconsistency during out-of-memory handling, and the second involves internal state from one request surviving into the next. Under certain conditions both could let someone run code on the server without logging in (remote code execution, RCE).

"PHP2Shell" is the name used in the blog of Wiz, one of the firms involved in finding the flaws, and in Japan's IPA alert. It does not appear in the Dutch government warning or on PHP's home page.

Confirmed versus uncertain

Coverage changed every few hours, and some articles say different things about the same point. The table separates what the primary sources agreed on as of 22 October from what still varies.

Topic	Confirmed	Varies or unconfirmed
Number and IDs	Two: CVE-2026-109618 / 109619	Nothing
Fixed releases	8.5.12 / 8.4.27 / 8.3.36 / 8.2.35	A further patch may follow (NCSC)
Affected versions	Unpatched 8.2–8.5 are affected	Older range: NCSC says "from 5", Wiz "from 5.4"
Exploitation	Public PoC exists; CISA added both CVEs to KEV on 26 Oct	No official report of a real organisation breached (30 Oct)
Discovery	Found in August 2026 with AI-assisted research	Dates and finders differ between sources
Scale	Many organisations shut sites as a precaution	"About 70% of websites" is Wiz's estimate

The right-hand column may change with later announcements. When you quote these numbers in an article or an internal message, include the source and the date you checked.

"Not exploited" and "being targeted" can both be true

This section describes the position on 22 October. CISA has since added both flaws to KEV (26 October); see "What we learned after 22 October".

The NCSC, the PHP Foundation and the US CISA all said that, as of 22 October, they had not seen active exploitation. A spokesperson for justice minister David van Weel said there were currently no indications the flaws were being actively exploited.

At the same time, DutchNews.nl reported that Cloudflare had seen attackers searching for and attacking the flaws, and was defending against them. NOS reported that information about the flaw circulated among attackers after the update was announced. NL Times wrote that, according to the NCSC, details leaked before a patch was ready.

These statements do not contradict each other. "No confirmed breach yet" and "people are actively looking" can both be true at once. Site owners should act on the second.

Discovery dates do not match across sources

The accounts of how the flaws were found differ. NOS, citing the PHP Foundation, said the first flaw was found on 11 August by Calif and OpenAI, and the second on 24 August by Wiz. Wiz's own blog says it found the first flaw on 19 August and reported to PHP on 24 August.

DutchNews.nl wrote that the flaws were found in August using AI models from OpenAI and Google (Wiz is owned by Google). All agree the flaws were found in August with AI-assisted research, but the exact dates and who found what cannot be settled from these sources. This article lists the accounts side by side rather than picking one.

3. Fixed releases and PHP support periods

The fixed releases

On 21 October PHP published fixes for all four supported branches. The table pairs each fixed release with the support dates from PHP's official supported-versions page.

Branch	Fixed release	Active support ends	Security fixes end
8.5	8.5.12	31 Dec 2027	31 Dec 2029
8.4	8.4.27	31 Dec 2026	31 Dec 2028
8.3	8.3.36	31 Dec 2025 (ended)	31 Dec 2027
8.2	8.2.35	31 Dec 2024 (ended)	31 Dec 2026
8.1 and older	No official fix	Ended	Ended

The key line is 8.2: security fixes for 8.2 end in a little over two months. If you update to 8.2.35 and stop there, you will face the same decision again in January. Choosing 8.3 or newer lets you do the work once.

PHP 8.1 and older: minimal backports, not a real fix

The first Dutch government warning said that, as far as was known, the fixes applied only to PHP 8. A later NCSC Community update reported that minimal source backports had been published for 7.4, 8.0 and 8.1, and noted that this newer information supersedes the earlier statement.

Those backports are for people who build PHP from source. PHP itself, the UK NCSC and JPCERT/CC all recommend moving to a supported version. Linux distributions and long-term-support vendors may also ship their own patched packages.

4. Which sites went offline, and which kept working

Main Dutch sites taken offline

Precautionary shutdowns went well beyond government. The table groups the main examples reported by NOS, DutchNews.nl, NL Times and Dutch IT Leaders.

Sector	Reported examples	Sources
Government	DigiD, MijnOverheid, parliament, NCSC, overheid.nl, water boards' umbrella body	NOS / DutchNews / Rijksoverheid
Public services	UWV sick-leave tool, NotuBiz council documents	NOS / DutchNews
Education and research	Parts of the SURF shared network	NL Times / Dutch IT Leaders
Media	RTL site and app, NPO upload system, NL Times, DutchNews	NOS / NL Times / DutchNews
Health and charities	Several hospitals, KWF, Hartstichting, Amnesty	NOS / DutchNews
Everyday life	Schiphol app flight data, KNVB and football clubs	NOS

As the table shows, this was not only about government websites. It was a day that revealed how widely PHP sits behind services residents use every day.

The Dutch Data Protection Authority (AP)

Some accounts said the website of the Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP) was also taken offline. However, the AP is not named in the NOS, DutchNews.nl, NL Times and Dutch IT Leaders articles or the NCSC statements checked for this article. Whether the AP site went offline could not be confirmed here.

Beyond the Netherlands

DutchNews.nl and NOS reported that government sites in Flanders (Belgium), Germany, France and Finland were also taken offline for a time. In France, the interior ministry took prefecture sites offline. According to NOS, Belgium and France were still affected on 22 October.

The UK NCSC issued its own notice the same day, urging organisations to find every PHP installation and to prioritise internet-facing ones. National CERTs elsewhere, including Japan's, issued alerts on 22 October (section 13).

5. What this means for residents, and what to do

Nothing to install on your own devices

PHP runs on the servers that deliver websites. You do not need to update your phone, computer or browser. If you receive a message telling you to "install this app to fix the PHP vulnerability", that alone is a reason to suspect a scam.

For users, the practical impact was that some sites were unavailable for a few hours. According to NOS, even while the DigiD website was down, people could still use DigiD to log in to other organisations' services.

What to do service by service

The table covers the services reported as affected and how to handle them. Status changes over time, so check each organisation's official site for the latest.

Problem	Status (reported, 22 Oct)	What to do
Cannot log in with DigiD	Website back at 20:27 on 21 Oct	Try again later via the official address
Cannot read MijnOverheid messages	Back at 18:11 on 21 Oct	Deadline letters can also be checked by post or with the agency
overheid.nl will not load	Still down on 22 Oct, no return date	Look for the information on ministry websites
Council documents unavailable	Parts of NotuBiz down, including The Hague	Reported to return by the morning of 22 Oct. Ask the municipality if urgent
Cannot report sick via UWV	Tool temporarily offline	Contact your employer or phone UWV

If you missed a deadline because a site was down, note the date and time of the outage. A link to a news article or a screenshot makes it easier to explain later.

A note for The Hague residents

According to NOS, NotuBiz, a document system used by municipalities and provinces for council meetings, could not show official documents for The Hague, Almere, Breda, Haarlem, Den Bosch, Delft and others for a while. NotuBiz expected all pages to be back by the morning of 22 October. Worth knowing if you follow council agendas.

6. Watch out for scam emails and fake sites

The news is an easy hook for scammers

As of 22 October, no specific warning from the NCSC or DigiD about scams linked to this incident could be found. But DigiD's outage was widely reported, which makes messages like "You must re-verify your DigiD" or "Confirm your details for a security update" an obvious lure.

Consumer programmes Radar and Kassa have reported that DigiD does not send links or QR codes by email or text message. Treat any such message as fake.

Warning sign	Example	What to do
Contains a link or QR code	"Reactivate here"	Do not open it. DigiD does not send links
Creates urgency	"Confirm within 24 hours"	Stop, and go to the official site yourself
Asks for bank details	"Log in to receive a refund"	Do not enter anything. Call your bank
Unfamiliar sender	A look-alike domain	Delete it and consult the Fraudehelpdesk
Asks you to install an app	"Install this fix"	Do not. PHP fixes need nothing from users

Every action in the table comes down to one rule: never use the link in the message; go to the official entrance yourself. Use a bookmark, or search and check the official domain (digid.nl, mijn.overheid.nl) before logging in.

If you have already entered details

If you entered DigiD details, contact DigiD's fraud desk through the official site and change your password. If you entered bank details, phone your bank immediately. The Dutch Fraudehelpdesk also takes reports and gives advice.

7. How to check your website's PHP version

Ways to check

From here on, the article is for people who run websites for themselves or for clients. The first step is knowing exactly which PHP version your site runs. The table lists the options from easiest to most technical.

Method	Best for	Caveat
Hosting control panel	Shared hosting customers	"Selected" and "actually running" can differ
WordPress Site Health	WordPress users	Requires admin rights
Other CMS admin screens	Drupal, Joomla, etc.	Usually under "System information"
Ask your agency	Outsourced sites	Ask for the full version number
Command line on the server	VPS and own servers	CLI and web versions can differ

Whichever method you use, check the full version number, such as 8.3.36, not just the branch "8.3". Whether you are patched depends on the last number.

In your hosting control panel

Most shared hosts have a "PHP version" or "PHP settings" page in the control panel. It often shows only the branch, such as 8.3, so the exact patch level may need to come from the host's announcements or support team.

Hosts that let you pick a version per domain or directory can end up with different settings for different sites. If you have several sites or subdomains, check each one.

In your CMS admin

In WordPress, go to Tools, Site Health, Info, and open the Server section to see the PHP version actually serving the site. Because it reports the version used for web requests, it is one of the most reliable checks.

In Drupal, look under Reports, Status report. In Joomla, it is System, System Information. All require administrator rights.

Do not leave phpinfo() public

A file calling phpinfo() shows the version instantly. It also shows server configuration, extensions and file paths, which is exactly the reconnaissance an attacker wants.

If you use one, give it an unguessable name and delete it as soon as you are done. While you are at it, search for forgotten info.php or phpinfo.php files. For the same reason it is common practice to turn off expose_php, which advertises the PHP version in HTTP response headers.

Command line versus web

On a VPS or your own server, php -v shows the command-line PHP. The PHP that serves web requests (PHP-FPM or an Apache module) may be a different package and a different version.

After updating, check the version serving web requests, not just the CLI, and confirm that long-running processes such as PHP-FPM have been restarted. PHP's advisory names the Apache module setup (mod_php) as the highest-risk configuration.

Composer's platform setting matches production, it does not patch it

Composer, PHP's dependency manager, has a config.platform.php setting. It tells Composer to choose dependencies as if production runs this PHP version, regardless of the PHP on the developer's machine.

It does not update anything on the server. Once the server is updated, setting this value to match keeps development and production in step. Running composer check-platform-reqs on the deployment target confirms that production PHP meets your dependencies' requirements.

At DevNJ, we confirmed on 22 October that our own server had been updated to 8.3.36 and aligned our Composer platform setting to the same version.

8. If you use WordPress or another CMS

Updating the CMS is not the same as updating PHP

If your site runs on a PHP-based CMS such as WordPress, the key point is that updating the CMS core does not fix these flaws. The defect is in PHP itself, so PHP must be updated to a fixed release.

The NCSC and veiliginternetten.nl (the Dutch government's online-safety campaign site) list WordPress, Joomla, Drupal, Zabbix and Roundcube as examples of products that may be affected. Wiz's blog says its research confirmed exploitation against Drupal and WordPress.

What to check	Where	Target
PHP version	Site Health, admin panel	8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or newer
CMS core version	Admin dashboard	Latest stable release
Plugins and themes	Plugin list	Apply updates. Remove unused ones
Compatibility with newer PHP	Each plugin's details	Supports 8.3 or newer
Backup	Hosting control panel	Taken just before the update

The usual problem when moving PHP up a branch is old plugins or themes that break on newer PHP. Take a backup first and, if possible, test on a staging copy before touching production.

Steps before moving PHP up

1. Back up the whole site (files and database)
2. Update WordPress core, plugins and themes
3. Identify plugins that have not been updated in a long time, and replace or remove them
4. If possible, raise PHP on a staging copy and test key pages and the contact form
5. Raise PHP on production and repeat the checks
6. Confirm in Site Health that the web-facing version is now a fixed release

9. Who patches what depends on your hosting

Where responsibility splits

Who updates PHP depends on where your site lives. On shared hosting, the provider usually manages PHP. On a VPS or your own server, it is entirely your job (or your contractor's).

The figure shows the typical split for three common setups. The real division depends on your contract, so check it.

On shared hosting

On shared hosting you cannot update PHP yourself. What you can do is check your provider's announcements (news page, status page, email) to confirm they have moved to the fixed releases.

If you find nothing, ask support directly and quote the identifiers: "Have you updated to the fixed releases for CVE-2026-109618 and 109619, for example 8.3.36?" veiliginternetten.nl also advises asking your host whether they will patch PHP.

If the PHP branch selected in your control panel is old (7.4 or 8.1, for example), the host may have patched everything else while your branch has no fixed release at all. Switching to 8.3 or newer is the step that is in your hands.

Hosting type	What you do	Where to check
Shared hosting	Select a newer branch, update the CMS	Provider announcements and support
Managed WordPress	Update plugins and themes, test	Provider announcements, your contract
VPS or cloud server	Update PHP, restart PHP processes	OS security notices, PHP.net
Containers and images	Rebuild on an updated base image	Image maintainer's notices
Devices with bundled PHP	Apply the vendor update	Vendor notices, NCSC product list

The last row is easy to miss. The NCSC is inventorying products that use PHP in their admin interfaces, such as network equipment, enterprise hardware and IoT dashboards, because they may also be affected.

10. Moving off unsupported PHP versions

Why old versions matter so much this time

Each PHP branch normally gets two years of active support followed by two years of security fixes. Once that ends, no official fix arrives even for a flaw this serious.

Japan's IPA goes further than "migrate": it asks organisations to consider whether an unsupported system is still needed and whether its maintenance is sustainable. This incident is a good moment to take stock of every site you run.

How to migrate

Stage	What to do	Typical time
1. Inventory	List every site and server with its PHP version	1 day
2. Impact check	Check CMS, plugins and custom code for compatibility	A few days
3. Testing	Upgrade a staging copy and test	Days to 2 weeks
4. Production	Back up, schedule a window, switch over	Half a day
5. Watch	Monitor error logs and user reports	1 week

These durations assume a small to medium company website. Custom-built systems, or sites nobody has touched in years, can take much longer to test.

Note that, according to the PHP Supported Versions page (checked 30 October), PHP 8.2 stops receiving security fixes on 31 December 2026, so moving to 8.2 is not enough; aim for 8.3 or newer. If you would rather hand the inventory and testing to someone else, see our services and get in touch with a list of your sites and their PHP versions.

Temporary mitigations until you migrate

PHP has published temporary mitigations for systems that cannot be updated straight away, such as disabling the session upload-progress feature and reviewing memory and POST size limits.

Both PHP and the NCSC are explicit that mitigations only narrow specific attack paths and are not a complete fix. The NCSC also warns that abuse of the mitigations could lead to denial of service. Treat them as a way to buy time, always paired with a migration plan.

11. Looking for signs of compromise

Why patching is not the end of it

NL Times reported the NCSC's deputy director saying the flaw could have existed "for ages". DutchNews.nl reported the vulnerabilities had existed for over a decade. Whether something happened before you patched is a separate question.

The UK NCSC says that if you cannot update, disable or take a system offline, you should check it for signs of compromise and backdoors first. JPCERT/CC likewise recommends investigating for compromise alongside updating.

What to check

The table rephrases the indicators listed by JPCERT/CC and Wiz in terms site owners can check. It covers what to look for in logs and files, not how the attack works.

Where to look	Indicator	Note
Web server logs	Unusual uploads followed by repeated HTTP 500 errors	Not conclusive on its own
PHP error log	A sudden rise in memory-limit errors	Can also happen under normal load
Session cookies	Unusually long or malformed values recorded	Many setups do not log these
Processes	PHP workers crashing or restarting often	Check monitoring history
Files	Unfamiliar PHP files, odd modification times	Focus on upload folders
Network	Outbound connections to unknown destinations	Ask your host for help

JPCERT/CC notes that because there are several attack paths, a single detection rule may miss them; that depending on logging, no traces may remain; and that finding no indicators does not prove you were not attacked.

If something looks wrong

If you find suspicious signs, do not delete or overwrite logs and files. Preserve the evidence first, then assess the scope and, if needed, disconnect the site from the internet for a while. On shared hosting, contacting your provider's support is the first step.

If the site handles personal data and a leak is possible, consider whether you must report it under the GDPR. In the Netherlands, personal data breaches generally have to be reported to the AP within 72 hours of discovery. Get professional advice if you are unsure.

12. How to think about "switch it off"

Why the government switched off first

The Dutch government shut its own sites before any attack was confirmed. The NCSC warning asked organisations to assess the risk of each internet-facing PHP system until it is fixed and to consider extra measures, including shutting it down.

According to NL Times, the NCSC's deputy director said it is up to organisations to assess the risks and take systems offline if necessary, and that there was no panic in the Netherlands. Whether to switch off is a matter of weighing the impact of a breach against the inconvenience of downtime.

Type of site	Weight of the decision	Example approach
Logins or personal data	Heavy	Take offline or restrict access until patched
Has a contact form	Medium	Pausing for a few hours is an option
Brochure site, mostly static	Lighter	Monitor while waiting for the host's update
Admin panel of a business system	Heavy	Block access from outside your network

These are examples, not rules, and the right answer differs per organisation. What matters is deciding in advance who makes the call and how. The next sections cover that.

13. How national agencies framed it

Comparing the Dutch, UK and Japanese messages

Japan's IPA issued a "prepare now" pre-alert on 21 October and a full alert on 22 October, and JPCERT/CC published alert JPCERT-AT-2026-0033 with specific indicators of compromise to check.

The UK NCSC issued its notice on 21 October after the fix, saying all versions might be affected and laying out steps from inventory to compromise checks. The Dutch NCSC stands out for asking organisations to prepare for shutdowns before any fix existed.

Every agency agrees that updating is the only real fix and that old versions must be migrated. If you run sites in several countries, the actions are the same whichever agency you follow. What differs is how fast each hosting provider patches, so keep a list of which server runs which PHP version, per location.

14. Building an update routine

Four steps

The gap between organisations that recovered in hours and those still offline the next day came down to two things: whether they knew what was running where, and whether they had an update procedure ready. The figure shows a four-step routine that even a small organisation can run.

What each step involves

Step	What to do	Example tools
1. Inventory	One table of sites, servers, CMS, PHP versions and owners	A spreadsheet
2. Monitor	Follow PHP.net, the NCSC, your national CERT and your host	RSS, email alerts
3. Test	Try updates on a copy of production and check key pages	A staging server
4. Apply	Patch production in a set window, record date and version	A change log
Decide	Agree who decides on emergency shutdowns	A contact list

The "Decide" row is where organisations differed most this time. If the person who makes the shutdown call and the way to reach them are agreed in advance, you can act on the day a warning lands.

What to check in your agency or maintenance contract

If someone else runs your site, check that the contract covers:

• Who applies PHP and CMS security updates, and within what time frame
• How you will be contacted about urgent vulnerabilities, and how quickly
• Who may decide to take the site offline, and under what conditions
• How migration off unsupported versions is proposed and priced

15. Example cases (fictional)

Here are three fictional cases showing how the answer depends on your situation. They are not real people or companies.

Case (fictional)	Situation	First step
A, a small restaurant in The Hague	WordPress on shared hosting, booking form	Check Site Health and the host's announcements
B, an overseas manufacturer	English site for Europe, built and run by an agency	Ask the agency in writing for the version and patch date
C, an Amsterdam IT firm	Custom system on its own VPS, PHP 8.1	Apply mitigations now, plan a move to 8.3+

For A, PHP is the host's job, so the task is to check the version and consider pausing the booking form until the update is confirmed. For B, responsibility stays with B, so ask the agency which version runs and when it was patched, and keep the answer on file. For C, there is no official fix for 8.1, so mitigations buy time while the migration is fast-tracked and exposed admin screens are limited to known addresses.

16. What not to do

Don't	Why
Assume updating the CMS is enough	The flaw is in PHP itself. Check the PHP version
Leave a phpinfo() page online	It hands attackers a map of your server
Rely on mitigations alone	PHP says they are not a complete fix
Stop at 8.2.35	8.2 security support ends at the end of 2026
Check only the command-line version	The web-facing PHP may differ
Declare yourself safe because nothing showed up	Traces may not be logged at all
Check via a link in an email	Go to the official site yourself

The first three are the most common misunderstandings in this incident. "Our CMS is up to date, so we're fine" does not hold this time.

17. Checklist

As a resident

• I reach DigiD and MijnOverheid through a bookmark or by checking the official domain
• I have not opened links in emails or texts claiming to be from DigiD
• If an outage made me miss a deadline, I noted the date and time
• I ignored any request to install an "update app"

As a site owner

• I know the full PHP version number of every site we run
• Each one is on a fixed release (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35) or newer
• On shared hosting, I confirmed the update in the provider's announcements
• The branch selected in the control panel is 8.3 or newer
• I checked the web-facing version, for example in Site Health
• No phpinfo() files are left on the server
• There is a migration plan with a deadline for any site on 8.1 or older
• I checked the logs for signs of compromise
• I checked vendor notices for devices with bundled PHP (routers, NAS and so on)
• We agreed who decides on emergency shutdowns
• Our agency or maintenance contract states who patches and how fast
• We keep an inventory of sites, servers, versions and owners

18. Summary

• On 21 October 2026 the NCSC warned of two critical PHP flaws (CVE-2026-109618 and 109619), and DigiD, MijnOverheid, the parliament site and many others were taken offline as a precaution. DigiD and MijnOverheid were reported back that evening.
• The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There is no official fix for 8.1 and older, and 8.2 security support ends on 31 December 2026.
• No active exploitation had been confirmed as of 22 October, but public proof-of-concept code exists and scanning has been reported. Sources differ on the range of older versions affected and on the discovery timeline.
• Residents do not need to do anything on their own devices. The real risk is scams exploiting the news.
• Site owners should check the full PHP version in the control panel or Site Health, and on shared hosting confirm that the provider has patched.
• After patching, check logs for signs of compromise, and set up an inventory, monitor, test and apply routine so the next warning takes hours, not days.

Sources

Primary sources (agencies and the PHP project)

• NCSC: Ernstige kwetsbaarheden in PHP — Rijksoverheid: the warning published 21 October at 13:59; PoC exists, no exploitation seen, consider shutting down
• NCSC Advisories: NCSC-NL advisory list (alternative channel while ncsc.nl was down)
• PHP — NCSC Community: timeline from 11:03, minimal fixes for 7.4/8.0/8.1, examples of affected products
• NCSC-NL/php2shell — GitHub: CVE summary, fixed versions, affected setups, status of mitigations
• Critical security issue affecting PHP — UK NCSC: eight priority steps from inventory to compromise checks
• PHP.net: 21 October release announcements and temporary mitigations
• Supported Versions — PHP: support end dates per branch
• GHSA-w8hw-w9fx-j79w — php-src: advisory for CVE-2026-109618
• GHSA-6wmf-4rv5-p3rp — php-src: advisory for CVE-2026-109619
• PHP vulnerability alert — IPA (Japanese): 22 October alert; affected versions and handling of unsupported versions
• PHP security release pre-alert — IPA (Japanese): 21 October call to prepare
• JPCERT-AT-2026-0033 — JPCERT/CC (Japanese): indicators of compromise to check, and their limits
• Ernstige kwetsbaarheden in PHP — veiliginternetten.nl: what small organisations should check (CMS, hosting, devices)
• DigiD: official DigiD site
• Fraudehelpdesk: Dutch fraud reporting and advice

Added in the 30 October update

• CVE-2026-109618 — CVE Program: publication date, CVSS score, CISA KEV listing date
• CVE-2026-109619 — CVE Program: same
• Known Exploited Vulnerabilities Catalog — CISA: 26 October addition, 29 October due date
• PHP.net news: the 23 October notice on CVE-2026-115560 and the 26 October Windows rebuilds
• Releases — PHP: whether any release is newer than 8.5.12
• NCSC-NL/php2shell software list: per-product status and counts (updated 30 October, 09:14 CET)
• PHP2Shell — Automattic: protection for WordPress.com and others; note for self-hosters
• PHP vulnerability update — WP Engine: all customer sites patched (22 October)
• After the PHP security release — Drupal Association: how to audit Drupal sites
• Nextcloud All-in-One v14.4.1: release with updated PHP dependencies
• PHP2Shell: Exploitation Attempts and Remediation Trends — Wiz: observations and patching progress as of 27 October
• PHP2Shell now exploited in the wild — BleepingComputer: report on the honeypot exploitation
• Tientallen gemeentelijke websites nog kwetsbaar — Binnenlands Bestuur: BNR check of municipal sites (23 October)
• Tienduizenden PHP-applicaties draaien op getroffen versie — Binnenlands Bestuur: MindYourPass research (26 October)
• Overheidswebsites na urenlange uitval weer bereikbaar — Binnenlands Bestuur: recovery of municipal sites
• Nog altijd websites niet bereikbaar — NOS (updated 22 October, 06:53): record of overheid.nl still offline

Researchers and technical references

• PHP2Shell — Wiz Research: discovery timeline, affected versions (5.4 and later), indicators at a high level
• Composer config: platform: matching dependencies to the production PHP version
• Site Health Screen — WordPress.org: where WordPress shows the PHP version

News coverage

• Beveiligingsupdate PHP staat online — NOS live blog: time-stamped record of 21 October, other countries
• Nog altijd websites niet bereikbaar na lek — NOS: sites still down on 22 October, NotuBiz, discovery account
• Dutch parliament website taken offline — NL Times: parliament, SURF and others offline
• Critical PHP security fix released — NL Times: NCSC deputy director's briefing, why recovery takes time
• Government websites taken offline over hacking vulnerabilities — DutchNews.nl: scope of shutdowns, other countries, Cloudflare's observations
• Diverse websites offline door kritieke kwetsbaarheden in PHP — Dutch IT Leaders: CERT-EU advice, overview of impact
• Pas op: Valse DigiD-brief in omloop — Radar: DigiD does not send links or QR codes

The original sources were checked on 22 October 2026, and those under "Added in the 30 October update" on 30 October 2026. We also searched IamExpat, DutchReview and Expatica for coverage of this incident but found none at the time of checking. The situation is changing daily, so check the latest announcements from each organisation before acting.