The PHP Emergency, and Why Your Website Should Be Static
On 21 October 2026 PHP is releasing fixes for two critical vulnerabilities, both scored 9.2. For a client with a brochure site, you really should be serving files statically.
Yesterday the PHP Foundation posted this:
The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2.
PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence.
The same notice is on the PHP Foundation forum and the php.internals list. Two bugs. Both CVSS v4.0 9.2, which is Critical. Fixes scheduled for today, 21 October 2026, at 14:00 UTC (3pm in the UK, 4pm in central Europe). They will ship earlier if the details leak or they see the bugs being used.
If you are the person who paid for the website, read that as a question about your site. Does a visit execute PHP, and who is installing this update today?
What is public, and what is still withheld
The PHP security team has not published how the bugs work, which versions are affected, or which releases contain the fixes. That list arrives with the update. php.net is where the version numbers will be. Until those packages exist every PHP website on the internet is vulnerable.
BleepingComputer reports that researchers at watchTowr say information leaked ahead of the embargo. They name the issues CVE-2026-109618 and CVE-2026-109619, describe them as remote code execution, and say they understand them to affect PHP 5, 6, 7, and 8. They scored them 10.0. The PHP security team scored each one 9.2, and that is the number I am using. watchTowr also said they had reproduced one of the bugs, were withholding the technical write-up until patches exist, and had not seen attacks in the wild when they spoke to the press.
Remote code execution means a request can make the server run someone elseās code. The ordinary outcomes follow: a defaced homepage, mail sent from your domain, a database cloned or altered.
The leaked exploit, which researchers are calling PHP2Shell, is an HTTPS request. This encrypts traffic between a visitor and the server. It does not check what PHP does once that traffic is decrypted. The request hits the same https:// address your customers use, and PHP starts parsing it before your theme, your plugins, or your own code get a say. Sansec says a tool claiming to cover every PHP release from 5.4 onward leaked with the advisory, and that Cloudflare was already seeing attacks this morning. Aikido reports the configuration changes being passed around do not close it. A static file on a CDN never reaches that parser.
You can be a local company with a modest site and still be in that queue. Scammers do this at industrial scale. I have written about a small-business homepage defaced overnight in Why WordPress Is Not the Best Choice in 2026. The bots and scripts do not check your turnover first.
Updating PHP is the easy part
On a real site, there is a list of responsibilities someone has to own:
- Know that the site runs PHP, and which version.
- Know whether the host patches the runtime, whether your developer does, or whether it was quietly left with you.
- Apply the update the afternoon it ships. Use a staging copy if you have one.
- Check that the theme, the plugins, and any custom code still work.
- Do it again next time. There will be a next time.
A lot of brochure sites have no owner for that list. The freelancer who launched it has moved on. The agency retainer lapsed. The āmanagedā host patches on a Tuesday window, which is a long gap once a critical bug is public. Shared hosting sometimes still runs a PHP version the vendor has already stopped supporting, and the researcher reporting points at a range that reaches back years.
If you cannot name the person who will install this update today, you might be screwed.
WordPress is the version of this most clients will recognise. It is PHP, plus a database, plus an admin login on the public internet, plus whatever plugins were installed to make the homepage editable. Drupal, Magento, Laravel, and a custom build from 2014 sit in the same queue for this particular notice. The CMS is the part you log into. PHP is the part that has to be patched underneath it.
Current WordPress core, current plugins, a unique admin password, and two-factor auth are still worth doing this week. They do not replace the PHP update.
A static site sits this one out
A static site is built before anyone visits. The deploy produces HTML, CSS, and JavaScript. A visitor receives a file from a CDN. That request does not start a PHP process, open a database, or pass through an admin login.
This advisory needs a PHP runtime interpreting the request. Files on a CDN do not offer it one. There is no PHP version on the live site to be behind.
The fuller case is in Why You Should Have a Static Site: speed, a small hosting bill, content in Git, and a smaller attack surface as the default. You still care about third-party scripts, form endpoints, and who can push to the repo. Those are specific risks with specific owners. A language runtime, a CMS, and a stack of plugins are not sitting on the same public URL as the homepage, waiting for the next advisory.
For a marketing site, the usual build is Astro rather than a React app framework. Pages and posts are files. A bad edit fails in the build, in front of you, before it fails in front of a customer.
What to send your developer today
If the site is still PHP, forward them this. Today, before the release window closes.
- Which PHP version are we on, and which patched release will we move to once it ships at 14:00 UTC?
- Who applies it, and when? If the host auto-updates, confirm that includes the PHP runtime, not only WordPress core.
- Where is the staging site, and who checks production after the update?
- What is the rollback if a plugin breaks?
Keep it simple
You do not need a working knowledge of these critical vulnerabilites. You need web security that fits the website you bought. Static sites do this out of the box.
For a brochure, a portfolio, or a blog, pages are files. Changes go through the repo. The live site has no PHP and no admin login. An advisory like this one is something you read, because your site was never affected.
If that is the kind of site you want, get in touch.