pfSense and OPNsense Release History: FreeBSD Bases and Support

pfSense and OPNsense are both open source firewall distributions built on FreeBSD, but they release and support software in different ways. As of 25 October 2026, pfSense CE 2.9.0 (20 August 2026) is the newest community release, built on a FreeBSD 16.0-CURRENT snapshot, with 2.8.1 still listed as supported. OPNsense ships two major releases a year, in January and July; the current 26.7 series runs on FreeBSD 15.1 and was at 26.7.7 on 13 October 2026.

Below: where each project came from, every major release with its date and FreeBSD base, the two numbering schemes, OPNsense's HardenedBSD years, when key security features arrived, how updates are delivered and verified, how FreeBSD advisories reach each firewall, what "supported" means, and an upgrade routine that works for both.

Key takeaways

• pfSense came first. Its documentation says it "was forked from the m0n0wall open source project in 2004". OPNsense 15.1 followed on 2 January 2015.
• Two numbering schemes. pfSense CE uses major.minor.patch with no fixed schedule (2.7.0 in June 2023, 2.8.0 in May 2025, 2.9.0 in August 2026). OPNsense uses year.month with "two major releases each year, which receive minor updates about every two weeks".
• Different kinds of base. Since 2.7.0, pfSense CE builds from a pinned FreeBSD -CURRENT snapshot (now 16.0-CURRENT). OPNsense tracks FreeBSD releases (now 15.1).
• OPNsense ran on HardenedBSD from 19.1 (January 2019) to 21.7, and moved to FreeBSD 13 in 22.1 (27 January 2022).
• Only the newest releases get fixes. pfSense lists CE 2.9.0 and 2.8.1 as supported. OPNsense community updates go to the current series only.
• FreeBSD fixes arrive in each firewall's own release. OPNsense folds FreeBSD advisories into its fortnightly updates. pfSense merges them into its next release and offers recommended patches in between through its System Patches package.
• Back up before every major upgrade. Both keep the configuration in config.xml; OPNsense major upgrades run offline, and opnsense-revert can roll a single package back.

This post goes one level deeper than our earlier coverage. See also every FreeBSD release and its support model, is open source router firmware more secure than stock, build a home firewall on a mini PC and end of life firewall risks.

Where pfSense and OPNsense came from

pfSense: a 2004 fork of m0n0wall

The pfSense documentation says pfSense software "was forked from the m0n0wall open source project in 2004". m0n0wall "was focused specifically on providing a firewall/router for embedded devices", and pfSense first aimed at "an expanded set of capabilities on larger PC and server style hardware". The oldest release in the official versions table is 1.2, dated 25 February 2008 and built on FreeBSD 6.2-RELEASE-p11, so the documented history starts there.

OPNsense: a 2014 decision and a January 2015 release

OPNsense's documentation has an "About the Fork" page that sets out the project's original reasons, while noting that "currently less than 10% of the original legacy code base remains". It says the decision was made in 2014, and it groups the reasons under six headings: technical (a wish for a roadmap with regular releases and "a decent framework"), security (the web GUI "should not perform tasks that require root access"), quality (new features built on a Model View Controller framework), community (freely available build tools), transparency, and licensing (a "very simple license that is suitable for forking"). Those are the project's own stated reasons, summarised here without comment.

Before the first release, the page says, the build tools were rewritten, OPNsense became a package on top of a custom FreeBSD build (removing it leaves "an almost standard FreeBSD base system"), and firmware upgrades moved to FreeBSD's pkg. The first release, 15.1 "Ascending Albatross", came out on 2 January 2015 on FreeBSD 10. The 16.1 notes recall: "Back then it was FreeBSD 10.0. Not even two months after, 10.1 was introduced along with the opnsense-update utility."

Release timeline: every major version and its FreeBSD base

pfSense CE

Every row comes from the official pfSense versions table; the notable changes come from each release's notes.

Up to 2.6.0, pfSense CE was built on FreeBSD RELEASE or STABLE branches. From 2.7.0 the table lists a -CURRENT snapshot pinned to a commit, such as 16.0-CURRENT@4bdcff554368 for 2.9.0: FreeBSD's development branch at a fixed point, not a FreeBSD release.

