PHP2Shell in Plain English
PHP is the programming language that runs a large share of the web. When a page loads, PHP builds it on the server. PHP2Shell is a pair of mistakes deep inside PHP itself, officially CVE-2026-109618 and CVE-2026-109619, that let a stranger send one carefully built request and, with some effort, get the server to run their code. No password is needed, and the request does not have to hit any particular page.
The PHP project rates both flaws 9.2 out of 10 and released fixes on 21 October 2026, Australian time just after midnight on the 22nd. Details had leaked the day before, and sensor networks saw exploit shaped requests from 21 October onwards, including some that tried to install botnet software. Because the problem is in PHP rather than in any one product, updating the product alone does not fix it. PHP itself has to be updated, and the server restarted.
2
critical flaws in the PHP runtime, both fixed on 21 October 2026.
0
passwords an attacker needs to reach the vulnerable code.
Hours
between details leaking and the first attack traffic being recorded.
Does This Apply to Your Business?
Work down this list. The first yes means it is worth a phone call today.
| Your setup | Exposure |
|---|---|
| FreePBX, PBXact, Issabel or FusionPBX, on a server in the office or a virtual server | Check today. These are managed through PHP. The Dutch NCSC tracker lists FusionPBX as vulnerable on an affected PHP, and FreePBX 17, PBXact 17 and Issabel 5 as under investigation. |
| A VoIP billing or reseller platform such as ASTPP | Check today. ASTPP v7 is listed as vulnerable. |
| 3CX that you or your IT provider host | Check what else is on the server. 3CX does not appear to use PHP, but see the note for 3CX customers below. |
| An old phone system nobody has touched in years | Check today, and assume the worst. Older systems often run PHP versions that will never get an official fix. |
| A cloud phone system where the provider runs everything | Ask the provider what they patched and when. There is no server on your side to fix. |
Not sure which one you have? Look at how you log in to change a call menu or listen to a recording. If it is a web page at an address your IT provider gave you, or an address inside your office network, you are self-hosted.
What Is on That Server
It is easy to think of the phone system as a utility, like the lights. To an attacker it is one of the most useful machines in the building.
Your conversations
Call recordings and voicemail, often kept for years. For a practice, firm or agency, that is personal information you are responsible for under the Privacy Act.
Your customer list
Call records show who calls you, who you call, when and for how long. That is a very clean list of your customers and suppliers.
Your phone bill
The server holds the login it uses to make calls through your carrier. Stolen, it can be used to run up international and premium calls on your account, usually over a weekend.
Your network
The phone server sits inside the office network and is rarely watched closely. That makes it a comfortable place for an attacker to stay.
Five Questions for Your IT Person Today
Send these by email so you have the answers in writing. None of them should take long to answer.
- "Which version of PHP is our phone server running, and has it been updated for PHP2Shell?" A good answer names a version: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, or a distribution package with the fix. A worrying answer is "the phone system is up to date", because the phone software and PHP are updated separately.
- "Has everything been restarted since the update?" PHP keeps old code running in memory until it restarts. The answer should be yes, including the web server.
- "Can the admin screen be reached from the internet?" The right answer is that it can only be reached over a VPN or from a short list of approved addresses. If it is open to the world, closing it is the most useful thing that can happen today, patched or not.
- "Have you checked the logs and our call records for anything unusual since 20 October?" Your IT person will know what to look for from the technical section below. You can check the call side yourself: any calls to countries or premium numbers you never ring.
- "What limits are on our calls if someone does get in?" Ask for a spend limit with your carrier and international call barring for any destinations you do not use. They cost nothing and cap the damage.
If your IT provider looks after other businesses
Ask whether they have checked all of their customers' phone servers, not just yours. Providers who manage dozens of PBXs tend to have a script for this already. If they do not, that is useful to know too.
A Note for 3CX Customers
On everything published so far, PHP2Shell is not a flaw in 3CX. 3CX runs its own web server and database, nothing public suggests its admin console depends on PHP, and it does not appear on the Dutch NCSC's list of affected software. Check 3CX's own security notices to be sure.
But a self-hosted 3CX server can still be reached through something else. The usual ways are a website, recording viewer, wallboard or provisioning tool on the same server; a PHP based system such as a CRM or booking tool on the same network with nothing in between; or the same administrator password used across several systems. So the question for your IT person is not just "is 3CX affected?" but "what else runs on that server and that network, and is it patched?"
It is also a fair moment to ask whether you want to keep running the server at all. 3CX's licensing and support terms changed this year, which we covered in what changed at your 3CX renewal, and if you are weighing a move, the 3CX migration guide walks through it.
For Your IT Person: The Technical Detail
Forward this section as it is.
Mechanism. CVE-2026-109618: when a request exceeds memory_limit, PHP bails out with a longjmp(), and in some contexts that leaves request data "only partially initialized", which cleanup then treats as valid. CVE-2026-109619: request owned state "can survive after its backing memory has been freed", and a later request on the same worker uses it before initialisation resets it. Both are CWE-824 and need a worker that serves multiple requests, which is why Apache prefork with mod_php is the highest risk; PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also affected. Imperva describes five exploitation techniques, including session decoder use after free, a stale OPcache class cache pointer, an oversized PHPSESSID leaking around 67 KB of memory, and a fatal error backtrace use after free on 8.5.
Pre-auth reach. Three techniques use session.upload_progress.enabled (default on), which processes multipart/form-data bodies containing PHP_SESSION_UPLOAD_PROGRESS before any application code runs. Every PHP endpoint that accepts a POST is a way in.
| Step | Detail |
|---|---|
| Patch | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, or the distribution package. 8.1, 8.0 and 7.4 have minimal source backports from the PHP project only. Check the web SAPI version, not just php -v. |
| Restart | Every PHP-FPM pool and Apache. Old workers keep old code. |
| Interim (not a fix) | In php.ini, pool or Apache config, not ini_set() or .user.ini: session.upload_progress.enabled = 0; memory_limit = -1 with a cgroup or container memory limit instead; fatal_error_backtraces = 0 on 8.5. Do not use RLIMIT_AS or RLIMIT_DATA. Restart after. |
| Edge | Admin GUI behind VPN or allow list. Block multipart where no uploads are needed; cap body size, parts, fields and headers elsewhere, including requests without a usable Content-Length. |
| Hunt | Multipart POSTs with the progress field and boundaries starting ----p2s; bursts of memory exhausted errors and worker crashes; large PHPSESSID values; PHP or asterisk processes spawning shells or network tools; new PHP files, cron jobs or SSH keys; unusual CDRs. |
| Contain | Rotate SIP trunk, admin and API credentials if the GUI was public and unpatched. If anything in the hunt row turns up, isolate and rebuild rather than patch in place. |
Primary sources: the PHP security release notes and the NCSC-NL software tracker, which is being updated as vendors respond.
If the Answer Is "We Are Not Sure"
Then the safe move is to take the phone server's admin screen off the internet today, and if the server itself cannot be updated quickly, to take it offline and divert your main number to mobiles until it is done. A few hours of calls on mobiles is a much smaller problem than a weekend of fraudulent international calls or a recording archive in someone else's hands.
If there are signs someone got in
Do not simply patch and carry on. Disconnect the server, keep the logs, rebuild it with new passwords, and report it to the Australian Cyber Security Centre through ReportCyber. If recordings or customer details may have been accessed, check whether the Notifiable Data Breaches scheme applies to you.
Where VOCPhone Stands
VOCPhone customers do not run a phone server, so there is nothing on your side to patch for this. We own and operate our own network in Australia, and keeping the platform patched is our job, not yours. Our public website, vocphone.com, runs on PHP like much of the web, and it was on the fixed 8.5.12 release when we checked on 22 October.
None of that means self-hosting is wrong. A well run on premises system with a diligent IT provider is fine, and our guide to hosted versus on premise PBX is honest about when it still makes sense. But if this week has you wondering why you are paying to look after a server for something as basic as answering the phone, it is a reasonable question. Setup and number porting are $0, and your old system keeps working until your numbers have moved.
Frequently Asked Questions
What is PHP2Shell and why does it matter to my phone system?
PHP2Shell is the name for two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619, that the PHP project fixed on 21 October 2026. They can let an attacker run code on a server with one web request and no password. PHP runs the admin screens of many self-hosted phone systems, including FreePBX and systems built on it, Issabel and FusionPBX. If one of those servers is running an unpatched PHP and its admin screen can be reached from the internet, an attacker could get at your call recordings, voicemail, call records and the login your system uses to make calls through your carrier. That last one is how toll fraud happens: large numbers of international or premium calls charged to your account. The fix is to update PHP itself, restart the server and keep the admin screen off the open internet.
Is my 3CX phone system at risk from PHP2Shell?
Based on what has been published as of 22 October 2026, 3CX itself is not affected, because it runs its own web server and database and nothing public suggests it uses PHP. It is not on the Dutch NCSC's list of affected software, and 3CX's own security notices are the place to confirm that. A self-hosted 3CX server can still be put at risk by other software around it: a website, recording viewer or provisioning tool on the same server, a PHP application on the same network with nothing separating them, or administrator passwords reused between systems. Ask your IT provider what else runs on the 3CX server and its network, whether that has been patched, and whether the 3CX admin console can be reached from the internet.
What should I ask my IT provider about PHP2Shell?
Ask five things, ideally by email. First, which version of PHP the phone server runs and whether it has been updated to a fixed release: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later on the same branch, or a distribution package with the fix. Second, whether the server and web server have been restarted since, because old code stays in memory until they are. Third, whether the phone system's admin screen can be reached from the internet, which it should not be except over a VPN or from approved addresses. Fourth, whether they have checked the logs and your call records for anything unusual since 20 October. Fifth, what spend limits and international call barring are in place with your carrier, so the damage is capped if someone does get in.
How do I know if my phone system has been hacked?
The easiest thing for an owner to check is the call records or the carrier bill. Look for calls to countries or premium numbers you never call, calls in the middle of the night or across a weekend, and extensions or users you did not create. Your IT provider can check the technical signs: unusual large web requests mentioning PHP_SESSION_UPLOAD_PROGRESS, bursts of out of memory errors and crashes, unfamiliar files or scheduled jobs on the server, and the phone or web server software starting programs it should not. If anything turns up, the server should be disconnected and rebuilt with new passwords rather than simply patched, the incident reported to the Australian Cyber Security Centre through ReportCyber, and an assessment made under the Notifiable Data Breaches scheme if customer information may have been accessed.
What if my phone server cannot be updated straight away?
Then reduce the exposure until it can. The most useful single step is to take the admin screen off the internet, so it can only be reached over a VPN or from a short list of approved addresses. The PHP project has also published temporary settings that lower the risk, such as turning off session upload progress, which your IT person can apply to the server configuration and then restart, though the project is clear they do not make a server safe. If even that is not possible today, the UK National Cyber Security Centre's advice is to take systems that cannot be fixed offline. For a phone system, that can mean diverting your main number to mobiles for a few hours or days, which is a much smaller cost than a fraud bill or a data breach.
Do cloud phone systems need to worry about PHP2Shell?
With a cloud phone system the provider runs the servers, so there is no phone server or admin panel on your side for an attacker to reach and nothing for you to patch. The provider still has to patch its own platform and websites, and it is perfectly reasonable to ask what they did and when. Many providers' public websites run on PHP, as a large part of the web does, so the question applies to their sites and portals as well as the phone platform. VOCPhone customers do not run a phone server, we operate our own network in Australia, and vocphone.com was on the fixed PHP 8.5.12 release when we checked on 22 October 2026.
