PHP: critical security vulnerabilities CVE-2026-109618 und CVE-2026-109619

eagle61

The news regarding CVE-2026-109618 and CVE-2026-109619 sounds alarming. pfSense uses PHP as the primary language for its webConfigurator GUI, backend scripts, and administrative tools.

to what extent is the firewall vulnerable to these critical security vulnerabilities?
how soon will the patches for pfSense — expected at 14:00 GMT — be available?

slu

@eagle61 maybe an issue, but your pfSense web interface is internal only, or?

PS 0

@slu Yes that is an important thing to make sure. Block accesss to your pfsense from 'web'. At least until there is a patch.

eagle61

Yes, the web interface is only accessible from within the local network. However, in a larger setup, potentially infected devices designed to exploit these vulnerabilities could gain access to the LAN.

I run a Nextcloud server on a VLAN, which I have already isolated from the internet using firewall rules. Selected external users can now only access Nextcloud via a WireGuard VPN.

However, all of this still carries a certain residual risk.

In Germany, for example, the University of Freiburg has therefore already completely disconnected its central servers that use PHP from the network.

mcury

@eagle61 Block management access from all VLANs except MGMT, as it should be. No need to disconnect anything.

eagle61

The VLANs have had no access to pfSense right from the start. Nextcloud was cut off from direct access via the internet because PHP is also used on its server.

matthewfearnley

This sounds serious. Will Netgate be ready to provide a quick solution like a patch, or package upgrade, or something else?

At this time we don't know the exact nature of the vulnerability, but https://github.com/syhunt/php2shell-protection/tree/main suggests setting session.upload_progress.enabled = Off in php.ini (/etc/rc.php_ini_setup), and restarting PHP-FPM.

Or more severely/securely, disabling multipart posts in Nginx.
I don't know if this will break anything.

I also had a quick try at disabling multipart posts in Nginx. I could log in OK, but it broke some pages like Diagnostics->Command Prompt - perhaps pages with a file upload button.

stephenw10

@eagle61 said in PHP: critical security vulnerabilities CVE-2026-109618 und CVE-2026-109619:

how soon will the patches for pfSense — expected at 14:00 GMT — be available?

As soon as possible.

eagle61

@matthewfearnley said in PHP: critical security vulnerabilities CVE-2026-109618 und CVE-2026-109619:

but https://github.com/syhunt/php2shell-protection/tree/main suggests setting session.upload_progress.enabled = Off in php.ini (/etc/rc.php_ini_setup), and restarting PHP-FPM.

But Heise Online wrotes: "Auch die angebliche Schutzmaßnahme, session.upload_progress.enabled = 0, ist nach unserem Kenntnisstand unwirksam." (english: To the best of our knowledge, the alleged security measure, session.upload_progress.enabled = 0, is also ineffective.)

stephenw10

