PHP2Shell security fix for OPNsense 26.1.x?

[weilander]

Hi Franco,

Thanks for the quick response to the critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619).

I'm currently running OPNsense 26.1.11_10 and haven't upgraded to 26.7 yet due to compatibility considerations with my existing setup. The upgrade is planned, but I can't carry it out immediately.

Will the PHP security fixes also be made available for installations still running 26.1.x, perhaps as a standalone package update or backport?

I understand that older release branches cannot be maintained indefinitely. However, especially with vulnerabilities of this severity, it would be helpful to have a way to apply essential security fixes without having to perform a major version upgrade at short notice.

Thanks for clarifying!

Cheers,
Michael

[nero355]

I'm currently running OPNsense 26.1.11_10 and haven't upgraded to 26.7 yet due to compatibility considerations with my existing setup.

Which ones exactly ?

[weilander]

Which ones exactly ?

Hi nero355,

I've had some rather unpleasant issues with my OPNsense installation in the past, including a FreeBSD pkg version being installed instead of the expected OPNsense version, resulting in segmentation faults and requiring manual repairs.

I've also experienced issues with the Zenarmor repository and recurring WebGUI problems after restarts, apparently related to Zenarmor.

I'm not claiming that these are confirmed incompatibilities with 26.7. However, given those experiences, I'd prefer to prepare and test the major upgrade carefully rather than rush it.

I do intend to upgrade, but I can't do it immediately.

That's why I was asking whether a standalone PHP security fix or backport might be available for 26.1.x in the meantime.

[newsense]

> I'm currently running OPNsense 26.1.11_10

Then worry not, you have far bigger issues than a couple php vulnerabilities

The only way to patch for you on 26.1 is to switch to the BE edition that is based on 26.1 - but that will only take you to next week when 26.10 BE will land

Take a snapshot and do your updates to 26.7.7. There's no better option and no reason to wait for miracles on unsupported versions

[Labber53]

Can you please patch 26.1.x

[nero355]

I've had some rather unpleasant issues with my OPNsense installation in the past, including a FreeBSD pkg version being installed instead of the expected OPNsense version, resulting in segmentation faults and requiring manual repairs.

I've also experienced issues with the Zenarmor repository and recurring WebGUI problems after restarts, apparently related to Zenarmor.

I'm not claiming that these are confirmed incompatibilities with 26.7. However, given those experiences, I'd prefer to prepare and test the major upgrade carefully rather than rush it.

I understand where you are coming from, but AFAIK none of those issues should happen now :
- FreeBSD pkg issues are mainly caused by the wrong repositories being enabled.
- The version of pkg in OPNsense has recently been upgraded.
- ZenArmor is now compatible with version 26.7.x for a long time from what I have seen in their sub-forum.

So in theory there shouldn't be any issues as long as you :
- Make sure you migrate Firewall and NAT Rules in advance.
- Disable Intel CPU Micro Code injection before upgrading to 26.7.x in case you are using it.
- Upgrade your FreeBSD Boot Loader after the first OPNsense 26.7.x upgrade step.
After the last two steps you can then choose to Enable either Early or Late Intel CPU Micro Code injection.
The Late injection option was added in 26.7.x when this bug appeared for people not wanting/knowing how to update their FreeBSD Boot Loader but I suggest to do it anyway!
Easpecially when running in UEFI Boot Mode it's super easy :)


Good luck!

[franco]

26.1.11 was updated to PHP 8.3.36 today.

This is a one time effort.  If you need a supported version use the latest community or business release.

> - FreeBSD pkg issues are mainly caused by the wrong repositories being enabled.

I agree.  Nothing to add here.


Cheers,
Franco

[weilander]

Hi Franco, nero355 and everyone,

Thanks again for your feedback. I wanted to provide an update on how things went.

I decided to proceed with the upgrade from OPNsense 26.1.11_10 to 26.7.7, keeping my existing UFS installation rather than performing a fresh ZFS installation.

The upgrade went smoothly overall. The only issue afterwards was an obsolete php83-pecl-mongodb package, which I removed. Since then, the PHP-related crash reports have stopped.

The firmware health audit is clean, and all essential services are working, including WireGuard, Unbound, CrowdSec, Suricata, ntopng and Caddy. I also checked the firewall rules, VLAN isolation and external accessibility. An external port check confirmed that TCP ports 80, 443 and 8443 are filtered, as intended. The internally accessible services remain functional.

Two minor points remain:

Suricata 8.0.7 repeatedly reports approximately 30 flowbit warnings after rule updates or reloads. The configuration test passes with exit code 0, and the IDS appears to be working normally.

I investigated one example (`dcerpc.rpcnetlogon`) more closely. Several rules check this flowbit, but I couldn't find a rule setting that exact bit in the downloaded rule files. Some apparent matches turned out to set different, more specific flowbits. This seems to explain at least this particular warning, although I'm not sure whether the missing dependency originates in the upstream ruleset or results from my selection of rule categories. I have left the rules unchanged for now.