The commercial edition of pfSense

The versions table also lists a commercial edition with its own numbers, starting with 21.02 on 17 February 2021 (the same day and base as CE 2.5.0). Its latest is 26.07 (13 August 2026), with 26.10 listed as "TBD". The two share a code base and often a snapshot: CE 2.9.0 and commercial 26.07 both list 16.0-CURRENT@4bdcff554368. This post covers the community edition.

OPNsense community edition

Dates and bases come from the major release section of each series' release notes page, and the last update from the top of that page. Where a release announced no base change, the table says so.

The OPNsense roadmap lists the next release, 27.1, for January 2027.

What the two timelines show

OPNsense moves its base about once a year to an existing FreeBSD release. pfSense CE moves less often but further, to a development snapshot that is usually ahead of any FreeBSD release. A release branch comes with FreeBSD's own advisory patches; a pinned snapshot carries newer code, but every later fix has to be merged by the firewall project itself.

Version numbering and release cadence

pfSense CE: major.minor.patch, released when ready

CE numbers "use the format major.minor.patch, and each component is present even if the value is 0". Patch releases used to carry a -p suffix (2.4.5-p1, 9 June 2020); since 2.5 fixes come as point releases (2.5.1, 2.7.2, 2.8.1). There is no fixed calendar: since 2021 the minor releases have come 7 to 17 months apart.

The commercial edition: year.month

The commercial edition has used year.month.patch since "the start of 2021", and the docs say the different formats "make it clear that the releases do not necessarily happen at the same time, even if they share a common code base".

OPNsense: year.month, two majors a year, updates every two weeks

The OPNsense updates page puts it plainly: "The OPNsense update schedule consists of two major releases each year, which receive minor updates about every two weeks. The major release version number consists of the year and month of release (e.g. 25.1 for the January 2025 release), with the fortnightly minor updates adding a third number (e.g. 25.1.3 for the third update to 25.1)."

Each series has an alliterative animal codename, moving through the alphabet from "Ascending Albatross" (15.1) to "Xenial Xenops" (26.7). The commercial Business Edition runs its own April and October series (BE 21.4 to 26.4), which the security documentation describes as the stage where "functional changes are being included in a more conservative manner".

Cadence compared

OPNsense's HardenedBSD years

HardenedBSD is a FreeBSD derivative focused on exploit mitigations. OPNsense's release notes show three phases.

Adding HardenedBSD features to a FreeBSD base (2016 to 2018). The 16.1.16 update in June 2016 marked the start: "the splendid and battle-proven ASLR implementation gets incorporated into the default installation". OPNsense 16.7 (28 July 2016) listed "FreeBSD 10.3 with full integration of HardenedBSD ASLR". 17.1 brought "state-of-the-art HardenedBSD security features" on FreeBSD 11.0. During the 17.1 series, OPNsense added HardenedBSD's SafeStack for base applications and explained that "SafeStack depends on Address Space Layout Randomization (ASLR) in order to be effective". In 18.1 the source was described as "FreeBSD to 11.1-RELEASE-p6 with HardenedBSD additions", and the notes also mention that HardenedBSD enabled Meltdown mitigation (page table isolation) by default "even for AMD CPUs".

Running on HardenedBSD (2019 to early 2022). The 18.7.5 notes (17 October 2018) say "the HardenedBSD 11.2 adoption is almost finished behind the scenes", and 19.1 (31 January 2019) announced "The migration to HardenedBSD 11.2 has been completed". 20.1 noted that "HardenedBSD 12.1 has been postponed to the next major release", and 20.7 (30 July 2020) shipped it.

Back to FreeBSD (2022 onward). The 21.7 announcement (28 July 2021) said: "It will also be the last release on HardenedBSD 12.1. We are planning to start the work on FreeBSD 13 as soon as next week for the 22.1 series." 22.1 (27 January 2022) "features the upgrade to FreeBSD 13". The release notes record the move and when it happened, but they do not give a detailed reason. This post does not add one.

