PHP2Shell: Why Broadcasters Need to Patch Now

Most people in radio don’t think of PHP as part of the air chain. It’s the language behind WordPress and a lot of old web panels. But it also runs inside some of the gear in our racks. This week two bugs turned up in PHP’s core, and together they’re called PHP2Shell. If anything you run serves a PHP page, this is one to deal with now, not at the next maintenance window.

What PHP2Shell is

PHP2Shell is two remote code execution bugs in PHP itself, not in any one app built on it. The PHP project announced patches on October 20 and shipped them on October 21. The technical details were supposed to come out on the 22nd, but they leaked early, CVE numbers and all. Telos Alliance rates both bugs Critical, CVSS 9.2.

• CVE-2026-109619 is a use-after-free in PHP’s session upload-progress feature. While a file uploads, PHP keeps pointers into the session data so it can report progress. If the session gets rebuilt during the upload, those pointers still aim at memory that has already been freed.
• CVE-2026-109618 is in how PHP handles running out of memory. When a request hits its memory limit, PHP jumps straight out of the request and skips its normal cleanup. Shutdown code can then read memory nobody initialized and act on whatever is in it.

Either way, the attacker ends up running commands on the server with the web server’s privileges. They don’t need a login.

Why so much is exposed

What makes this bad is the default configuration. Upload progress tracking (session.upload_progress.enabled) is on by default, and PHP runs it before your own code ever sees the request. That means any PHP endpoint that accepts a form upload can be a way in, even one that ignores uploads. Akamai says every version from PHP 5 onward is affected.

How the attack works

I’m keeping this at a high level. The short version:

1. The attacker sends a crafted file upload and pauses partway through, so PHP records progress, then rebuilds the session and frees the memory it was pointing at.
2. They fill that freed memory with fake data hidden in ordinary-looking form fields. This is called a heap spray.
3. The next progress update writes through the stale pointer, and PHP ends up calling a function the attacker chose, such as one that runs a shell command.

The out-of-memory bug works the same way. The attacker pre-loads memory with fake data and then pushes the request past its memory limit.

There is one hurdle. The exploit needs a memory offset that depends on the exact PHP build, so an attacker has to leak it or work it out from a known distro package. Embedded appliances that all ship the same firmware make that easy. As of Akamai’s write-up, nobody had seen it exploited in the wild. With the details already public, I wouldn’t count on that lasting.

The broadcast gear that’s affected

Telos Alliance has a disclosure page up. As of its October 22 update, it lists:

Product	Affected	Fix
Pathfinder Core Pro	1.10.13 and earlier	Release candidate 1.10.14
Zephyr Connect SE	1.1.11 and earlier	Patch in progress
Altus SE	2.2.3 and earlier	Patch in progress

Telos says the list may change. Until a fix ships, its only advice is to make sure network security limits who can reach the device.

Think about what those boxes do. Pathfinder controls your routing. Zephyr Connect and Altus carry your codec and remote audio. An attacker inside one of them sits right in your air chain. And even if you don’t run Telos gear, your station website, streaming panel or some vendor’s web UI is very likely PHP.

What to do now

• Take inventory. Find everything that serves PHP: websites, CMS hosts, stream and automation web panels, and appliances. Ask your vendors directly whether their products ship PHP.
• Patch PHP. Judging by Akamai’s detection queries, the fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older gets no fix, so plan the upgrade.
• Update Pathfinder Core Pro to 1.10.14. Watch the Telos page for the Zephyr Connect SE and Altus SE fixes.
• Get management interfaces off the open network. Control-plane gear belongs on its own VLAN, reachable over VPN, and never on the public internet or the office LAN. This is the same airchain hygiene from my post on the FCC cybersecurity rules.
• Harden where you can. On servers where you control php.ini, setting session.upload_progress.enabled = Off closes off the upload-progress path while you wait on patches. That’s my suggestion, not something either source recommends. Test it first, because some upload progress bars depend on it.

Patching a web server takes minutes. Rebuilding a routing core after someone has been inside it takes much longer. Patch now.