Security advisory · fixed 21 October 2026
PHP2Shell on Windows Server: patch PHP on IIS today, and never patch it by hand again
On 21 October 2026 the PHP project fixed two flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell. An attacker needs no password and no vulnerable website: any server that serves PHP is a target, and php-cgi under IIS is on the list. This page tells you whether your Windows web server is exposed, how to patch it by hand, and why ServerMaid servers were safe again by the next hour without anyone logging on.
Automatic PHP security updates are part of ServerMaid from version 1.3.47. Server setup from £99 £49.50 per server for twelve months. 30-day money-back promise.
What PHP2Shell is
Most PHP security stories are about a plugin, a framework or a badly written site. PHP2Shell is different: the bugs are in PHP itself, in the way it handles memory when a request ends abnormally. CVE-2026-109618 corrupts memory when PHP runs out of it mid-request; CVE-2026-109619 lets state from one request leak into the next on the same worker. Chained, each gives an unauthenticated attacker code execution as the account the web server runs PHP under.
The PHP project states that all PHP installations serving web requests are at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. On Windows Server, IIS runs PHP through FastCGI as php-cgi.exe, so every PHP website on IIS is in scope. The fixed releases are:
| PHP line | First safe release | Status |
|---|---|---|
| 8.5 | 8.5.12 | Active support |
| 8.4 | 8.4.27 | Active support |
| 8.3 | 8.3.36 | Security fixes only |
| 8.2 | 8.2.35 | Security fixes only, until 31 December 2026 |
| 8.1 and older | None | No fixed Windows build will be published. Move the websites to 8.3 or newer. |
The advisory was pre-announced on 20 October, the details leaked the same day, and the fixed releases went out at 14:00 UTC on the 21st. Security teams across Europe, including the UK and Dutch national cyber security centres, told organisations to update at once or take affected systems offline. Sources: the PHP project’s release announcements and the NCSC-NL operational notes.
The PHP project also published interim settings that reduce exposure, such as turning off session.upload_progress, and was clear that they are not a fix. The only fix is the patched PHP.
Are you exposed? Three questions
- Does anything on the server run PHP? In IIS Manager, open the server node, then Handler Mappings. Any mapping whose executable ends in
php-cgi.exemeans yes. Check each website too: a site can carry its own PHP mapping in its web.config. - Which version is it? Open a command prompt in the folder that mapping points at and run
php-cgi.exe -v. Do it for every PHP folder the mappings name; servers that have been upgraded over the years often have two or three. - Is it below the first safe release for its line? Anything below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 is exposed right now. Anything on 8.1, 8.0 or 7.x is exposed with no fix coming, and the only remedy is to move those websites to a supported line.
If the answer to all three is yes, the server needs patching today, not at the next maintenance window. A ServerMaid server answers these questions for you: the Dashboard shows a Critical PHP security updates alert naming the version, the folder and the flaw it is open to, and the health score drops until it is fixed.
Patching PHP on IIS by hand
Without a tool, this is the job, for each PHP line on each server:
- Download the fixed release from windows.php.net: the Non Thread Safe x64 zip, built with the same compiler as the one you have (vs16 for 8.2 and 8.3, vs17 for 8.4 and 8.5). Check the SHA-256 the site publishes against the file you downloaded.
- Stop the websites that use that PHP, or stop IIS. A running php-cgi.exe holds its files open.
- Copy the existing PHP folder somewhere safe, with its
php.ini. - Extract the new release into the same folder, then put your
php.iniback. If you extract to a new folder instead, update every FastCGI application and handler mapping that pointed at the old one, including the ones inside individual websites. - Check that the Visual C++ runtime the new build needs is installed; a newer build can need a newer runtime, and the symptom is the unhelpful FastCGI process exited unexpectedly.
- Start IIS again and confirm with
php-cgi.exe -vand a real page load. - Restart IIS even if you replaced the files in place. IIS keeps the php-cgi.exe workers it already started, and they go on serving requests with the old code until they recycle on their own. This is the step most write-ups skip, and it leaves a server looking patched while it is not.
- Repeat for the next PHP line, then the next server. Then put something in place that tells you when the next release lands.
It works. It takes a careful hour per server for someone who has done it before, and it has to happen at the moment the release comes out, whatever else you were doing that Tuesday afternoon.
Why by-hand patching keeps failing
The patch exists. The problem is everything around it.
Nobody was watching the release list
The fix was published at 14:00 UTC on a weekday. Most small businesses and agencies found out days later, if at all. Exposure is measured from the moment the exploit is public, not from the moment you heard.
The worker trap
Replace the files, forget to restart IIS, and the old PHP keeps answering requests. The server passes every version check you run by hand and is still exploitable.
More lines, more servers
One server with 8.3 and 8.4 side by side is two patches. An agency with twelve client servers is twenty or more, each with its own php.ini and its own quirks.
The person who knew how has left
The PHP install was done by a contractor in 2023. The notes, if there were any, are on a laptop nobody has. The next person starts from scratch, under pressure.
Old lines with no fix
Servers still on PHP 8.1, 8.0 or 7.4 cannot be patched at all. Those websites have to move to a supported line, which is a different job from a patch and a bigger one.
This is not the last one
PHP ships security releases several times a year. Whatever you do for PHP2Shell by hand, you will do again, and the next one may land on a Friday night.
The ServerMaid way
Seven reasons a ServerMaid server was safe by the next hour
ServerMaid is the automated Windows web server engineer: it installed your PHP, it knows which release each line should be on, and from version 1.3.47 it keeps it there by itself.
It checks every hour, not when someone remembers
The hourly health scan compares every PHP line ServerMaid installed with the official windows.php.net release list. A new security release is noticed within the hour of publication, on every server, with nobody logged on.
It installs the fix, in place
The fixed release is downloaded from windows.php.net, checked against the SHA-256 the PHP project publishes, extracted beside the live folder and swapped in. Your php.ini stays. 8.4 stays 8.4 and 8.3 stays 8.3, so nothing about your websites changes except the hole being closed.
It stops the old PHP processes
ServerMaid ends the php-cgi workers that were running the old code, so the very next request is served by the patched PHP. No forgotten iisreset, no server that looks patched but is not.
It can undo it
The previous copy is parked beside the new one and the change is journaled like every other change ServerMaid makes. If a patch release ever disagreed with one of your sites, Roll back puts the old PHP back in seconds.
It tells you, in plain English
Until the fix is in, the Dashboard shows a Critical alert: which PHP, which folder, which flaw, and a Fix button that does it now. When it is done, the alert clears and the health score recovers. Your account page shows the same for every server you run.
It knows what it did not install
A PHP somebody else put on the server is never touched, because websites may depend on it. It is flagged instead: version, folder, and what to do. A line the PHP project no longer fixes gets the same honest treatment.
It did the rest of the hardening first
PHP2Shell gives an attacker code execution as the web server account. On a ServerMaid server that account has the least permission it needs, the database only listens locally, Remote Desktop is closed to the world and backups are proven by a restore test. One flaw does not become a lost server.
Automatic PHP security updates arrived in ServerMaid 1.3.47 on 22 October 2026 and apply to every PHP line ServerMaid installed, on every licence that is in date. The same machinery handles every future PHP security release without another ServerMaid update. Moving between PHP lines stays your decision, one website at a time.
Beyond PHP
The exposure PHP2Shell revealed is wider than one patch
If a PHP release caught you unprepared, ask what else on the server is waiting for someone to notice.
A security baseline you can read
TLS 1.0 and 1.1 off, SMBv1 off, request filtering, folder permissions, the guest account, account lockout: applied at build, re-checked every hour, repaired on request.
Drift detected, not discovered
ServerMaid knows how the server was built and notices what moved away from it, with the reason and the fix. PHP versions are one item on that list.
Remote Desktop closed to the world
Locked to your addresses with a safety timer, so a stolen password from somewhere else is not a way into your server.
Backups proven by a restore
If the worst happens anyway, you want a backup that has been restored before, not one that has only ever been written.
Questions about PHP2Shell on Windows Server
What is PHP2Shell?
The name given to two flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, fixed by the PHP project on 21 October 2026. Both let an attacker run code on the server without a password and without any vulnerable application, on any PHP that serves web requests.
Which PHP versions are safe?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and anything newer within each line. PHP 8.1 and older have no fixed release; websites on them need to move to a supported line.
Is php-cgi on IIS affected?
Yes. The PHP project lists php-cgi among the affected ways of running PHP, alongside PHP-FPM, Apache mod_php, FrankenPHP and LiteSpeed. A Windows Server running PHP under IIS FastCGI is exposed until its PHP is updated.
Does ServerMaid patch PHP2Shell automatically?
Yes, from ServerMaid 1.3.47 (22 October 2026). The hourly scan compares every PHP line it installed with the official release list, installs a security release in place, restarts the PHP worker processes and clears the alert, with nobody logged on. A licence in date is required, as for every change ServerMaid makes; a lapsed licence still shows the alert.
Is replacing the PHP files enough?
No. IIS keeps the php-cgi.exe worker processes it has already started, so an old, vulnerable PHP keeps serving requests after the files are replaced until the workers recycle or IIS is restarted. ServerMaid stops the old workers as part of the update.
My server already has ServerMaid. What do I need to do?
Install the ServerMaid update when the banner offers it, or open Health & Security (Repair & Security before 1.3.48) and press Fix on the PHP row. From 1.3.47 onwards there is nothing to do: the hourly scan handles PHP security releases for you.
Will ServerMaid move my websites to a new PHP line by itself?
No. It installs security releases within the line you chose (8.4 stays 8.4). Moving a website to another line changes how its code runs, so that stays your decision, one website at a time, with the old line still there to go back to.
The next PHP flaw is coming. Be the server that patches itself.
ServerMaid, the automated Windows web server engineer. Single servers from £99 £49.50 for twelve months; Agency licences for 3, 6 or 12 servers.