The 22.1 notes do warn about the side effects of a major base change: "major operating system changes bear risk for regression and feature removal". They give examples, including the end of support for insecure cryptography in the kernel for IPsec and the switch from the Realtek vendor driver back to FreeBSD's own driver, which at the time did not support newer 2.5G models. Since then, OPNsense's base has been plain FreeBSD: 13.1 in 22.7, 13.2 in 23.7, 14.1 in 24.7, 14.2 in 25.1, 14.3 in 25.7 and 15.1 in 26.7.

Which security features arrived when

Security relevant changes named in each project's own release notes or roadmap, in date order.

WireGuard on pfSense. The 2.5.1 notes say an upgrade from a system with active WireGuard tunnels "will abort until all WireGuard tunnels are removed", and the 2.5.2 add-on package settings "are not compatible with the older base system configuration", so 2.5.0 tunnels had to be rebuilt.

Privilege separation on OPNsense. The 25.7 roadmap entry lists an "optional 'strict' security mode for webui (no root mode)". It is an option, not the default.

Independent testing. The OPNsense security page describes twice yearly evaluation of Business Edition releases by an outside lab under LINCE, a methodology from Spain's National Cryptologic Center, and lists BE 26.04, 25.10, 25.04, 24.10 and 23.10 as "LINCE Certified". This applies to Business Edition builds, not community releases.

How updates are delivered and verified

OPNsense: pkg repositories, signed sets and a set of helper tools

OPNsense installs updates with FreeBSD's pkg plus its own opnsense-update utility. The man page for opnsense-update says it "offers combined kernel and base system upgrades using remotely fetched binary sets, as well as package upgrades via pkg(8)". The options -b, -k and -p choose the base, kernel and packages, and "typically, '-bkp' is used to update all currently installed components at once". Major upgrades use -u.

Repository settings live in /usr/local/etc/pkg/repos/OPNsense.conf. The man page notes that a FreeBSD.conf file in the same directory is used "to disable FreeBSD repository configuration", so packages come from OPNsense's repository and not from FreeBSD's. Signature checks use pkg's standard mechanism: the FreeBSD pkg.conf(5) man page explains that signature_type: "fingerprints" with a FINGERPRINTS path makes pkg verify a repository against "known signatures for the repository". OPNsense's opnsense-verify tool "verifies FreeBSD's pkg(8) signatures on arbitrary files", and its -l option lists the enabled repositories. In the GUI, System > Firmware > Settings selects the mirror and the release type ("Production" or "Development"), and the docs ask you to leave it on Production unless you "fully understand the implications".

For recovery, opnsense-revert "offers to securely install previous versions of packages found in an OPNsense release as long as the selected mirror caches said release", opnsense-patch applies specific upstream git commits, and opnsense-update -G returns "the log file of the last upgrade".

Minor updates install from System > Firmware > Status. Major upgrades "are installed offline", with "no web or SSH server is running for you to monitor the upgrade": console option 12 downloads the release files, reboots, installs, then reboots again.

pfSense CE: pkg upgrades, a fixed sequence and System Patches

The pfSense upgrade overview describes the traditional pkg based process that CE uses as six steps: download update files, upgrade kernel, reboot (offline downtime starts), upgrade base files ("Operating System, PHP code, etc."), upgrade base and add-on packages, finish boot. The upgrade runs from System > Update in the GUI, from console menu option 13, or from a root shell with pfSense-upgrade. The docs suggest running screen pfSense-upgrade over SSH if the connection is unreliable.

System > Update also has a Branch setting; "Latest Stable Version" is the default, and the docs warn against development snapshots in production.

The docs say installing packages from repositories other than the project's own "is not supported and carries a significant risk of breaking the installation", and that such packages "may result in failed upgrades or unbootable systems". They also recommend removing add-on packages before a major upgrade and reinstalling them afterwards, because "packages are frequently a source of problems".

Between releases, the System Patches package is the documented way to "obtain official recommended security patches and bug fixes", and to apply or revert custom patches. Automatic rollback through ZFS boot environments is documented for the commercial edition only, so a CE rollback means restoring a backup or reinstalling.

