Critical PHP vuln: php2shell (CVSSv4 9.2, CVE-2026-109618 / CVE-2026-109619)

[some-random-user]

Hello,

By default, PHP runs as root on OPNsense.

With that in mind, can you please confirm that OPNsense will release a fix for this critical vulnerability in sync with upstream (scheduled for 14:00 UTC today, 21 Oct 2026)?

Thanks in advance!

[dxche]

Adding to this: both CVEs (CVE-2026-109618, CVE-2026-109619) are rated CVSS 9.2 and reported as unauthenticated, so login protection on the GUI won't help. Also worth noting that by default lighttpd binds on every interface address, so the GUI is reachable from all internal VLANs, not only WAN.

Two follow up questions:

Is there any plan for 26.1 installs (still on PHP 8.3.30), or is upgrading to 26.7 the only way to get the fix?
Until the hotfix lands, is restricting Listen Interfaces plus WAN source IPs the recommended mitigation, or is there anything else you'd suggest?

[KantFreeze]

Yeah this seems like a big deal, I hope there is an official comment on it. I just run a home network and don't have the web gui listening on WAN, so hopefully that's enough for now. This is going to be a wild ride with so many different platforms using PHP.

[Patrick M. Hausen]

binds on every interface address, so the GUI is reachable from all internal VLANs, not only WAN

Only if firewall rules explicitly allow that. And there are none in the default configuration. Regardless of socket binding the UI is *not* reachable from WAN or any new VLAN unless the administrator explicitly configures that.

[some-random-user]

And there are none in the default configuration.

In the default configuration, anyone on the LAN network can probably get root on OPNsense. Is this acceptable to you?

The project must ship a PHP update today, and must accelerate work on not running any components of the web UI as root.

[Lucid1010]

https://github.com/eness/php2shell-CVE-2026-109618-CVE-2026-109619-PoC

https://github.com/ikow/php2shell-poc

[meyergru]

The project must ship a PHP update today, and must accelerate work on not running any components of the web UI as root.

...or maybe you should refrain from exposing an administrative interface to the open? Besides, there is the checkbox "Strict Security" - which does not help much (read on!).

Guys, we now live in 2026, not 2010. If you think that this vulnerability is the only one that AI has found, think again: It is only one that has been made public.

FWIW: I am using ~one week in a month just to keep ahead of these things (see this for an example on why running non-root does not really help at all) and to save me some work, I just ordered a Spark DGX to help me do it, because I do not trust cloud AIs to keep my secrets...

[some-random-user]

maybe you should refrain from exposing an administrative interface to the open

Why do you keep moving the goalposts? OPNsense is vulnerable in its default configuration.

[some-random-user]

The patches have dropped:

https://www.php.net/archive/2026.php#2026-10-21-5

[Patrick M. Hausen]

FreeBSD has incorporated them in the HEAD and 2026Q4 ports branches.

[meyergru]

maybe you should refrain from exposing an administrative interface to the open

Why do you keep moving the goalposts? OPNsense is vulnerable in its default configuration.

Which goalposts, exactly? Patrick had already explained that the GUI is not accessible from WAN or newly added VLANs by default. I am referring to a security boundary that already exists.

For a direct attack against the GUI, an attacker first needs network access to it:

a. You have exposed the management interface to an untrusted network. That would be a configuration change you made, not the default configuration.
b. The attacker is on a LAN from which management access is permitted. If your threat model includes attacks from those LAN clients, restricting their access to the administrative interface is your responsibility.

The presence of a PHP vulnerability does not make the packet filter disappear. Assessing whether an attacker can actually reach the vulnerable service is fundamental to assessing exposure and urgency.

The bug needs fixing, I give you that. That does not make the existing security boundary irrelevant, and me pointing that out is not "moving the goalposts."

If anyone is moving the goalposts here, it is you: you are turning a discussion about actual exposure into a blanket demand for an emergency patch. The default configuration blocks direct WAN access. If your urgency instead stems from exposing the GUI to the Internet or to LAN clients you consider potential attackers, then that exposure results from your own failure to restrict administrative access appropriately.

[jensk]

I run a public WLAN with a Captive Portal. Is this done with php, and therefor in danger. Or does that work without?

[NickF]

Hi,

Given that this issue will need to be addressed in OPNsense at some point, is there a plan to incorporate the relevant upstream patches? If so, is there any rough timeline or release target for when that might happen?

If not, what is the process for getting that agreed?

Thanks
Nick

[ou1]

I run a public WLAN with a Captive Portal. Is this done with php, and therefor in danger. Or does that work without?

I would say yes, it is in danger, but luckily the attacker would need to be close to the AP to exploit it, it's not vulnerable to bots on the internet trying all public IPs.

[some-random-user]

I run a public WLAN with a Captive Portal. Is this done with php, and therefor in danger.

Yes, it is vulnerable, unlike what @meyergru would apparently like us to think. If you can reach any part of the web UI, you can reach php.