And just to be absolutely clear (in case is wasn't already) you should never open the webgui to the internet directly. There are numerous other ways to access pfSense remotely if you have to and all are far better!

eagle61

The patch is available: Security advisory: Critical remote code execution vulnerabilities, update now

jimp

Ideally your GUI shouldn't be accessible to any potential source of untrusted clients. Even on a small single subnet network it's a good idea to hardcode your management host(s) and restrict the GUI to them. It's not as good as a full management subnet, but it's better than nothing (defense in depth and all).

The primary concern will be Captive Portal instances as those are intended to be open to untrusted clients.

We'll have updates out as soon as feasible but if there are viable mitigations we can put in the Captive Portal config, we can distribute a patch for those as well. But there is still way too much conflicting information going around and no proof yet.

slu

@jimp said in PHP: critical security vulnerabilities CVE-2026-109618 und CVE-2026-109619:

The primary concern will be Captive Portal instances as those are intended to be open to untrusted clients.

I forget the captive portal, not good, I hope it will be clearer in the next hours.

slu

@jimp we can fix this with pkg upgrade?

Installed packages to be UPGRADED:
	ca_root_nss: 3.124 -> 3.131.1 [pfSense]
	pfSense-repoc: 20261014.155656 -> 20261020.185334 [pfSense]
	php85: 8.5.7 -> 8.5.12 [pfSense]
	php85-bcmath: 8.5.7 -> 8.5.12 [pfSense]
	php85-bz2: 8.5.7 -> 8.5.12 [pfSense]
	php85-ctype: 8.5.7 -> 8.5.12 [pfSense]
	php85-curl: 8.5.7 -> 8.5.12 [pfSense]
	php85-dom: 8.5.7 -> 8.5.12 [pfSense]
	php85-filter: 8.5.7 -> 8.5.12 [pfSense]
	php85-ftp: 8.5.7 -> 8.5.12 [pfSense]
	php85-gettext: 8.5.7 -> 8.5.12 [pfSense]
	php85-gmp: 8.5.7 -> 8.5.12 [pfSense]
	php85-intl: 8.5.7 -> 8.5.12 [pfSense]
	php85-ldap: 8.5.7 -> 8.5.12 [pfSense]
	php85-mbstring: 8.5.7 -> 8.5.12 [pfSense]
	php85-pcntl: 8.5.7 -> 8.5.12 [pfSense]
	php85-pdo: 8.5.7 -> 8.5.12 [pfSense]
	php85-pdo_sqlite: 8.5.7 -> 8.5.12 [pfSense]
	php85-posix: 8.5.7 -> 8.5.12 [pfSense]
	php85-readline: 8.5.7 -> 8.5.12 [pfSense]
	php85-session: 8.5.7 -> 8.5.12 [pfSense]
	php85-shmop: 8.5.7 -> 8.5.12 [pfSense]
	php85-simplexml: 8.5.7 -> 8.5.12 [pfSense]
	php85-sockets: 8.5.7 -> 8.5.12 [pfSense]
	php85-sqlite3: 8.5.7 -> 8.5.12 [pfSense]
	php85-sysvmsg: 8.5.7 -> 8.5.12 [pfSense]
	php85-sysvsem: 8.5.7 -> 8.5.12 [pfSense]
	php85-sysvshm: 8.5.7 -> 8.5.12 [pfSense]
	php85-tokenizer: 8.5.7 -> 8.5.12 [pfSense]
	php85-xml: 8.5.7 -> 8.5.12 [pfSense]
	php85-xmlreader: 8.5.7 -> 8.5.12 [pfSense]
	php85-xmlwriter: 8.5.7 -> 8.5.12 [pfSense]
	php85-zlib: 8.5.7 -> 8.5.12 [pfSense]

Number of packages to be upgraded: 33

...and the new ca_root_nss is also there!

jimp

@slu Packages are still building for various versions, but the ideal path will be:

# pfSense-upgrade -c && \
  pkg upgrade -y && \
  pkg upgrade -fy pfSense-pkg-WireGuard && \
  /etc/rc.php-fpm_restart && \
  /etc/rc.restart_webgui && \
  /etc/rc.captiveportal_configure

Or (better):

# pfSense-upgrade -c && \
  pkg upgrade -y && \
  pkg upgrade -fy pfSense-pkg-WireGuard && \
  /etc/rc.reboot

slu

@jimp ok, thank you.
If the package available, it's safe to update, right?

jimp

@slu said in PHP: critical security vulnerabilities CVE-2026-109618 und CVE-2026-109619:

@jimp ok, thank you.
If the package available, it's safe to update, right?

It should be, yes. Though as usual, best to test it in some way if you can before running that everywhere.

slu

php --version
PHP 8.5.7 (cli) (built: Aug  3 2026 17:26:44) (NTS)

After upgrade and reboot:

php --version
PHP 8.5.12 (cli) (built: Oct 21 2026 15:12:29) (NTS)

Thank you Netgate team!

FireOdo

@jimp said in PHP: critical security vulnerabilities CVE-2026-109618 und CVE-2026-109619:

It should be, yes. Though as usual, best to test it in some way if you can before running that everywhere.

Update done. Here 2.9.0 CE until now no flaws seen ... Thanks for the rapid mitigation!
PS. I used this command:

pfSense-upgrade -c; pkg upgrade -y; /etc/rc.php-fpm_restart; /etc/rc.restart_webgui;

because I dont use captive-portal.

PPS. Big Update on my Lab-Machine with pfsense+ 26.07 without any flaws! (unbound, pfsense-repoc, strongswan, PHP etc.) (Update via console/ssh)

johnpoz

hmm not seeing this available on 26.07

Installed packages to be UPGRADED:
        ca_root_nss: 3.124 -> 3.131.1 [pfSense]
        pfSense-repoc: 20260919.051732 -> 20261020.185334 [pfSense]
        strongswan: 6.1.0_1 -> 6.1.0_2 [pfSense]

FireOdo

@johnpoz said in PHP: critical security vulnerabilities CVE-2026-109618 und CVE-2026-109619:

hmm not seeing this available on 26.07

I guess you have to be a little bit patient ...

jimp

@johnpoz said in PHP: critical security vulnerabilities CVE-2026-109618 und CVE-2026-109619:

hmm not seeing this available on 26.07

Installed packages to be UPGRADED:
        ca_root_nss: 3.124 -> 3.131.1 [pfSense]
        pfSense-repoc: 20260919.051732 -> 20261020.185334 [pfSense]
        strongswan: 6.1.0_1 -> 6.1.0_2 [pfSense]

It's still building, we haven't actually announced that it's available for anyone yet. :-)

jimp

We'll almost certainly have a more formal announcement coming, but all of the updated PHP packages should be there for Plus 26.07, Plus 26.03.1, CE 2.9.0, and CE 2.8.1.

Plus 26.07, Plus 26.03.1, and CE 2.9.0 should now have PHP 8.5.12
CE 2.8.1 should now have PHP 8.3.36

Use one of the following command sets from an SSH or console shell prompt to upgrade PHP and other packages to the latest available versions:

Ideal - Update and reboot (will also catch other recent update/restart things like strongSwan, unbound, miniupnpd, etc)

# pfSense-upgrade -c && \
  pkg upgrade -y && \
  pkg upgrade -fy pfSense-pkg-WireGuard && \
  /etc/rc.reboot

Or update and restart web services with Captive Portal:

# pfSense-upgrade -c && \
  pkg upgrade -y && \
  pkg upgrade -fy pfSense-pkg-WireGuard && \
  /etc/rc.php-fpm_restart && \
  /etc/rc.restart_webgui && \
  /etc/rc.captiveportal_configure

Or update and restart just the GUI (No Captive Portal):

# pfSense-upgrade -c && \
  pkg upgrade -y && \
  pkg upgrade -fy pfSense-pkg-WireGuard && \
  /etc/rc.php-fpm_restart && \
  /etc/rc.restart_webgui

As the packages are now in the repository, anyone doing a fresh install/reinstall or upgrading from an older version will automatically get the updated PHP packages and will not require manual intervention.

EDIT: There is also a new build of the WireGuard package out that should come in with this update automatically. However, if someone manually updated PHP before that was out or if they updated WireGuard using the GUI package manager before updating PHP, they may need to manually reinstall WireGuard to fix errors attempting to start/restart tunnels:

# pkg upgrade -fy pfSense-pkg-WireGuard

johnpoz

@jimp yeah updated

[26.07-RELEASE][admin@sg4860.home.arpa]/root: php -v
PHP 8.5.12 (cli) (built: Oct 21 2026 15:31:59) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.5.12, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.12, Copyright (c), by Zend Technologies
[26.07-RELEASE][admin@sg4860.home.arpa]/root:

Wanted to also stress - to be honest if your web gui is exposed to anything other than your administration vlan/pc your doing it wrong ;)

