A critical PHP flaw can hand your whole site to an attacker.
Check a site now
Enter your site, a client's, or any site you are responsible for. It is read from the outside, one host. No web addresses are stored, only anonymous totals. It looks past the home page for the PHP system underneath: WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel and more.
PHP shipped an emergency fix today for flaws rated 9.2 out of 10 that let an attacker run their own code on the server with no password. The details leaked and exploit code was published before the patch was. About 69% of the web runs PHP, and government sites went offline to wait for it. The fix only exists for PHP 8.2 to 8.5. Every site on 8.1 or older, WordPress or not, stays open.
Patched versions, released 21 Oct 2026
8.5.12 · 8.4.27 · 8.3.36 · 8.2.35
8.1, 8.0, 7.x and 5.x: no patch, ever.
THE EXACT ANSWER
Check the exact version from inside your own site
The checker above reads your site from the outside, so when the version is hidden it can only tell you it runs PHP. The one way to get the exact version is from inside the site itself. This is safe, it is what your own tools do, and it only works if you can already put a file on the server, which proves it is yours.
- 1Save the code as check-php.php
- 2Upload it to your site’s main folder
- 3Open yourdomain.com/check-php.php in a browser
- 4Read the version, then delete the file
<?php
// check-php.php - shows your exact PHP version. Delete this file afterwards.
echo 'PHP ' . PHP_VERSION;
echo PHP_VERSION_ID < 80200
? ' -> END OF LIFE, no official fix. Upgrade needed.'
: ' -> supported. Apply the latest patch for your branch.';Not sure how to upload a file, or want it done across every site you run? That is exactly what the free review covers.
RIGHT NOW
Do this in the next hour
Exploit code is already out, so the gap between the patch and an attack is short. In order:
- 1
Find out your PHP version
Use the checker above, your hosting panel, or run php -v on the server.
- 2
On 8.2 to 8.5: update now
Install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart PHP (PHP-FPM or the web server) so the fix actually loads.
- 3
Ask your host
Large managed hosts were given the patch early. Ask in writing whether your server is already on a fixed version.
- 4
On 8.1 or older: there is no patch
The only fix is moving to a newer PHP version. If that cannot happen today, seriously consider taking the site offline until it does.
- 5
Stopgap only
Setting session.upload_progress.enabled = Off in php.ini is being shared as a temporary measure. Security researchers say it may not fully protect you. It buys time; it is not a fix.
- 6
Then check nothing got in
Look for new admin users, files you did not upload and recently changed files. A site that was open before the patch may already have a backdoor. Security firms suggest looking back as far as June 2026.
LIVE UPDATES
What has happened so far
Last updated 21 Oct 2026, 14:40 UTC. Newest first.
21 Oct · afternoon · latest
With the patch out, Cloudflare reports early attempts to exploit the flaws and pushes emergency firewall rules for sites behind it. Aikido tells teams to patch now and check for compromise going back to June 2026.
Source: Aikido, The Hacker News
21 Oct · afternoon
Researchers warn the php.ini setting shared as a stopgap is not enough on its own, and that updating WordPress or a framework does not close the hole, because the bug is in PHP itself. Every PHP setup serving web pages is in scope, including PHP-FPM, Apache mod_php and LiteSpeed.
Source: The Hacker News, SOCRadar
21 Oct · about 13:35 UTC
PHP releases the fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, about 25 minutes ahead of schedule. PHP 8.1 and older get no fix.
21 Oct
Tenable publishes an FAQ and says it could not verify that the exploit code circulating online works against either flaw.
Source: Tenable
21 Oct
Dutch government sites including DigiD and MijnOverheid go offline as a precaution until the patch lands.
Source: Techzine, Patchstack
21 Oct, morning
Exploitation reports conflict. Some firms say attacks have started; watchTowr says it reproduced one of the bugs. Security teams start pushing stopgap settings.
Source: Patchstack, ITdaily, Help Net Security
20 to 21 Oct
Details leak before the planned disclosure and proof-of-concept exploit code appears online. Security press warns of mass exploitation.
Source: Infosecurity Magazine, SecurityWeek, The Hacker News
20 Oct
The PHP security team announces an emergency security release for 21 October at 14:00 UTC, rated 9.2 critical.
Source: PHP announcement, Laravel News
WHAT THE FIX REALLY INVOLVES
It depends where you start
For some sites this is a ten-minute update. For others it is a project. Here is what a professional has to do in each situation, and roughly how long it takes.
Simplest
On PHP 8.2 to 8.5, one site, a managed host
- Update to the patched release
- Restart PHP
- Click through the site to confirm it still works
Typically under an hour
More work
On 8.2 to 8.5, your own server or VPS, or several sites
- Patch every server and restart its services
- Check each site separately
- Read the server logs for signs of an attack before the patch
Typically a few hours
A real project
On PHP 8.1 or 8.0, no patch available
- Full backup that is proven to restore
- Copy the site to a staging server
- Update plugins, themes and code libraries that break on the new PHP
- Fix deprecated code, then test every page, form and checkout
- Move it live and watch the logs
Typically half a day to a few days per site
Possibly a rebuild
On PHP 7.x or 5.x, years out of date
- Old plugins and themes often no longer exist for modern PHP
- Custom code may need rewriting
- Database and character-set problems are common
- May need a new server altogether
Days to weeks. Sometimes rebuilding is cheaper than upgrading
Incident clean-up
Already broken into before you patched
- Find and remove backdoors and web shells
- Reset every password, key and database login
- Check the database for injected content and fake admin accounts
- Restore from a clean backup and harden the server
- Get the site off Google’s blacklist, and decide whether customers must be told
A day to a week or more, depending on the damage
Not sure which one you are?
That is what the free review is for. I tell you which situation each of your sites is in, and what it will take, before anyone touches anything.
Get a free reviewTimes are typical ranges from experience, not quotes. Every site is different.
You are almost certainly running PHP
PHP is the engine under most of the web. It is usually invisible, which is exactly why this catches people out.
Sources: W3Techs, October 2026. “No fix” counts PHP 7, PHP 5 and PHP 8.0 to 8.1, all end of life.
WHAT IS ACTUALLY AT STAKE
What an attacker gets
Remote code execution is the worst kind of flaw. It is not a defaced page. It is the keys to the whole server.
Full control of your server
Remote code execution means they run their own commands on your server, as if they were sitting at it. No password needed. From there, everything below is on the table.
Your whole database, stolen
Customer names, emails, addresses, orders, password hashes, anything your site stores. Downloaded in minutes, quietly.
Your clients’ data too
If you host or build sites for others, their customers’ data sits on the same server. One breach can become a breach you have to report, with the liability that follows.
Ransomware and lockout
They encrypt or delete your files and your database and demand payment. If your backups are on the same server, they take those too.
Blacklisted by Google
Injected spam or malware gets your domain flagged with a red warning screen. Traffic and rankings you spent years on can vanish in a day.
A hidden backdoor
They leave a web shell behind so they can come back after you patch. This is why patching alone is not enough. Someone has to check the site was not already taken.
THE HIDDEN RISK
The sites you forgot run PHP
You do not have to know a site is PHP for it to be broken into. Attackers scan the entire internet automatically, around the clock, hitting every address they can find. The sites that get hit are usually the ones nobody is watching.
If you run a business online, or you have ever had sites built for you, it is worth taking five minutes to account for all of them.
- A WordPress or WooCommerce site, even one that looks like a simple brochure
- An old site or landing page you built years ago and forgot was still online
- A client’s site you set up and no longer think about
- A subdomain, a staging copy, or a microsite left running
- A contact form, booking tool or members area a plugin runs in PHP
- A Drupal, Joomla, Magento, Laravel, phpBB, MediaWiki or Moodle install
- An online store on WooCommerce, Magento, PrestaShop or OpenCart
- A cheap shared-hosting plan where the PHP version was set years ago and never changed
- Custom code a past developer wrote in PHP that nobody has touched since
WHY IT NEEDS CARE
Why you can't just click “update”
Upgrading PHP does not touch your files, but it changes the rules they run under. On sites still on 8.1 or older, there is no quick patch at all, you have to move versions. Done carelessly, that is how a working site goes dark. Here is what tends to break.
The white screen of death
The whole site goes blank, no error shown to visitors, nothing in the browser. Old code hit a rule the new PHP version removed.
Dead plugins and themes
Anything that has not shipped an update in a year or more can fatal-error the moment it runs on a newer PHP. On WordPress that is most sites.
A broken checkout
On a store, the part that breaks is often the cart or the payment step, so you lose orders without knowing until a customer complains.
Lost or corrupted data
A botched upgrade or a half-finished rollback can leave the database in a bad state. Without a clean backup taken first, that can be permanent.
The way to do it without taking the site down
- 1Back up the whole site and database, and confirm the backup actually restores
- 2Clone it to a staging copy and do the upgrade there first
- 3Update plugins, themes and dependencies to versions that support the new PHP
- 4Click through every page, form and checkout, and fix what breaks
- 5Move it live in a quiet window, then watch the logs
- 6Scan for backdoors, because a site on an old version may already be compromised
This is a few hours of careful work per site, and it is the kind of thing that is cheap to get right and expensive to get wrong. It is worth having someone who has done it before do it for you.
GET IT HANDLED
I can check it, and fix it properly
I have built and run PHP sites for twenty years. Start with a free review, no obligation. If you want it handled after that, I will do it safely and tell you the cost first.
START HERE · FREE
A free review
Send me your site, or a list of the sites you are responsible for. I will check what each one runs, whether it is exposed, and tell you plainly where you stand and what it would take to fix. No cost, no obligation.
IF YOU WANT IT DONE
The expert fix
I back up your site, upgrade and patch it on a copy, test every page, form and checkout, move it live with as little downtime as possible, and scan for anything already planted. One site or a whole portfolio.
or email kyle@simgen.dev · Clouthier Simulation Labs, Petawawa, Ontario
Common questions
What is the PHP vulnerability on October 21, 2026?
Critical flaws in PHP core, rated 9.2 out of 10, that allow remote code execution: an attacker can run their own code on a server running PHP without any password. The details leaked and exploit code was published before the fix. PHP released the fix on October 21, 2026 as versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no fix.
Does it affect my site?
About 69% of all websites run on PHP, including every WordPress, WooCommerce, Drupal, Joomla, Magento and Laravel site. If your site runs any of those, or any custom PHP, it is affected. Versions 8.1 and older get no official fix and must be upgraded.
Can I just click update?
Not safely. Changing the PHP version changes the rules your code runs under. Old plugins, themes and custom code can fail instantly with a blank white screen, and sites on 8.1 or older need a full version upgrade, which is where things break. It should be done on a copy first, tested, then moved live, then scanned for anything already planted.
What can an attacker do?
With remote code execution they can take full control of the server: steal your database and your clients’ data, install ransomware, deface the site, get it blacklisted by Google, use it to attack others, and leave a hidden backdoor that survives the patch.
Official sources
This page is general security information, not a scan of your site, and the checker reads only what a site shows publicly. php.net lists the fixes under advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp; the CVE numbers circulating online (CVE-2026-109618 and CVE-2026-109619) were not shown on php.net when this was written. Always follow the official advisory above.