How FreeBSD security advisories reach each project

FreeBSD's side

FreeBSD publishes security advisories (SA) and errata notices (EN) on its security pages. The security page explains what qualifies: privilege escalation, code injection, memory disclosure, remotely exploitable denial of service, "unassisted jailbreak" and flaws that could produce insecure crypto keys "very likely" get an advisory, and other issues are judged case by case. The advisory list shows how often they come. On 30 June 2026 alone, FreeBSD published 12 advisories (FreeBSD-SA-26:39 to 26:50), and the most recent batch, on 14 October 2026, covered caroot, bhyve and sound.

FreeBSD's support table, last updated 14 October 2026, lists these branches as supported: stable/15 until 31 December 2029, 15.1-RELEASE until 31 March 2027, stable/14 until 30 November 2028, 14.5-RELEASE until 30 June 2027 and 14.4-RELEASE until 31 December 2026. The support model says each minor release "is only supported for three months after the next minor release within the same major version", and from FreeBSD 15 each stable branch is "explicitly supported for 4 years from its dot-zero release".

How OPNsense picks them up

Because OPNsense tracks FreeBSD releases, its fortnightly updates can carry FreeBSD's patches directly, and the release notes say so. 25.1.x notes describe an update that "ships the latest FreeBSD SA/EN patches". 25.7.10 (18 December 2025) "is released mainly due to the fact that FreeBSD-SA-25:12" had been published. 26.1.11 (1 July 2026) arrived "with a bag of security advisories also for FreeBSD which came out just yesterday", and its patch list includes entries such as "execve: local privilege escalation via execve(2) TOCTOU race" and "openzfs: multiple vulnerabilities in OpenZFS". Those match the FreeBSD advisories published on 30 June 2026.

How pfSense picks them up

pfSense release notes list the FreeBSD advisories each release includes. The 2.3 notes, for example, list FreeBSD-SA-16:01.sctp through FreeBSD-SA-16:15.sysarch alongside pfSense's own advisories (pfSense-SA-16_01.webgui and 16_02.webgui). The 2.9.0 notes say "security and errata fixes were merged from FreeBSD, including fixes for vulnerabilities discovered in WireGuard, OpenSSL, and the DHCP client".

Since 2.7.0, the base is a -CURRENT snapshot, not a FreeBSD release, so FreeBSD's advisory patches, which target release and stable branches, have to be merged into the project's own branch. That happens in the next pfSense release or, for selected issues, through System Patches. pfSense also publishes its own advisories for its own code; the 2.9.0 notes list several, such as pfSense-SA-26_03.webgui and pfSense-SA-26_04.webgui. In practice, a CE user's exposure to a FreeBSD advisory depends on when the next CE release or recommended patch arrives, not on FreeBSD's dates.

What support means for each project

pfSense CE

The pfSense releases index has two lists. "Current and Upcoming Supported Releases" for CE contains 2.9.0 and 2.8.1. Everything from 2.8.0 back to 2.0 is under "Older/Unsupported Releases". The upgrade guide adds that official help "can only officially assist with the most recent stable releases", and that larger jumps, "such as from 2.3.x to 2.9.0-RELEASE must be handled with care, and ideally tested on identical hardware".

No end date is published for either, so plan to move within one release cycle of each new CE release.

OPNsense community edition

The OPNsense docs do not publish an end of support date per series. The release notes record the pattern instead. Each series' final update has landed at or just before the next major release: 25.1.12 on 22 July 2025, the day before 25.7 (23 July 2025); 25.7.11 on 15 January 2026, two weeks before 26.1 (28 January 2026); and 26.1.11 on 1 July 2026, two weeks before 26.7 (15 July 2026). After that, updates go to the new series. The 26.1 notes also said the upgrade path from 25.7 "will likely be unlocked on January 29", the day after the release, so there is a short gap between a major release and the upgrade button appearing.

In effect, a community series gets fixes for about six months. If you need a slower track, the Business Edition is the option the project describes for that purpose.

