
On Wednesday 21 October 2026 the PHP team released fixes for two critical flaws that let an attacker run their own code on a server without logging in. PHP runs on most websites where the server-side language can be detected, and on every WordPress website. I summarise what happened, what a WordPress owner should check right away and why I build custom websites on Next.js, without PHP and without WordPress. This is not scaremongering: WordPress has its place, and I help clients who already have it.
PHP is used by 69.3% of websites whose server-side language W3Techs knows, and WordPress runs on 39.6% of all websites (as of 21 October 2026). The fixed PHP versions from 21 October 2026 are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; both flaws (CVE-2026-109618 and CVE-2026-109619) have a CVSS 4.0 score of 9.2. Updating WordPress or plugins does not fix them, PHP has to be updated by the hosting provider or the server administrator. For WordPress itself the main risk is in extensions: according to Patchstack, 91% of new vulnerabilities in 2025 were in plugins and 9% in themes. I build websites on Next.js with static generation, so the server does not need to run PHP, a database or a public admin login.
- What I build. I build custom websites and e-shops in Next.js and React. This website also runs on Next.js and is deployed on Vercel.
- I help with WordPress. For clients who already have WordPress, I help as part of IT help and website management. I do not rewrite a working website just because I would have picked a different technology myself.
- What is not in the article. Numbers from my own projects. Every fact has a link to its source, as of the evening of 21 October 2026.
What happened to PHP on 21 October 2026?
On 20 October the PHP security team announced on php.net an extraordinary release for Wednesday 21 October at 14:00 UTC. On Wednesday the fixed versions and the security advisory came out. The media call the flaws PHP2Shell.
- Two flaws, both critical. CVE-2026-109618 relates to out-of-memory handling, CVE-2026-109619 to internal state that survives the end of a request. The PHP team rates them CVSS 4.0 9.2, the US database NVD CVSS 3.1 9.8.
- Who is affected. According to php.net, all PHP installations that serve web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It sees the highest risk in mod_php, where an attack has been demonstrated that runs before the application code even starts.
- Only an update is a full fix. The temporary mitigations from the advisory, for example disabling
session.upload_progress.enabledinphp.ini, close only some attack paths according to the PHP team. They do not make an installation safe. - Older versions. PHP 8.1 and older no longer receive updates from the project. For 7.4, 8.0 and 8.1 the PHP team exceptionally published minimal patches in source code, otherwise the fix comes from Linux distributions and long-term support vendors.
| PHP version | Fixed version from 21 October 2026 | Security support from the PHP project |
|---|---|---|
| 8.5 | 8.5.12 | until 31 December 2029 |
| 8.4 | 8.4.27 | until 31 December 2028 |
| 8.3 | 8.3.36 | until 31 December 2027 |
| 8.2 | 8.2.35 | until 31 December 2026 |
| 8.1 and older | no new version, only patches in source code | ended |
Support dates are from the overview of supported PHP versions, as of 21 October 2026.
Is the flaw already being exploited?
Sources differ as of the evening of 21 October. The php.net advisory talks about a demonstrated attack, not about exploitation. According to the news agency ANP, the Dutch NCSC had not recorded active exploitation in the Netherlands on Wednesday. Qualys however states that Cloudflare reports attack traffic aimed at these flaws. Expect the situation to change over the coming days.
What happened in the Netherlands?
The Netherlands reacted most visibly. According to a summary by the news agency ANP in Reformatorisch Dagblad and Hart van Nederland, websites were taken offline as a precaution, among them the Tweede Kamer (the lower house of parliament), the MijnOverheid portal, several hospitals and some of the security regions. According to ANP, the hosting provider MijnDomein shut down its own website and its customers' websites, and Yourhosting temporarily switched off its systems, both until the fix was released. According to De Zaak, other Dutch hosting providers told customers they did not need to do anything because they would deploy the fix themselves. According to ANP, CERT-EU recommended disconnecting internet-facing applications that cannot be fixed right away.
I did not find announcements from Czech hosting providers about these flaws by the evening of 21 October. That does not mean they are doing nothing: ask your hosting provider directly, the procedure is below.
How many websites run on PHP and WordPress?
The often repeated "70% of the internet" is a rounded figure from W3Techs. Exact values as of 21 October 2026:
| Indicator | Value | Source |
|---|---|---|
| Websites on PHP | 69.3% of websites whose server-side language W3Techs knows | W3Techs: PHP |
| Websites on WordPress | 39.6% of all websites, 58.3% of websites with a known content management system | W3Techs: WordPress |
| WordPress websites on PHP older than 8.2 | 36.4% | WordPress.org, my sum of branches 4.4 to 8.1 |
WordPress.org collects PHP version statistics from websites that check for updates with it. So more than a third of them run on a PHP version for which the PHP project released no new version on 21 October. Some of them may have a fix from their distribution, but the hosting provider has to confirm that.
Why are WordPress websites a frequent target?
The WordPress core is well maintained. The risk is in what is assembled around it. The report Patchstack State of WordPress Security in 2026 states for 2025:
- 11,334 new vulnerabilities in the WordPress ecosystem, 42% more than in 2024,
- 91% of them in plugins and 9% in themes, in the core only 6, with low priority,
- 46% of vulnerabilities had no fix from the author at the time of disclosure,
- the weighted median time to first exploitation is 5 hours.
What follows from this: every WordPress is a different combination of core, plugins, theme and PHP version. Its security is only as good as its weakest plugin and the speed at which someone deploys the fix. A weekly check for updates is not enough against a five-hour window. And because the login sits at the same address by default (/wp-login.php), an attacker does not have to look for targets by hand.
How do I build websites and why without PHP?
I build custom websites in Next.js. For a company website, most pages are produced in advance, at build time (static generation). The server then sends the visitor ready-made files, usually from a CDN. For security this means:
- No PHP runs on the server. Flaws like those of 21 October do not affect such a website.
- No admin login on the website. When a client needs to edit content on their own, a content management system (CMS) is added. It has its own login and belongs in maintenance like everything else.
- A database only where it is needed. A presentation website mostly does not need one. A client zone or an e-shop does, and then it is another part that needs care.
- Fewer third-party add-ons. Functions are part of the project code, not dozens of plugins from different authors. But npm packages exist and they also have to be updated.
- Every change is a version in git. A deployment can be rolled back to the previous version.
- Speed. A ready-made page from a CDN does not wait for PHP or a database. I verify the result by measuring, not by promising, see how to speed up a website.
Is a Next.js website more secure?
When it is built statically, it has a smaller attack surface. It is not free of flaws, though. On 3 December 2025 React and Next.js published the critical flaw React2Shell (CVE-2025-55182, CVSS 10.0), which allowed code to run on the server without logging in. It affected applications using the App Router in Next.js 15 and 16. Websites whose React code does not use a server were not affected. The fix was the same as now with PHP: an immediate update.
I take a simple rule from this: technology reduces risk, but every website needs someone who watches the security advisories and deploys the fix.
| Area | WordPress (typical website) | Next.js with static generation |
|---|---|---|
| What runs on a visit | PHP and database queries, unless a cache serves the page | ready-made files from a CDN, a server function only for forms and the like |
| Admin login | on the same domain (/wp-login.php) |
a static website has none, a connected CMS has its own login |
| Who supplies the features | core, plugins and themes from different authors | project code and npm packages |
| What to update | core, plugins, theme and PHP on the server | Next.js, React and packages, deployment via git |
| PHP flaw of 21 October 2026 | affected, the hosting provider deploys the fix | not affected, no PHP runs |
| React2Shell of 3 December 2025 | not affected | affected applications with the App Router and server components |
| Editing content without a programmer | the editor is built in | only with a connected CMS |
When does WordPress make sense and when a custom website?
I do not consider WordPress a bad choice. The bad choice is a website nobody looks after, whatever it runs on.
| Situation | What I would choose |
|---|---|
| A newsroom with several authors, approvals and articles every week | WordPress on managed hosting with regular maintenance |
| You need a ready-made function from a plugin (bookings, membership, courses) and have a small development budget | WordPress with as few plugins as possible, from active authors |
| A working WordPress you are happy with | Keep it and maintain it, switching just for fashion makes no sense |
| A company presentation that changes a couple of times a month | A custom website with static generation |
| Speed, a custom design and the least possible maintenance matter to you | A custom website |
| A calculator, a configurator, a CRM integration or a client zone | A custom website or application |
For a comparison of editorial work, performance and price, see the article WordPress vs Next.js. When Next.js alone pays off, I describe in the article why choose Next.js for a business website.
What should I check right away if I have a WordPress website?
- Find out the PHP version. In the WordPress admin: Tools → Site Health → Info → Server. Or in your hosting administration.
- Ask your hosting provider whether it has deployed the fix of 21 October 2026. The fixed versions are 8.5.12, 8.4.27, 8.3.36, 8.2.35 and newer. Linux distributions may carry the fix under an older version number, so ask the hosting provider for confirmation, not just the number. Do not trust emails that ask you for login details because of the PHP flaw, and verify them directly with your hosting provider.
- Is the website on PHP 8.1 or older? Plan the move. Ideally straight to 8.3 or newer, because 8.2 has support only until 31 December 2026. Before the change make a backup and test the website on a staging copy, old plugins may not work on a new PHP version.
- Update the core, plugins and themes and delete the unused ones. It will not fix the PHP flaw, but it covers the places where most WordPress vulnerabilities arise.
- Keep a backup outside the server and test the restore. A backup nobody has restored is just an assumption.
- Secure the login. Unique passwords, two-factor authentication and only as many administrators as are really needed.
- Do you run your own server and cannot update right away? Use the temporary mitigations from the PHP advisory, for example
session.upload_progress.enabled=0inphp.iniand a restart of all workers. It is not a full fix. If the update will take long, consider taking the website offline temporarily, as CERT-EU advises. - Do you see foreign content, redirects or browser warnings? The procedure is in the article my website is down, what now.
How can I help you with this?
- You want WordPress maintained: website management from €60/month, or one-off IT help for websites and e-shops when something does not work.
- You are considering a website without PHP: web development starts at €800 with me. When moving from WordPress it is important to keep the addresses and redirects, see protecting SEO during migration.
FAQ
Does the PHP flaw of 21 October 2026 affect my WordPress website?
Yes, until your hosting provider deploys the fix. WordPress always runs on PHP and the flaws affect all PHP installations that serve web requests. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; for PHP 8.1 and older it depends on whether the hosting provider has deployed a fix from the distribution.
Will updating WordPress or plugins fix it?
No. The flaw is in PHP itself on the server, not in WordPress. The fix has to be deployed by the hosting provider or the server administrator. Updating WordPress and plugins is still important because of their own vulnerabilities.
Is WordPress dangerous?
The WordPress core is well maintained, Patchstack reports only 6 low-priority core vulnerabilities for 2025. The risk is in plugins and themes (91% and 9% of new vulnerabilities), in old PHP and in missing maintenance. A maintained WordPress with a few vetted plugins can be a reasonable choice.
Is a Next.js website completely secure?
No. A static Next.js website has a smaller attack surface because the server runs no PHP, database or public login. But Next.js and React also had a critical flaw (React2Shell, December 2025, CVSS 10.0), and packages have to be updated. Maintenance makes security, not the name of the technology.
Should I move from WordPress to a custom website because of this?
Not because of one flaw. A move makes sense when you need to redo the website anyway, nobody looks after the WordPress, or you want a fast website with the least possible maintenance. If WordPress works and you have a person for maintenance, it is cheaper to maintain it.
Is it true that PHP runs 70% of the internet?
Approximately. According to W3Techs as of 21 October 2026, PHP is used by 69.3% of websites whose server-side language can be detected. For the others the share is unknown. WordPress runs on 39.6% of all websites.
Sources and links
- PHP: security advisory of 21 October 2026, preliminary announcement of 20 October 2026 and supported versions
- NVD: CVE-2026-109618 and CVE-2026-109619
- Qualys: PHP2Shell, temporary mitigations and a report of attack traffic
- W3Techs: PHP and WordPress, as of 21 October 2026
- WordPress.org: PHP version statistics, as of 21 October 2026
- Patchstack: State of WordPress Security in 2026
- React: critical vulnerability in React Server Components and Next.js: CVE-2025-66478
- The Netherlands, news agency ANP: Reformatorisch Dagblad, hosting providers shutting down websites, Hart van Nederland; hosting providers according to De Zaak
