Messages

From my understanding the bug itself (a very rare race condition in the ip option set multiprocessing handling) is useless without further down the road support via more flexible tcp header options.

The full working exploit chain  requirements are not disclosed yet - for obvious reasons - but the Anthropic sample exploit seems to need mptcp enabled tcp services and tcp options support for the 2nd step, thats why all current more complex IDS rules targeting tcp.

Simply blocking ALL ip-options seems to be right choice here - after a review of the corresponding RFCs that define most of the prehistoric use cases.

Thanks for the qualified Feedback!

OPNsense/pf seems to be well equipped for the coming CVE-2026-98432 Linux Apocalypse. No need to inspect the tcp options in this case.

IP options are ok!

cve-2026-98432 is about tcp handshake (syn) and associated tcp options in the tcp header

The problem is: The FreeBSD pf firewall is able to track tcp session state, but has from my understanding currently no interface to investigate and normalize tcp header anomalies.

Thats a problem. For this specific CVE and in general for the fast moving ai driven exploit market.

[not]

https://atlasum.net/blog/cve-2026-98432-linux-ipv4-tcp-uaf

- does not impact FreeBSD
- does impact every Linux behind your (OPNSense-) Firewall that accepts TCP packets

Is there away to identify and drop all impacted packets? With nft i can do ...

nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop


From my understanding:
- pf scrub does not care for tcp (options)
- pf is not able to identify tcp options
- ipfw can (but only well known specific, but can not scrub unknown? maybe by tcp header lenght?)
- firewall chaining is not recommended
- firewall chaining is not part of opnsense (but can be done via script manually)

Any other options/ ideas ? (other than chain/migrate to nft based firewall or dump the complete traffic through ids / suricate screen? )

It's a vulnerability that defeats the purpose of a VPN.

To clear, this bug does only impact the data *authentication* check of the stream cipher on data inbound side -  not the data *encryption* itself!

This bug does NOT leaked direct any information or allowed to manipulate any information without breaking the private / session key first.

This bug (or bug-door) allowed to trick the server to process (parse) unauthenticated data.

Thats bad! But to exploit this, at least some weeks ago, some nation-state-actor level know-how was needed.

With the now publicly accessible open weight ai models it's direct, one shot and reliable reproduce able, possible for *everyone* to directly identify this bug - including a detailed report about the complete implications further down the process chain ...

So, yes. Patch and back port. NOW!

fixed, scheduled for 26.7.2 & 26.4.1p3

https://github.com/opnsense/src/pull/313

https://github.com/opnsense/core/issues/10650

https://www.tenable.com/cve/CVE-2026-58085



CVSS v3 : Base Score: 7.5 (HIGH)

Its a big one!

(Failure to check inbound data authentication!)

Quick hotfix & backports would be very welcome. Very small patch, very big impact. Expect AI assisted exploit flood in 3...2...1 ...

First things first:
- 25.7.3 is a Great Release!
- The UI Interface updates are very welcome!
- Thank you for your time and work!

Only a small downside for 25.7.2 => 25.7.3
update broke (REST/API/XML Backup/Restore)

REST API Backup file  [ /api/core/backup/download/this ] is not a (restore-able) xml file anymore, but response is a html-xml escaped frankenfile now. Timestamp file name generation change from RFC3339 to UnixTime (not a bug, more a feature, at least for me, maybe worth a changelog mention).

details:
https://github.com/opnsense/core/issues/9196

Thank you!

OPNBorg is a tool to help you to manage, (central-) backup, monitor, ... a complete opnsense cluster.

You can use it with only one opnsense instance, but the main target is to orchestrate a complete opnsense zoo:

https://paepcke.de/res/scr.png

In case you use nixos as opnborg hosting plattform it helps you with all the prometheus monitoring and cool grafana dashboards, but any os with a native golang compiler or a simple ready-to-use docker will do the all the basic trick as well.

as requested, the docker image (build by github)

docker pull ghcr.io/paepckehh/opnborg:latest

Hi,
you can download the packages direkt from the github.com release page now.

https://github.com/paepckehh/opnborg/releases

Just pick your Operating System and Hardware Plattform.,
Github will from now on automatically build all binaries for
every release.

Native Integration for NixOS - including nixpkgs, and declarative
setup of prometheus, grafana dashbords is already in review,
FreeBSD Ports / pkgs will follow, Docker container and other
Linux Distros may follow.

Hello OPNSense Friends,
in case you have to herd more than one OPNSense Appliance you may enjoy this little self-hosted OPN Management Portal (WIP Phase). Its Free, Transparent, OpenSource, will always be BSD-Licensed and is intentionally complementary (and not overlapping!) to OPNCentral. 

https://github.com/paepckehh/opnborg
https://paepcke.de/opnborg

Michael