Hardware that stops getting builds

Both projects have dropped architectures and image types, and each time a group of devices stopped getting new builds.

• 32-bit x86. pfSense 2.4 (12 October 2017) states "There are no images available for 32-bit (x86/i386) Intel architecture systems". OPNsense announced in the 19.1 notes that 20.1 would "discontinue the i386 (Intel 32 Bit) franchise", and the 20.1 notes confirm that "updated 32-bit builds (also known as i386) will no longer be available" once 20.7 shipped on 30 July 2020.
• NanoBSD and small flash images. pfSense 2.4 removed NanoBSD ("use a full install instead"). OPNsense's 19.7 notes told Nano image users to reinstall from the latest image because of an inode shortage.
• Memory limits. The pfSense upgrade guide warns that hardware with "1 GiB or less available memory may have issues upgrading".

A device on a dropped architecture keeps running its last build, but nothing new reaches it, including FreeBSD fixes. That is the same position as an end of life appliance, and our end of life firewall guide covers how to replace one without a gap in coverage.

Step by step: check, back up, update, verify, roll back

This routine works for both projects. Where the commands differ, both are shown. Run the shell commands from the console or over SSH as root.

Step 1: find out exactly what you are running

FreeBSD's freebsd-version tells the installed kernel apart from the running kernel. The man page says -k prints the installed kernel, which "if a new kernel has been installed but the system has not yet rebooted" differs from the running one, and -r prints the running kernel. A mismatch means a reboot is still pending.

# Both projects: FreeBSD kernel and userland versions
freebsd-version -kru
uname -a

# OPNsense: product version, flavour and architecture
opnsense-version

# pfSense CE: the dashboard System Information widget shows the version;
# the console banner shows it at login as well.

On pfSense CE, anything other than 2.9.0 or 2.8.1 is unsupported; on OPNsense, anything before the 26.7 series gets no updates.

Step 2: read the release notes for every version you will cross

Read the notes for the target release and every major release in between. They list removed features (WireGuard in pfSense 2.5.1, insecure IPsec ciphers in OPNsense 22.1 and pfSense 2.7.0), driver changes and known issues.

Step 3: take a configuration backup and store it off the box

On pfSense, go to Diagnostics > Backup/Restore, set the Backup Area to All and click Download. The upgrade guide says to "keep multiple copies of the backup file in different secure locations". On OPNsense, use System > Configuration > Backups. A local backup can be protected with a password, and you can choose whether to include RRD statistics.

Keep the backup with the installer image for the version you run: a clean install plus that file gets you back.

Step 4: record the package set

# Both projects use FreeBSD pkg
pkg info > /root/pkg-before.txt
pkg -vv | sed -n '/Repositories:/,$p'

# OPNsense: list the enabled repositories
opnsense-verify -l

If pkg -vv lists a repository you did not add on purpose, stop and find out why first.

Step 5: take a snapshot if you can

On a virtual machine, take a snapshot, which the pfSense guide calls "an easy fall-back plan for virtualized firewalls". It also suggests a reboot first, so a failing disk is not mistaken for an upgrade problem, and removing any attached installation media.

Step 6: run the update

# OPNsense: check what an update would do, then run a minor update
opnsense-update -c
# then use System > Firmware > Status, or the console menu.
# For a major upgrade use console option 12 and type the release, e.g. 26.7.
# Watch from a VGA or serial console: the upgrade runs offline.

# pfSense CE: console option 13, or as root:
pfSense-upgrade
# Over unstable SSH, run it inside screen as the docs suggest:
pkg install screen
rehash
screen pfSense-upgrade

On pfSense, remove add-on packages first if you can; the docs warn "Do not upgrade packages before upgrading pfSense software". On OPNsense, the next major upgrade path appears a day or so after the release.

Step 7: verify after the reboot

# Kernel and userland should now match
freebsd-version -kru

# Check installed package files against their recorded checksums.
# pkg-check(8): an invalid checksum "can be caused by data corruption or tampering"
pkg check -s -a

# Compare the package set with the one you recorded
pkg info > /root/pkg-after.txt
diff /root/pkg-before.txt /root/pkg-after.txt

