Critical PHP vulnerability (php2shell): if you expose PHP through a tunnel, update now

What was disclosed

On 21 October 2026 the PHP project published a security advisory for two vulnerabilities in the language core: CVE-2026-109618 and CVE-2026-109619, both scored 9.2 (CVSS v4.0). Vendors are calling the pair php2shell.

Both allow remote code execution without authentication, running with the privileges of the web worker. In short: an attacker does not need a login, a password or a valid session — reaching your PHP is enough.

Every PHP version from 5.4 through 8.5.11 is affected. The fixes are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older receive no fix from the project.

Why this matters if you use SuperDMZ

We need to be direct about this, because it is the part that concerns us. A tunnel does not create the vulnerability — it was already in your PHP. What the tunnel does is end the obscurity that was protecting that machine. An application that used to answer only on your LAN now answers on a public address, and automated scanning finds public addresses within minutes.

Today 141 of the 165 active tunnels on the platform are in public mode — 55 of 67 HTTP tunnels and 86 of 98 TCP tunnels. That is a legitimate choice and many people want exactly that. It is also the reason this notice exists.

How to check what you are running

php -v

One important caveat that most notices leave out: on Debian, Ubuntu and derivatives, the version number does not change when the distribution applies the patch. Our own web server reports PHP 8.5.4 and is already patched, because the fix came in the package revision (8.5.4-0ubuntu1.5), not in a new PHP release. So on those systems, do not judge by php -v. Ask the package manager instead:

apt list --upgradable | grep php
apt-get changelog php8.3-common | head

If the changelog mentions CVE-2026-109618, that package is the fix. On Windows, macOS, Docker images or a PHP compiled from source, the version number is the right signal — compare it against the four fixed releases above.

If you cannot update today

Here is something we can offer that a generic advisory cannot: switch your tunnel to authenticated mode. In the panel, on the tunnel, change the access mode from public to authenticated. The endpoint then requires a key before any traffic reaches your machine, which takes your PHP out of reach of untargeted scanning while you schedule the update.

It is a temporary measure, not a fix. The flaw stays on your machine, and anyone who holds the key still reaches it. But it buys you the window.

What we did on our side

Our own infrastructure was already affected and has been updated:

• SuperDMZ panel — PHP updated and the service restarted on 21 October.
• Web server (sites and tools) — updated on the same day.
• Tunnel nodes — not affected: they run Go, with no PHP.
• Mail server — container image replaced with the patched PHP build.

We also added a daily check to our own operations monitoring that reads the official vulnerability registry and the security channel of every distribution we run, so that the next case does not depend on someone noticing an email. This one we learned the hard way: we found out about php2shell because a supplier wrote to us.

Official sources

Do not take our word for the technical details — and do not click links in emails about security. Type the address yourself:

• php.net/archive/2026.php — the project's own advisory and the release announcements.
• nvd.nist.gov — search for CVE-2026-109618 and CVE-2026-109619.

If you have a question about your specific setup, reply through the panel's support channel. We will not ask you for passwords or send you a link to click.