What PHP2Shell Is
PHP2Shell is the name given to two vulnerabilities in the PHP language runtime, disclosed together on 21 October 2026. The PHP project describes them in its security release notes as remote code execution flaws that can be triggered without authentication, and rates both 9.2 under CVSS version 4. They were reported by researchers from Calif, Wiz, OpenAI and Quarkslab.
9.2
CVSS v4 score for each flaw, rated critical by the PHP project.
1
unauthenticated request is enough to reach the vulnerable code.
5.4
the oldest PHP release researchers believe is affected.
The timeline was compressed. Details leaked on 20 October, ahead of the planned disclosure. Fixed releases went out at 14:00 UTC on 21 October, which was 1am on 22 October in Sydney and Melbourne. ELLIO, which runs sensor networks, recorded the first exploit shaped request at 08:36 UTC on 21 October, more than five hours before the fix was public. Cloudflare reported attack traffic against its customers the same day, and by the early hours of 22 October ELLIO had seen the same route used to drop a botnet binary onto servers.
| Branch | Fixed release | Status |
|---|---|---|
| PHP 8.5 | 8.5.12 | Supported, update now |
| PHP 8.4 | 8.4.27 | Supported, update now |
| PHP 8.3 | 8.3.36 | Supported, update now |
| PHP 8.2 | 8.2.35 | Supported, update now |
| PHP 8.1, 8.0, 7.4 | None from php.net | Minimal source backports only, or your distribution or LTS vendor |
| PHP 7.3 and older | None | Upgrade or take offline |
How the Two Flaws Work
Both bugs live in the gap between PHP stopping a request abruptly and PHP cleaning up after it.
When a request hits a fatal condition, the classic one being memory_limit, PHP does not unwind politely. It performs what the engine calls a bailout: a longjmp() straight out of whatever it was doing, back to the request's top level. That is fast, and for decades it was considered safe. The researchers showed it is not always safe, because a bailout can land after PHP has published a pointer or claimed a slot somewhere, but before the bookkeeping that makes that pointer valid has run.
CVE-2026-109618: corruption on out of memory
In the PHP project's words, out of memory handling "can interrupt PHP while internal request data is only partially initialized", and request cleanup "may then treat the invalid data as valid". An attacker who can push a request to its memory limit at the right moment leaves half built structures behind, and the cleanup code reads them.
CVE-2026-109619: stale global state
Here, request owned state "can survive after its backing memory has been freed", and "a later request handled by the same worker may use that stale state before normal initialization resets it". In other words, one request poisons the worker, and the attacker's next request on that worker uses the poisoned state.
Imperva's analysis describes five techniques built on these primitives: use after free conditions in the session decoder and session module data, a stale class cache pointer in OPcache shared memory that can redirect a file operation, an oversized session ID that leaks around 67 KB of process memory back in the Set-Cookie: PHPSESSID header, and a use after free in fatal error backtraces on PHP 8.5. Turning a crash into reliable code execution is the hard part, because the attacker has to get crafted data into freed memory on the same worker before it is reused. That is why the attack complexity is rated high, and also why it matters that the attempts are already automated.
Why the process model matters
Both flaws depend on a worker serving more than one request. That describes Apache prefork with mod_php, where each Apache child is a long lived PHP worker, and PHP-FPM pools, where workers handle many requests before recycling. The PHP project names mod_php as the highest risk. php-cgi, FrankenPHP and LiteSpeed are also listed as affected. Code that runs only from the command line, such as cron jobs, is not reachable by a web request.
Why No Login Is Needed
Most web application flaws need the attacker to reach a vulnerable page, often after logging in. PHP2Shell does not, because three of the five techniques use the session upload progress feature, session.upload_progress.enabled. It is on by default.
When upload progress is enabled, PHP watches every incoming multipart/form-data body for a field named after session.upload_progress.name, which defaults to PHP_SESSION_UPLOAD_PROGRESS, and writes progress into the session while it is still parsing the body. That happens inside the runtime, before your application has run a single line. So a login page, a provisioning endpoint or a script that only prints a static message can all be used to drive session handling and memory use. The requests ELLIO captured were exactly that shape: multipart POSTs carrying the progress field, hundreds of empty file fields, deeply nested field names, and bodies from a few hundred kilobytes up to 37 MB.
Code execution means the web server's account
Successful exploitation runs code as whichever user the PHP worker runs as. On a dedicated web server that limits the damage. On a phone system it often does not, as the next section explains.
Why Phone Systems Are an Obvious Target
A PBX is an unusually rich target, and the PHP admin panel is usually its front door.
- The web user is the phone user. On a standard FreePBX build, Apache runs as the same
asteriskaccount that runs the telephony engine. Code running as the web server can read Asterisk's configuration and everything it can reach. - Recordings and voicemail. Call recordings and voicemail audio sit on the same disk, often for years. For a clinic, law firm or agency that is sensitive personal information under the Privacy Act.
- Call records. CDRs show who your business calls, when and for how long. That is a map of your customers and suppliers.
- SIP trunk credentials. The username and password your PBX uses to place calls through your carrier. With those, an attacker can place calls on your account from anywhere.
- Toll fraud. The usual way a hacked PBX is monetised is calls to premium and international numbers, often over a weekend. The bill arrives later and is usually yours to pay.
- A foothold. A PBX sits on the office network, often with a route to the internet for remote extensions and provisioning. It is a quiet place to stay.
The admin panels are also more exposed than most owners realise. Remote handset provisioning, user portals for voicemail and recordings, and installers who want to log in from home all push the web interface onto the open internet.
Which Phone Platforms Run PHP
The Dutch National Cyber Security Centre keeps a public PHP2Shell software tracker. This is where the common phone platforms stood when we checked on 22 October. "Investigation" means the product is confirmed to use PHP but the vendor has not yet said whether these flaws can be reached. Check the tracker and your vendor before relying on any line here.
| Platform | PHP | NCSC-NL status, 22 Oct 2026 |
|---|---|---|
| FreePBX 17 | PHP 8.2 tested platform | Investigation |
| PBXact 17 (Sangoma, commercial FreePBX) | PHP 8.2 | Investigation |
| Issabel 5 | PHP 7.4 | Investigation |
| FusionPBX | PHP-FPM, version depends on install | Vulnerable when run on an affected PHP |
| ASTPP v7 (VoIP billing) | PHP 8.2 | Vulnerable |
| 3CX | No public indication of PHP | Not listed |
Two rows deserve a comment. Issabel 5 ships PHP 7.4, which has had no official PHP release for some time, so there will be no 7.4.x update to install; the options are a distribution or vendor backport, the PHP project's minimal source backport, or moving off it. And older FreePBX releases such as 15 and 16 commonly sit on PHP versions that are also past end of life. If you inherited a PBX that has not been upgraded in a few years, assume it is in that group until you have checked.
Where 3CX Fits
We want to be precise here, because there is plenty of loose talk about 3CX. From everything published, 3CX on Linux runs its own Nginx web server and its own PostgreSQL database, and nothing public suggests the 3CX management console depends on PHP. It does not appear on the NCSC-NL tracker. On that evidence PHP2Shell is not a 3CX vulnerability, and you should check 3CX's own security notices rather than take anyone's word for it, including ours.
That does not mean a self-hosted 3CX system is outside the blast radius. Three common situations put it inside:
- Shared boxes. 3CX on a VPS or office server that also runs a website, a WordPress install, a call recording viewer, a wallboard or a monitoring panel written in PHP.
- Shared networks. A PHP based provisioning server, CRM or booking system on the same network segment as the PBX, with nothing between them.
- Shared people. The same administrator credentials used on the PHP apps and the PBX console, so data stolen from one opens the other.
The wider point applies to every self-hosted phone system. When you run it yourself, you are the security team for the operating system, the web server, the database, the runtime and every other package on the box, not just the phone software. PHP2Shell is one bad week. The 3CX desktop app supply chain compromise in 2023 was another. Our 3CX migration guide covers the move if you are weighing it up.
What to Do Today
In order of priority. If you look after phone systems for clients, do this for every one of them.
- Find every PHP that answers web requests. On each box run
php -v, but remember the command line can differ from the web runtime. Check the SAPI that actually serves requests: the FPM service version, orapachectl -Mforphp_module. Include anything sharing the host or network with the PBX. - Update. Install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's patched package. Distributions and LTS vendors had fixes before the public release, so
apt updateordnf updateshould offer them. Help Net Security notes that the volunteer run Remi repository had no update at the time of its report. - Restart every worker. Restart PHP-FPM pools and Apache fully. A patched package does nothing for workers already running the old code, and CVE-2026-109619 lives in long lived workers.
- If you cannot patch yet, apply the interim settings the PHP project published, in
php.inior the pool or Apache config, never throughini_set()or.user.ini, then restart:session.upload_progress.enabled = 0,memory_limit = -1with a sensiblepost_max_size, and on PHP 8.5fatal_error_backtraces = 0. Replace the memory limit with a container or cgroup limit, and do not useRLIMIT_ASorRLIMIT_DATA, which can trigger the bug. The PHP project is clear these reduce risk and do not make an install safe. - Take the admin panel off the internet. The FreePBX or FusionPBX GUI and user portals should be reachable only over a VPN or from a short allow list of addresses. Do it today and leave it that way after you patch.
- Limit requests at the edge. Block
multipart/form-dataon endpoints that never take uploads, and cap body size, part count, field count and headers on the ones that do. ELLIO points out that a size cap alone misses bodies that stay underpost_max_size. - If you cannot do any of that, take it offline. That is the UK NCSC's advice for systems that cannot be fixed straight away. Route calls to mobiles in the meantime.
- Assume exposure if it was public and unpatched. Rotate SIP trunk passwords, admin passwords and API keys, set or lower spend limits with your carrier, and turn on international call barring you do not need.
Signs Someone Has Already Tried
| Where to look | What it looks like |
|---|---|
| Web server access logs | Multipart POSTs containing PHP_SESSION_UPLOAD_PROGRESS, boundaries beginning ----p2s, very large bodies, hundreds of empty file fields, deeply nested field names |
| PHP and FPM error logs | Bursts of "Allowed memory size exhausted" errors and worker segfaults from the same addresses |
| Response headers | Unusually large PHPSESSID values in Set-Cookie, a sign of the memory disclosure technique |
| Process list | PHP workers, or the asterisk user, spawning shells, interpreters, curl, wget or unfamiliar binaries |
| File system | New PHP files in web directories, new cron entries, new SSH keys, unfamiliar files in /tmp |
| Call detail records | Calls to international or premium numbers you do not normally call, especially overnight or at weekends, and new extensions or trunks you did not create |
If you find something, do not just patch
Patching closes the door for the next attacker. It does not remove anyone already inside. If any of the signs above show up, take the box off the network, keep the logs, and rebuild from known good media with fresh credentials. Report the incident to the Australian Cyber Security Centre through ReportCyber, and if personal information may have been accessed, assess whether the Notifiable Data Breaches scheme applies.
The Case for Not Being Your Own Patch Team
Nothing about PHP2Shell is a reason to panic about cloud phone systems or a reason to throw out a well run on premises PBX. Plenty of IT providers patched overnight and went back to bed. It is a reminder of the job you take on when the phone system lives on your own server, and of how short the gap now is between a fix being published and attacks starting. Our guide to hosted versus on premise PBX sets out the trade offs fairly.
With Uniden Voice there is no PBX server in your office or on your VPS for you to patch. The platform is ours to run and maintain in Australia, and the only things on your side are the apps and handsets. For what it is worth, unidenvoice.com itself runs on PHP, and it was on the fixed 8.5.12 release when we checked on 22 October. The questions to ask any provider, us included, are the same: who patches the platform, how quickly, and how will you hear about it. Our wider piece on phone system security covers the rest of the list.