On 22 October 2026 PHP shipped emergency updates for two bugs, CVE-2026-109618 and CVE-2026-109619, nicknamed php2shell. Together they let someone on the internet run commands on your server with a single web request. No password, no account, nothing. If a website runs on PHP, it was most likely affected.
Short version: xTQ PHP is updated to the fixed PHP and has extra protection on top. If you run xTQ PHP, update to the latest build and you're covered.
What happened, in plain words
Every time someone opens a page, PHP reads what the visitor sent: the address, cookies, and anything typed into a form or uploaded. It turns all of that into neat lists before the website's own code even starts.
Researchers found two ways to break PHP right in that moment:
- Make it run out of memory while reading a form. A specially built upload makes PHP choke halfway through, and the mess it leaves behind can be used to take over the server. That's CVE-2026-109618.
- Leave rubbish behind for the next visitor. PHP servers are reused for many visitors in a row. A request that crashes PHP at the right moment can leave pieces of itself in memory, and the next request picks them up. One of the easiest ways in was the upload progress feature, which is switched on by default. That's CVE-2026-109619.
Which PHP versions are safe
| Version | Fixed in |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 and older | No fix. These versions are no longer supported |
If your host or panel shows a lower number than these, ask them to update today.
What I did in xTQ PHP
The first step was the obvious one. xTQ PHP now runs on PHP 8.3.36, the fixed version.
But a patch only fixes the bug we know about. PHP has had bugs like this before and it will have them again, so I built protection into xTQ PHP itself. It sits in front of PHP and doesn't depend on PHP getting it right next time.
Forms get checked before PHP sees them. xTQ PHP looks at every request first. If a form has more fields than PHP is set to accept, is nested absurdly deep, carries a pile of empty file uploads or has broken upload headers, it gets turned away right there. PHP never reads it, so a bug in how PHP reads forms can't be triggered. Normal visitors and normal forms never notice anything.
A crashed request can't leave anything behind. If a request makes PHP fall over, because of a fatal error, running out of memory or taking too long, xTQ PHP throws away that worker's whole memory and starts it fresh before the next visitor. Think of it as wiping the table after every spill instead of hoping the next guest doesn't touch it. That's the exact trick CVE-2026-109619 needs, and it no longer works on xTQ PHP whatever version of PHP is underneath.
Risky features are off by default. Upload progress, the feature behind the easiest attack, is now switched off out of the box. A site that really needs it can turn it back on.
These three are on for everyone who runs xTQ PHP. There's nothing to configure.
Classic PHP and the alternatives, side by side
Most PHP sites run one of two ways. mod_php puts PHP inside the Apache web server. PHP-FPM runs a group of PHP processes behind nginx or Apache. Here's how they compare with xTQ PHP on the things that mattered this week.
| mod_php | PHP-FPM | xTQ PHP | |
|---|---|---|---|
| Forms checked before PHP reads them | No | No | Yes |
| A worker that crashed is wiped clean | No, it carries on | Only if you restart every worker after every single visit | Yes, automatically, and only when it crashed |
| Upload progress, the easiest way in | On by default | On by default | Off by default |
| Settings a request or folder can change | Yes, through .htaccess | Yes, through the web server and .user.ini files | None, settings are fixed when it starts |
| The part that talks to the internet | Written in C | Written in C | Written in Rust |
A few of these need a word of explanation.
Wiping a crashed worker. The official advice for PHP-FPM users who can't update yet is to restart every PHP worker after every visit. That works, but it makes the whole site slower, all the time. xTQ PHP only resets a worker when a request actually crashed it. Normal visits cost nothing extra, and an attack that relies on crashing PHP gets a fresh worker every time.
Settings that can't be changed from outside. Part of the php2shell attack works by changing PHP settings while a request is starting up, through .htaccess files on Apache or through values the web server passes to PHP-FPM. xTQ PHP has no way to do that. Settings are read once when the server starts, and no visitor, file or folder can change them afterwards.
The language of the front door. The code that reads raw requests from the internet is where memory bugs hurt the most. In classic setups that's Apache or nginx plus PHP's own request handling, all written in C. In xTQ PHP everything up to the moment PHP runs your page is Rust, which rules out whole families of memory bugs by design.
What about the newer PHP servers? Tools like FrankenPHP, RoadRunner and Swoole get their speed from a worker mode that keeps your app loaded in memory between visitors. It's fast, but whatever one visit leaves in memory is still there for the next one, so the app has to be written with that in mind. That's the same kind of problem as CVE-2026-109619, just inside your app instead of inside PHP. xTQ PHP keeps PHP's normal rule that every visit starts with a clean app, and gets its speed elsewhere.
None of this makes updating optional. The real fix for php2shell is the patched PHP, and xTQ PHP ships it. The difference is what happens the next time PHP has a bug like this, before the patch exists.
What you should do
If you run xTQ PHP, update to the latest build and restart. That's it.
If you run PHP some other way, update PHP to one of the versions in the table above. Until you can, turning off session.upload_progress.enabled in your PHP settings blocks the easiest way in.
If you're on PHP 8.1 or older, there is no official fix and there won't be one. Moving to a supported version is the only real answer.