# OPNsense: read the log of the last upgrade
opnsense-update -G

Then check that interfaces, VPN tunnels, DHCP and the firewall log all look as expected.

Step 8: roll back if needed

On OPNsense, a single misbehaving package can go back to the version from an earlier release. The man page example is opnsense-revert -r 17.7.1 unbound, and running opnsense-revert unbound later brings it back to current. For a single upstream fix, opnsense-patch applies a specific commit, and running it again with the same commit removes it. A failed major upgrade means restoring the snapshot, or reinstalling and importing config.xml.

On pfSense CE, a failed upgrade means restoring the VM snapshot, or a fresh install of the version you want with the backup restored. The upgrade guide notes that "an older configuration can always be imported into a new version", and that the upgrade code converts it. The reverse is not true: the versions table tracks a config revision number for each release (24.6 for 2.9.0, 24.0 for 2.8.x) because a newer configuration "may make a configuration file incompatible with older versions". Keep the backup taken on the old version.

Common mistakes

• Staying on an unsupported release because it works. A pfSense CE 2.7.2 box or an OPNsense 25.7 box still forwards packets, but it gets no FreeBSD fixes and no fixes for the firewall's own code. Compare your version with the supported lists every quarter.
• Assuming FreeBSD's dates apply to your firewall. OPNsense 26.7 is on FreeBSD 15.1, which FreeBSD supports until 31 March 2027, but you only get those fixes through OPNsense updates on the current series. pfSense CE 2.9.0 is on a 16.0-CURRENT snapshot that FreeBSD's release table does not cover at all.
• Adding package repositories from unknown sources. Both projects install with pkg and check repository signatures. A third party repository adds code that the project never built or signed. The pfSense docs warn this "may result in failed upgrades or unbootable systems".
• Exposing the web GUI to the WAN. Both projects publish advisories for their web interfaces, such as pfSense-SA-26_03.webgui in the 2.9.0 notes. Keep the GUI on management interfaces or behind a VPN, and use the two factor options both projects support.
• Skipping a config backup before a major upgrade. Configuration formats change between releases. A backup from the old version, kept off the box with the matching installer, is the only clean way back on CE.
• Ignoring a pending reboot. If freebsd-version -k and -r disagree, the new kernel is installed but not running, so the fixes it carries are not active yet.

FAQ

What FreeBSD version is pfSense CE 2.9.0 based on?

The official versions table lists pfSense CE 2.9.0 (20 August 2026) as built on 16.0-CURRENT@4bdcff554368, a snapshot of FreeBSD's development branch at that commit. CE 2.8.0 and 2.8.1 used 15.0-CURRENT, and 2.7.x used 14.0-CURRENT.

What FreeBSD version does OPNsense 26.7 use?

OPNsense 26.7 "Xenial Xenops" (15 July 2026) uses FreeBSD 15.1, according to its release notes and the OPNsense roadmap. The previous series, 25.7, used FreeBSD 14.3.

How often does OPNsense release updates?

The updates documentation says there are two major releases each year, in January and July, and that each "receive minor updates about every two weeks". Hotfixes can come between scheduled updates.

Why is pfSense numbered 2.x while the commercial edition uses 25.11 or 26.07?

The pfSense docs say the community edition uses major.minor.patch and the commercial edition has used year.month.patch since early 2021. The different formats make it clear that the two editions do not necessarily release at the same time, even when they share code.

Which pfSense CE versions are still supported?

As of 25 October 2026, the pfSense releases index lists 2.9.0 and 2.8.1 as the supported CE releases. 2.8.0 and everything older are listed as unsupported.

How long is an OPNsense release supported?

No fixed end date is published for each series. In practice, the community edition gets fixes on the current series only, and each series' last update has landed at or just before the next major release, which gives each series about six months of updates.

Why did OPNsense switch from HardenedBSD back to FreeBSD?

The release notes record when, not why. 21.7 (July 2021) was announced as the last release on HardenedBSD 12.1, and 22.1 (January 2022) moved to FreeBSD 13. The notes do not give a detailed reason, so check the project's own announcements if the reasoning matters to you.