slu

@johnpoz said in PHP: critical security vulnerabilities CVE-2026-109618 und CVE-2026-109619:

Wanted to also stress - to be honest if your web gui is exposed to anything other than your administration vlan/pc your doing it wrong ;)

I will agree, but than...

@jimp said in PHP: critical security vulnerabilities CVE-2026-109618 und CVE-2026-109619:

The primary concern will be Captive Portal instances as those are intended to be open to untrusted clients.

...don't saw that coming.

BlockMaxxer

On pfSense CE 2.9.0-RELEASE, with WireGuard package 0.2.13_4, WireGuard was enabled but the service wasn’t running after the PHP update to 8.5.12.

Starting it produced:

ld-elf.so.1: /usr/local/lib/php/20250925/filter.so:
Undefined symbol "_safe_femalloc"

Diagnosis:

/usr/local/bin/php reported 8.5.12.
/usr/local/bin/php_wg -n -v still reported 8.5.7.
WireGuard’s service script explicitly launches php_wg.
The package installer creates php_wg as a hard link to php. That link apparently remained attached to the old executable after the update.

The following restored it on my system:

cp -p /usr/local/bin/php_wg /var/tmp/php_wg.before-repair-20261021
ln -f /usr/local/bin/php /usr/local/bin/php_wg
service wireguardd start