The other point concerns the bootloader and AMD CPU microcode. My firewall uses an AMD EPYC 3201, UEFI boot and UFS. I removed the os-cpu-microcode-amd plugin before upgrading and have not reinstalled it yet. I also left the existing EFI bootloader untouched, since the system is running reliably.

I understand that OPNsense 26.7.1 and later support late microcode loading without requiring an updated bootloader.

Would you recommend reinstalling the AMD microcode plugin using late loading? And would you still recommend manually updating the UEFI bootloader in this situation, or is that mainly relevant for early loading?

I'd prefer to avoid unnecessary changes to a stable production firewall, but I certainly don't want to miss important CPU security fixes either.

Thanks again for the helpful advice!

Cheers,
Michael

[nero355]

Thanks again for your feedback. I wanted to provide an update on how things went.

I decided to proceed with the upgrade from OPNsense 26.1.11_10 to 26.7.7, keeping my existing UFS installation rather than performing a fresh ZFS installation.

The upgrade went smoothly overall.

NICE! :)

The only issue afterwards was an obsolete php83-pecl-mongodb package, which I removed. Since then, the PHP-related crash reports have stopped.

That could be an artifact of ZenArmor after dropping MongoDB as database completely.

I also left the existing EFI bootloader untouched, since the system is running reliably.

And would you still recommend manually updating the UEFI bootloader in this situation, or is that mainly relevant for early loading?

IIRC there was also something else going on with the Boot Loader and enough reason for updating it anyway so I would really recommend it !!

[tracker]

Thank you Franco for the effort. Much appreciated, as we normally treat the "closed" version as "stable", despite the possible security issues, which are treated individually when possible. Updating dozens of remote routes is not a trivial process.

On the other hand, user newsense can piss right off with this attitude... if you don't have a solution, just don't say anything instead of compounding on an already stressful issue with this passive-aggressive nonsense.

[nero355]

On the other hand, user <removed> can piss right off with this attitude... if you don't have a solution, just don't say anything instead of compounding on an already stressful issue with this passive-aggressive nonsense.

I think you got the wrong guy : https://forum.opnsense.org/index.php?topic=53190.msg276078#msg276078 shows a different nickname ;)

[weilander]

Just a quick follow-up:

I decided to follow the recommendation and updated the UEFI bootloader as well.

During the process, I discovered that my 200 MB EFI partition still contained a tiny FAT filesystem of approximately 779 KB, with an old bootloader dating back to 2018. I recreated the filesystem to use the available space and installed the current FreeBSD 15.1 loader.efi. The system rebooted successfully and everything is working as expected.

I also reinstalled and enabled os-cpu-microcode-amd. Microcode loading is working correctly and has been verified after reboot.

The only remaining task is updating the system BIOS/UEFI firmware, which is still from January 2021. I'll tackle that separately.

Thanks again for the recommendations and support!

[Patrick M. Hausen]

During the process, I discovered that my 200 MB EFI partition still contained a tiny FAT filesystem of approximately 779 KB, with an old bootloader dating back to 2018.

Back in the day FreeBSD generated a FAT filesystem image to be used with dd(1) for installation. The size was just enough to keep the bootloader. All daynamically generated.

[franco]

On the other hand, user newsense can piss right off with this attitude... if you don't have a solution, just don't say anything instead of compounding on an already stressful issue with this passive-aggressive nonsense.

I think this is uncalled for and actually wrong at the same time.  He gave the best advice to move forward.  Everything else is running old versions on borrowed time.

11 years ago a lot of people said we're crazy with our update approach. Now in 2026, skip a week's worth of security work and you're already behind. It's been a strange journey.

Cheers,
Franco

[weilander]

Hi Franco,

I understand your point, and I don't disagree with the technical advice. In fact, newsense's recommendation made me reconsider my approach, and as you can see, I ultimately followed it. I also appreciate the work you put into providing the PHP security update for 26.1.

But I do think there's a difference between giving the right advice and the way that advice is delivered.

I came here with a genuine question, asked politely, and explained why I was hesitant to rush a major upgrade on a production firewall. I wasn't questioning the importance of security updates or expecting unsupported versions to be maintained indefinitely.

Being told that I had "far bigger issues than a couple php vulnerabilities" and that there was "no reason to wait for miracles" felt unnecessarily dismissive. The same technical advice could have been given clearly and firmly without those remarks.

I wouldn't have chosen tracker's rather harsh wording either. But I do think he has a point about how people communicate with each other in technical forums.

Being technically right and treating someone respectfully are not mutually exclusive. Especially when someone comes here looking for help.

I'm grateful for the advice and support I received, and the successful upgrade speaks for itself. I just think the tone matters, too.

Cheers,
Michael