When did pfSense get WireGuard?

pfSense CE 2.5.0 (17 February 2021) included a kernel WireGuard implementation. It was removed from the base system after 2.5.0 "when it was removed from FreeBSD", and returned as an add-on package in 2.5.2 (7 July 2021).

How do I roll back a bad OPNsense update?

For a single package, opnsense-revert -r followed by a release number installs the package version from that release, if your mirror still caches it. For a failed major upgrade, restore a VM snapshot or ZFS snapshot, or reinstall and import your configuration backup.

A firewall distribution is itself a bundle of open source components: a FreeBSD base, OpenSSL, OpenSSH, PHP, Python, Suricata, Unbound, Kea and dozens of other packages, each updated on its own upstream schedule and repackaged by the firewall project. The firewall image still has to be fixed by its own project, so the fit here is indirect: the same component hygiene applies to the services and tooling you build and deploy behind it, and that is where the approach below helps.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Safeguard does not scan or patch a pfSense or OPNsense install, and it does not manage firewall configurations. The fit is with the software you build and run behind the firewall, and with the open source components that software carries.

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. If you keep firewall automation scripts, configuration tooling or internal services in repositories on a build host, this is how you scan those repositories and images where they live.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. Asked to fix a lodash CVE, the assistant reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to a dashboard, exporter or API client you wrote around your firewall, where the vulnerable dependency is in your own repository and the fix is a change you review and test.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once your projects are in Safeguard, you can ask which of them contain a given component and version, for example every service still built against an OpenSSL release that both firewall projects moved past in their latest releases.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• pfSense documentation: Versions of pfSense software and FreeBSD
• pfSense documentation: Releases index
• pfSense documentation: General information and project history
• pfSense documentation: 2.3 new features and changes
• pfSense documentation: 2.4 new features and changes
• pfSense documentation: 2.5.0 new features and changes
• pfSense documentation: 2.5.1 new features and changes
• pfSense documentation: 2.5.2 new features and changes
• pfSense documentation: 2.6.0 new features and changes
• pfSense documentation: 2.7.0 new features and changes
• pfSense documentation: 2.8.0 new features and changes
• pfSense documentation: 2.9.0 new features and changes
• pfSense documentation: Upgrade guide
• pfSense documentation: Upgrade process overview
• pfSense documentation: Pre-upgrade tasks
• pfSense documentation: Perform the upgrade
• pfSense documentation: System Patches package
• OPNsense documentation: Releases
• OPNsense documentation: About the Fork
• OPNsense documentation: Updates
• OPNsense documentation: Backups
• OPNsense documentation: Security
• OPNsense roadmap
• OPNsense 15.1 release notes
• OPNsense 15.7 release notes
• OPNsense 16.1 release notes
• OPNsense 16.7 release notes
• OPNsense 17.1 release notes
• OPNsense 17.7 release notes
• OPNsense 18.1 release notes
• OPNsense 18.7 release notes
• OPNsense 19.1 release notes
• OPNsense 19.7 release notes
• OPNsense 20.1 release notes
• OPNsense 20.7 release notes
• OPNsense 21.1 release notes
• OPNsense 21.7 release notes
• OPNsense 22.1 release notes
• OPNsense 22.7 release notes
• OPNsense 23.1 release notes
• OPNsense 23.7 release notes
• OPNsense 24.1 release notes
• OPNsense 24.7 release notes
• OPNsense 25.1 release notes
• OPNsense 25.7 release notes
• OPNsense 26.1 release notes
• OPNsense 26.7 release notes
• opnsense-update(8)
• opnsense-revert(8)
• opnsense-patch(8)
• opnsense-verify(8)
• opnsense-version source
• FreeBSD security information
• FreeBSD security advisories
• FreeBSD unsupported releases
• freebsd-version(1)
• pkg-check(8)
• pkg.conf(5)

Last reviewed: 25 October 2026. Both projects release often; check the pfSense versions table and the OPNsense release notes before planning an upgrade.