Afterward, both split and full tunnels completed handshakes, DNS worked, and internet access worked through the full tunnel.

Could the PHP update/package hooks refresh WireGuard’s php_wg hard link automatically? The stale executable appears to be the immediate cause; I haven’t established which update step left it behind.

I originally ran pfSense-upgrade -c && pkg upgrade -y && /etc/rc.reboot

slu

@jimp I upgraded now two CE and one 26.07 boxes.

All three don't start the WireGuard service and it was not possible to start it manual.
Reinstall the WireGuard package fix this issue, I don't know if that's important.

Edit: @BlockMaxxer found it out, thank you!

Bob.Dig

@slu Ouch, that is bad. I see it too after rebooting 26.07. Now there is a new WireGuard version. :)

johnpoz

I didn't do a full reboot of pfsense, but I did the update and my wireguard was up, and did a restart of the service and it restarted.

I wasn't going to do a restart of pfsense for this - my gui is only exposed to my PC.

but yeah checked and php_wg -v was still showing 8.57, did your fix @BlockMaxxer and show wireguard back up and now showing

[26.07-RELEASE][admin@sg4860.home.arpa]/usr/local/bin: ./php_wg -v
PHP 8.5.12 (cli) (built: Oct 21 2026 15:31:59) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.5.12, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.12, Copyright (c), by Zend Technologies
[26.07-RELEASE][admin@sg4860.home.arpa]/usr/local/bin:

keyser

@slu Ouch.. that requires an updated Wireguard package as well I assume to fix in the same "update session"?
We will need this fixed before rolling the update on wireguard based remote sites.

jimp

@keyser Good news, the updated package is now live.

Just make sure to update everything at the same time.

If someone updates WireGuard using the GUI but then updates PHP after that, they'll still need to reinstall WireGuard manually (either using the CLI or GUI) after.

elvisimprsntr

Once again, what an amazing job from the entire Netgate team.

I had previously patched ca_root_nss early this morning after pkg_check.php script sent me a Pushover notification at midnight.

I just had to upgrade PHP, then restart PHP-FPM and GUI

Looks like Freshports team is already working on a Tailscale pkg update.

Bob.Dig

@elvisimprsntr What is not amazing though is this update-process...

sgw

Another "same here" from me: patched PHP via:

# pfSense-upgrade -c && pkg upgrade -y && /etc/rc.reboot

After that no wireguard as others mentioned, the upgrade to package WireGuard-0.2.13_5 fixed that.

Thanks all!

jimp

@Bob.Dig said in PHP: critical security vulnerabilities CVE-2026-109618 und CVE-2026-109619:

@elvisimprsntr What is not amazing though is this update-process...

We're working on making that smoother and integrating it into the GUI update process.

It's part of moving things to pkgbase, but the new update method likely won't be fully ready until after the next release.

stephenw10

The pkg version was just bumped now so if you ran that command before that it would not have been reinstalled. After the bump it should be reinstalled as part of that command and not need anything further,

Bob.Dig

@stephenw10 I got it.
~~Now I see high CPU usage with old Suricata on a WG-Tunnel. WireGuard probably didn't changed, so it is the php- update? It is a very weak VPS though.~~
Gone.

keyser

@stephenw10 said in PHP: critical security vulnerabilities CVE-2026-109618 und CVE-2026-109619:

The pkg version was just bumped now so if you ran that command before that it would not have been reinstalled. After the bump it should be reinstalled as part of that command and not need anything further,

I admire the speed of fixing this and trusting your product enough to risking the "pave as you go" strategy that is currently being used. Hopefully the integrated pkg update feature that is coming will prevent the need for something like this in the future.

sgw

I didn't look close before, but it seemed there were around 10-15 packages pulled, right?
What was that?

I was on 26.07 before and no packages to be upgraded were shown in the GUI (I check that every other day or so).

elvisimprsntr

This might be a textbook case for an after action review (AAR) for the entire internet.