26.7.7 — Security audit reports 6 vulnerable packages, but no updates available

[cfarachid]

Hello,

I am setting up OPNsense Community Edition 26.7.7 (amd64) for a small company. The firewall is still in a test environment and has not been deployed to production.

After updating, "Check for updates" reports:

There are no updates available on the selected mirror.

However, the security audit reports six vulnerable packages:

unbound-1.26.1

python313-3.13.15

ca_root_nss-3.130

brotli-1.2.0,1

curl-8.22.0

openssh-portable-10.5.p1_1,1

My current configuration:

Firmware type: Community

Mirror and flavour: default

Auxiliary packages repository: disabled

SSH: disabled

Unbound: enabled, listening on the LAN interface only

No manually configured WAN allow rules

Could you please clarify:

Are official fixes available, or scheduled, for these packages?

Do any of these findings have OPNsense-specific mitigations or applicability notes?

What temporary precautions should I take before deploying this firewall to production?

Should I wait for a package update, or is there an officially supported corrective procedure?

I would prefer to avoid unsupported package upgrades or adding external FreeBSD repositories.

Full security audit output:
***GOT REQUEST TO AUDIT SECURITY***
Currently running OPNsense 26.7.7 (amd64) at Mon Oct 26 13:41:10 UTC 2026
vulnxml file up-to-date
unbound-1.26.1 is vulnerable:
  Unbound -- Multiple vulnerabilities
  CVE: CVE-2026-97206
  CVE: CVE-2026-50106
  CVE: CVE-2026-96405
  CVE: CVE-2026-109125
  CVE: CVE-2026-35501
  WWW: https://vuxml.freebsd.org/freebsd/0be28489-cd2f-11f1-8135-8447094a420f.html

python313-3.13.15 is vulnerable:
  Python -- poplib module, when passed a user-controlled command, can have additional commands injected using newlines
  CVE: CVE-2025-15367
  WWW: https://vuxml.freebsd.org/freebsd/6d3488ae-2e0f-11f1-88c7-00a098b42aeb.html

ca_root_nss-3.130 is vulnerable:
  ca_root_nss -- trusted root certificate from compromised CA eMudhra
  WWW: https://vuxml.freebsd.org/freebsd/b755b277-cf12-11f1-bae2-3497f65b111b.html

brotli-1.2.0,1 is vulnerable:
  brotli -- out-of-bounds write permits remote code execution
  CVE: CVE-2026-111497
  WWW: https://vuxml.freebsd.org/freebsd/f1e61d76-cdb6-11f1-b15e-589cfc104230.html

curl-8.22.0 is vulnerable:
  Curl -- Multiple vulnerabilities
  CVE: CVE-2026-107929
  CVE: CVE-2026-107928
  CVE: CVE-2026-94266
  CVE: CVE-2026-94265
  CVE: CVE-2026-92386
  CVE: CVE-2026-92387
  CVE: CVE-2026-92388
  CVE: CVE-2026-92389
  CVE: CVE-2026-92390
  CVE: CVE-2026-92391
  CVE: CVE-2026-92392
  CVE: CVE-2026-86410
  CVE: CVE-2026-86412
  CVE: CVE-2026-86413
  CVE: CVE-2026-86414
  CVE: CVE-2026-86415
  CVE: CVE-2026-87861
  CVE: CVE-2026-87862
  CVE: CVE-2026-87863
  CVE: CVE-2026-87865
  CVE: CVE-2026-87866
  WWW: https://vuxml.freebsd.org/freebsd/14dab969-c797-11f1-a6ea-8447094a420f.html

openssh-portable-10.5.p1_1,1 is vulnerable:
  OpenSSH -- Multiple vulnerabilities
  WWW: https://vuxml.freebsd.org/freebsd/26fd839c-c338-11f1-a6ea-8447094a420f.html

6 problem(s) in 6 package(s) found.
***DONE***

Thank you for your help.

[Amodin]

Well first, I don't know why you're using the Community Edition for business, but secondly, your list appears that it would be a FreeBSD issue and/or the providers of the packages that would need to update them, wouldn't it? OPN isn't the developer for packages/plugins and they are actually quite active in letting FreeBSD know about issues that are problematic.

Things like Unbound don't have to be used in the firewall.  I don't use it on OPN, I maintain recursive DNS servers separate from OPN that use Unbound.  Instead, you could use another package other than keeping it on the firewall, or alternative that's offered in OPN. Disabling SSH should be your go-to anyways, so it can't even be used, and only turn it on when/if you need it.

Franco is really, really good about getting updates out as quickly as they are available, but they aren't necessarily his responsibility for updating them.

And if you wait for every package to be patched, you're essentially going to play whack a mole, because there's always something found, something fixed.  The PHP2Shell vulns have been around for 10 years, and they were only discovered because AI found them, not a hacktivist.  So, you'd be waiting forever to put something into production.