FreeBSD Release History: Every Major Version and Security Support

FreeBSD has shipped fifteen major versions, from FreeBSD 1.0 in late 1993 to FreeBSD 15.0 on 2 December 2025, and the newest release is 15.1 (16 June 2026). Each major version gets a stable branch, and from FreeBSD 15 onward that branch is supported for four years from its .0 release. Each minor release is supported until three months after the next minor release in the same series. The FreeBSD Security Team fixes the base system through signed Security Advisories (FreeBSD-SA) and Errata Notices (FreeBSD-EN), while third party packages are tracked separately in the VuXML database that pkg audit reads.

As of this writing (23 October 2026), the FreeBSD security page lists three supported releases: 15.1-RELEASE (supported until 31 March 2027), 14.5-RELEASE (until 30 June 2027) and 14.4-RELEASE (until 31 December 2026). The stable/15 branch is supported until 31 December 2029 and stable/14 until 30 November 2028. FreeBSD 15.0-RELEASE reached end of life on 30 September 2026 and FreeBSD 13 left support entirely on 30 April 2026. If you run anything older, you are on an unsupported release and no longer receive advisories or binary patches.

This post goes one level deeper than our Debian release history and Fedora, CentOS Stream and RHEL release pipeline posts, sideways into the BSD family; our Ubuntu release history covers the same questions for Canonical's releases. FreeBSD is not a Linux distribution. It ships kernel and userland from one source tree, under one release engineering team and one security team, and keeps the base system and third party software on two separate update tracks. Most confusion about FreeBSD support comes from not knowing which track a piece of software sits on.

Key takeaways

• FreeBSD began in early 1993 as a cleanup of Bill Jolitz's 386BSD. FreeBSD 1.0 shipped in late 1993, and after the Novell and University of California settlement the project rebuilt itself on 4.4BSD-Lite for FreeBSD 2.0 in late 1994.
• There are three kinds of branch: main (CURRENT, today 16.0-CURRENT), stable/N (one per major version, for example stable/15) and releng/N.M (one per release, which becomes the security branch for that release, for example releng/15.1).
• In July 2024 the core team approved a fixed, quarterly release schedule and cut stable branch support from five years to four, starting with FreeBSD 15. A .0 release is planned every two years, in December.
• A minor release (14.4, 15.1 and so on) is supported for three months after the next minor release in the same series, or until the stable branch ends if it is the last one.
• Security Advisories cover the base system only, are PGP signed by the Security Officer, and are never issued for CURRENT. Errata Notices cover base system bugs that are not security issues. The advisory index goes back to April 1996 and lists 729 advisories as of 23 October 2026.
• Headline security features arrived in this order: jails (4.0), the MAC framework (5.0, experimental), ZFS (7.0 experimental, 8.0 production), Capsicum (9.0), OpenZFS and kernel TLS (13.0), ASLR on by default for 64 bit executables (13.2 and 14.0), and the packaged base system, known as pkgbase (tech preview in 15.0).
• Update the base system with freebsd-update fetch and freebsd-update install (or with pkg on a pkgbase system). Update third party software with pkg upgrade, and check it with pkg audit -F. One does not cover the other.

Where did FreeBSD come from?

FreeBSD's own Handbook tells the origin story plainly. The project "had its genesis in the early part of 1993," started by the last three coordinators of the Unofficial 386BSD Patchkit: Nate Williams, Rod Grimes and Jordan Hubbard. 386BSD was Bill Jolitz's port of BSD to the Intel 386, and by 1993 it had gone almost a year without a new release. The patchkit, a pile of community fixes applied on top of 386BSD, had grown unwieldy, so the three coordinators planned an interim snapshot under the working title "386BSD 0.5" or "386BSD Interim."

When Jolitz withdrew his support, the group carried on under a new name, "FreeBSD," which the Handbook credits to David Greenman. Walnut Creek CDROM agreed to distribute it on CD and gave the project a machine and a fast network connection, which mattered when many users had no easy Internet access.

The Net/2 problem and the move to 4.4BSD-Lite

The first public release, FreeBSD 1.0, was based on the Berkeley "Net/2" tape (the Handbook calls it "4.3BSD-Lite") with components from 386BSD and the Free Software Foundation. FreeBSD 1.1 followed in May 1994.

Then the legal ground moved. Novell, which by then owned the original AT&T UNIX rights, and the University of California settled their long running lawsuit over Net/2. Under the settlement, Berkeley accepted that three files in Net/2 were encumbered and had to be removed. In return, the upcoming 4.4BSD-Lite release would be declared unencumbered, and Net/2 users were strongly encouraged to switch. FreeBSD was given until the end of July 1994 to stop shipping its Net/2 based product, and was allowed one last release before that deadline: FreeBSD 1.1.5.1.

The project then rebuilt itself on 4.4BSD-Lite. Only three files (System V shared memory and semaphores) had been removed, but years of FreeBSD fixes had to be merged into a new and incomplete base. FreeBSD 2.0 followed in late 1994 and 2.0.5 in June 1995. Every later release descends from that rebase, which is also why the code carries BSD license terms; our BSD 3-clause license explainer covers what those mean for products that ship FreeBSD code.

A small date note: FreeBSD's release information page lists 1.0 as "November, 1993" and 2.0 as "November, 1994", while the Handbook history says 1.0 shipped "in December of 1993" and that 2.0 was released in December 1994. We give both below and treat the release information page as the record for the table.

Every major version: dated timeline

The table below uses the FreeBSD release information page for release dates and the supported and unsupported releases pages for end of life dates. The "stable branch end of life" is the date the whole major series stopped (or will stop) receiving security support. FreeBSD did not publish branch end of life dates for versions 1 to 3 on its unsupported releases page, so those rows say "not listed."

A few release dates differ by a few days between FreeBSD's own pages: 5.0 (14 January 2003 on the release page, 19 January in the announcement email), 6.1 (8 or 9 May 2006), 8.4 (7 or 9 June 2013), 9.0 (12 or 10 January 2012) and 11.4 (23 or 16 June 2020). None of this changes any support decision, but it explains why two inventory tools can disagree.

Supported releases on 23 October 2026

The security page calls these the earliest dates support will end and says they "may be pushed back if circumstances warrant it." Plan against the published date.

How do FreeBSD branches work?

FreeBSD has one Git source repository with three kinds of branch. The names matter, because advisories, uname -r output and package repository URLs all use them.

CURRENT (main)

main is the development branch, today building as 16.0-CURRENT. New features land here first, and the security page states that advisories are not issued for CURRENT because it is "primarily oriented towards FreeBSD developers."

STABLE (stable/N)

Before a new major version ships, release engineering branches stable/N from main. Changes that keep the binary interface stable are merged back from main (an MFC, "merge from current"), and builds report themselves as, for example, 14.4-STABLE. The four year support clock measures this branch. Advisories cover it, but you receive fixes only by updating and rebuilding from source.

RELEASE and the security branch (releng/N.M)

Each release is cut onto its own releng/N.M branch, which becomes that release's security branch after it ships. Only security and errata fixes go there, and each bumps the patch level, so a system shows 14.4-RELEASE-p4 after four patch sets. Most production systems sit here, and it is what freebsd-update serves.

How did the support model change in 2024?

FreeBSD's support model has gone through three phases, and you can see all of them in the "Type" column of the unsupported releases page.

Phase 1: Normal and Extended releases (to 2015)

Up to the FreeBSD 10 era, each release was labeled "Normal" or "Extended." Extended releases got a longer support window, typically about two years, while Normal releases got a shorter one, often a little over a year. For example, 10.3 (Extended, April 2016) was supported to 30 April 2018, while 10.2 (Normal, August 2015) ended on 31 December 2016. The labels made planning harder, because you had to know in advance which minor version would get the longer life.

Phase 2: branch based support (2015 to 2024)

In February 2015 the project switched to a branch based model: the whole stable branch got a fixed five year life, and each minor release was supported until three months after the next minor release. The unsupported releases page shows the labels disappearing from 11.0 onward (the Type column becomes "n/a"). Under this model, the 13 series ran from 13.0 (13 April 2021) to stable/13 end of life on 30 April 2026, five years and two weeks later.

Phase 3: a fixed quarterly schedule and four years per branch (from 2024)

On 11 July 2024, release engineering lead Colin Percival announced two changes on the freebsd-announce list, after core team approval:

1. Stable branch support drops from five years to four years after the .0 release, starting with FreeBSD 15.
2. Releases follow a fixed quarterly schedule: a .0 release every two years in December, and a minor release from one of the two supported stable branches in most quarters.

The reasoning in the announcement is practical. Release engineering can manage a release every three months. A .0 every two years suits development, because some features cannot be merged back to an older branch. But the security and ports teams "can't practically manage more than 2 stable branches at once," so four years of support per branch, with a new branch every two years, means at most two branches in support at any time. The release process was also trimmed to three BETA builds and one release candidate.

Inside each quarter, the code slush starts mid first month, BETA builds come at the start of the second month, and the release lands early in the third. So features should land by mid January, April, July or October, and releases should be out by the end of March, June, September or December.

The schedule published in that announcement, checked against what actually happened:

Two things stand out. First, the project has hit every slot in that plan so far. Second, the 13 and 14 series kept their five year promises: the announcement notes that 13.5 and 14.6 are supported until five years after 13.0 and 14.0. Only FreeBSD 15 and later get four years.

Worked example: how long is my release supported?

The minor release rule is "next minor release plus three months," with end of life falling at the end of a month. Two examples from the published dates:

• FreeBSD 15.0 was released on 2 December 2025. The next 15.x release, 15.1, came out on 16 June 2026. Three months later puts 15.0's end of life at 30 September 2026, which is exactly what the unsupported releases page shows. Anyone still on 15.0-RELEASE today needs to move to 15.1.
• FreeBSD 14.4 was released on 10 March 2026. The next 14.x release, 14.5, came out on 8 September 2026. Three months later gives 31 December 2026, which is the end of life the security page lists.

The last minor release of a series is the exception: it lives until the stable branch ends. That is why 13.5 (11 March 2025) was supported until 30 April 2026, more than a year, and why 14.6 is planned to run until November 2028.

For capacity planning: a FreeBSD 15 system needs a minor upgrade roughly every six months and a major upgrade within four years of 15.0. FreeBSD trades a shorter per release window than Debian or the enterprise Linux lifecycles for a predictable calendar and binary upgrades between minor releases.

How does the FreeBSD Security Team issue advisories?

Who decides

The FreeBSD Security Officer is defined by a charter the core team accepted in February 2002. The Security Officer issues advisories, responds to vendor inquiries, audits code (particularly security and network code) and has a veto in security matters, including the power to request that a commit be backed out. A new Security Officer is appointed by the previous one and ratified by the core team, and the officer is accountable to the core team. The Security Officer can appoint a Security Officer Team and delegate to it. Separately, the Ports Security Team handles third party software in the ports tree, which is why ports issues end up in VuXML rather than in FreeBSD-SA advisories.

The security page says base system issues should be reported by email to the Security Team, or with PGP encrypted email to the Security Officer team if more confidentiality is needed.

When an issue becomes a Security Advisory

The security page lists the questions the team asks when a report comes in. An advisory is "very likely" if the issue is one of these:

• A privilege escalation.
• Code injection.
• Memory disclosure or a data leak from the kernel, a privileged process, or a process owned by another user.
• A denial of service, but only when remotely exploitable, where remote means from a different broadcast domain. ARP and NDP based attacks on the local segment do not qualify.
• An unassisted jail escape.
• A malfunction that could produce insecure cryptographic keys, such as a random number generator bug.

Anything outside the list is judged case by case and may become either an advisory or an Errata Notice. When an advisory is warranted, the reporter's CVE is used if they requested one; otherwise the project assigns one from its own CVE pool.

Security Advisories versus Errata Notices

The advisory index starts in April 1996 (FreeBSD-SA-96:01.sliplogin) and, on 23 October 2026, lists 729 advisories. The most recent is FreeBSD-SA-26:73.caroot, dated 21 October 2026. The index lists 12 advisories for 2025 and 73 so far for 2026. Raw counts say little on their own, because one advisory can bundle several CVEs and the mix of components (OpenSSL, the TCP stack, bhyve, jails, drivers, the root certificate store) changes every year. Operationally, 2026 has meant frequent patch levels, so a host left alone for a quarter will be many patch sets behind.

Advisories go to three mailing lists (freebsd-security-notifications, freebsd-security and freebsd-announce), are always signed with the Security Officer PGP key, and are archived with their patches on security.FreeBSD.org.

How to read an advisory

The Handbook walks through a real advisory, FreeBSD-SA-23:07.bhyve, as its example. Every FreeBSD advisory uses the same skeleton:

In the Handbook example, the Impact section notes that a privileged guest could run code in the bhyve host process, but that bhyve runs in a Capsicum sandbox, so that code is limited to the capabilities bhyve holds. Sandboxing does not stop the bug; it limits what the bug can reach. The Solution section also says when a reboot or service restart is required, because a patched file on disk does nothing for a process still running old code.

What security features arrived in each version?

Here is the feature history in more detail, using the project's own release announcements, release notes and manual page HISTORY sections as the source for each claim.

Jails (FreeBSD 4.0, March 2000)

The jail(8) manual page records that "The jail utility appeared in FreeBSD 4.0." A jail is an operating system level partition: processes inside a jail see their own file system root, their own hostname and their own IP addresses, and root inside the jail cannot affect the host. The same manual page notes that hierarchical jails (jails within jails) arrived in FreeBSD 8.0, and that the jail.conf configuration file arrived in 9.1. FreeBSD 12.0 made pf usable inside VNET jails (jails with their own network stack) and allowed bhyve to run inside a jail. FreeBSD 15.0 added kevent filters that track jail creation, changes, attachment and removal.

Because jails are a security boundary, an "unassisted jailbreak" is one of the categories the security page lists as very likely to get an advisory, and the 2026 index includes jail advisories. Jails are only as strong as the host kernel they share, which is why patching the host matters more than patching the jail.

The MAC framework (FreeBSD 5.0, January 2003)

The mac(4) manual page says the Mandatory Access Control implementation "first appeared in FreeBSD 5.0 and was developed by the TrustedBSD Project." The 5.0 announcement listed it as "experimental support for Mandatory Access Controls (MAC)," alongside UFS2 and the GEOM storage framework. The MAC framework lets loadable policy modules add checks to kernel operations beyond normal UNIX permissions, for example multi level security labels or rules that restrict which users can see each other's processes. FreeBSD 15.0's release notes declare the mac_do(4) policy module production ready and add a common jail parameter node for MAC modules.

ZFS (experimental in 7.0, production in 8.0, OpenZFS in 13.0)

FreeBSD 7.0's announcement (27 February 2008) listed "experimental support for Sun's ZFS filesystem." FreeBSD 8.0's announcement (25 November 2009) said "ZFS is no longer in experimental status." FreeBSD 9.0 moved to ZFS version 28, and 10.0 added TRIM for SSDs and LZ4 compression. In FreeBSD 13.0, the release notes state "The ZFS implementation is now provided by OpenZFS," and FreeBSD 14.0 shipped OpenZFS 2.2. For operations, ZFS matters mostly through boot environments: snapshot the system before an upgrade and roll back if it breaks.

Capsicum (FreeBSD 9.0, January 2012)

The capsicum(4) manual page says "Capsicum first appeared in FreeBSD 9.0, and was developed at the University of Cambridge." The Cambridge project page by Robert Watson and Jonathan Anderson describes it as turning file descriptors into capabilities and adding a "capability mode" in which a process can no longer reach global namespaces such as the file system by path. The 9.0 announcement called it "an experimental set of features for sandboxing support." Early adopters on the project page include compartmentalized tcpdump and gzip, stronger privilege separation in OpenSSH and dhclient, and a Chromium adaptation done with Google. FreeBSD 12.0 added more Capsicum to sshd, and bhyve runs in a Capsicum sandbox, as the Handbook's example advisory shows.

Toolchain, packaging, hypervisor and kernel TLS (9.0 to 13.0)

Four changes between 2012 and 2021 shaped the attack surface more than any single feature. FreeBSD 9.0 brought LLVM and Clang into the base system, 10.0 made Clang the installed compiler where it is the default, and 13.0 "removed the obsolete binutils 2.17 and gcc(1) 4.2.1 from the tree," leaving every architecture on LLVM. FreeBSD 10.0 made pkg "the default package management utility" and removed pkg_add, which brought signed repositories and pkg audit. The same release added the bhyve hypervisor, later extended with graphics (11.0), NVMe emulation and jail support (12.0), and TPM and GPU passthrough (14.0); as a hypervisor it is a regular subject of advisories, because guest to host escapes are a serious bug class. FreeBSD 13.0 added kernel TLS ("in-kernel framing and encryption of Transport Layer Security (TLS) data on TCP sockets"), a performance feature that also moves TLS record handling into the kernel, which is why ktls appears as its own component in the advisory index.

ASLR on by default (FreeBSD 13.2 and 14.0)

Both the 13.2 and the 14.0 release notes state that "Address Space Layout Randomization (ASLR) is enabled for 64-bit executables by default." The notes also explain the opt out paths for software that breaks: proccontrol -m aslr -s disable command for one run, or elfctl -e +noaslr file to mark a binary permanently. If you are auditing a fleet, those two commands are what you search for to find exceptions someone made.

OpenSSL generations (12.0, 14.0, 15.0)

The base system carries its own OpenSSL, which is why OpenSSL advisories appear in the FreeBSD-SA index. FreeBSD 12.0 moved to OpenSSL 1.1.1a (an LTS series). FreeBSD 14.0 moved to OpenSSL 3.0.12, "a major upgrade from OpenSSL 1.1.1t in FreeBSD 13.2-RELEASE." FreeBSD 15.0 moved to OpenSSL 3.5.4, the current upstream LTS line, with QUIC support and the standardized post quantum algorithms ML-KEM, ML-DSA and SLH-DSA. OpenSSH 10.0p2 in 15.0 uses post quantum key agreement by default and, following upstream, removed the weak DSA signature algorithm.

The packaged base system, pkgbase (14.0 experimental, 15.0 tech preview)

The Handbook says official base system packages began in October 2023 with 14.0, as an experiment. The 15.0 announcement calls the packaged base system "a major change," offered as a technology preview and already the default for the project's VM and public cloud images. Distribution sets are planned for removal in FreeBSD 16, but they and freebsd-update stay supported for the whole life of the 15 branch. How it works day to day is covered in the updates section below.

Platform retirements in 15.0

The 15.0 release notes say "the venerable 32-bit hardware platforms i386, armv6, and 32-bit powerpc have been retired," with 32 bit applications still running through compatibility mode on 64 bit platforms. armv7 is the last supported 32 bit platform. If you have i386 FreeBSD hosts, they cannot move past FreeBSD 14, which means a hard end of the road on 30 November 2028.

How are base system updates separated from third party packages?

This is the most important operational idea in FreeBSD, and the one people coming from Linux most often get wrong.

On Debian, the kernel, the C library, OpenSSL and nginx are all distribution packages updated by one tool. FreeBSD has two separate worlds:

1. The base system. The kernel and the userland outside /usr/local, including the base copies of OpenSSL, OpenSSH and other contributed software. It is built from the FreeBSD source tree, versioned as a unit (15.1-RELEASE-p2), fixed through Security Advisories and Errata Notices, and updated with freebsd-update, with pkg on a pkgbase host, or by building from source.
2. Third party software. Everything from the Ports Collection, installed as packages under /usr/local. These have their own versions, are tracked by the Ports Security Team and port maintainers in VuXML, and are updated with pkg upgrade and checked with pkg audit.

The Handbook says it directly: while FreeBSD releases advisories for the base system, "doing so for every third party utility is beyond the FreeBSD Project's capability," which is why pkg audit exists.

What changes with pkgbase

pkgbase blurs the first column. On a pkgbase host, the base system is installed as packages named FreeBSD-* from a repository called FreeBSD-base, and you update it with pkg. The Handbook shows the repository configuration for release branches:

FreeBSD-base {
    url = "pkg+https://pkg.freebsd.org/${ABI}/base_release_${VERSION_MINOR}";
    mirror_type = "srv";
    signature_type = "fingerprints";
    fingerprints = "/usr/share/keys/pkg";
    enabled = yes;
}

The repository is still a separate repository with its own signing keys, and the base system is still patched only because the Security Team fixes it. What changes is the mechanism, not the split in responsibility. On a pkgbase host, pkg audit covers third party packages in VuXML; the base system is still covered by FreeBSD-SA advisories, which you match against the base package versions or freebsd-version output.

Converting an existing 14.0 or later host to pkgbase uses the Foundation sponsored pkgbasify tool, which the Handbook recommends. According to the Handbook, it creates a backup ZFS boot environment, writes the repository configuration, converts the base, kernel, lib32 and debug components, merges configuration files, updates the password and capability databases, and restarts sshd. The Handbook warns that the migration needs up to 5 GiB of extra free space and that the tool does not check for it, and that the whole path is still in development.

How is the FreeBSD project governed?

FreeBSD is run by volunteers and an elected core team, with a separate non profit foundation supporting it. Our open source foundation governance models post compares this pattern with others; here is how it works for FreeBSD specifically.

Committers

Committers are people with push access to the Git repositories. The Handbook notes that the project moved from CVS to Subversion in June 2008, and migrated the source and documentation repositories to Git in December 2020, with ports following in April 2021. Anyone can file a bug; committers review and land changes.

The core team

The administration page describes the core team as the project's "Board of Directors," responsible for overall goals and direction, and states that "the Core Team is elected by the active developers in the project." The Handbook says elections are held every two years and that the core team it describes was elected in May and June 2024. The administration page lists nine core members as of October 2026. Core approves decisions such as the 2024 support change, and the Security Officer is accountable to core.

Teams that matter for security

The administration page lists specialized teams. For risk tracking, four matter most: the Security Officer and Security Team (base system advisories, errata and signing), the Ports Security Team (VuXML entries for third party software), the Release Engineering Team (branches, builds and the release schedule) and the package and ports management teams that build and publish binary packages.

The FreeBSD Foundation

The FreeBSD Foundation is separate from the project. Its own site describes it as "a US-based 501(c)(3) non-profit organization dedicated to supporting the FreeBSD Project and community," funded by individual and corporate donations. The Handbook adds that the Foundation funds development through grants, provides staff for urgent problems and new features, buys hardware for project infrastructure, funds work on testing and continuous integration, and represents the project in contracts and legal agreements that need a legal entity. The Foundation does not run the Security Team or decide release policy; the elected core team and its delegated teams do. In practice, Foundation funded staff do much of the engineering work behind recent changes, and the Handbook names the pkgbasify tool as Foundation sponsored.

Step by step: check your version, patch, and audit packages

The following walkthrough assumes a FreeBSD 14.x or 15.x host installed from release media and updated with freebsd-update (the classic method). Run the commands as root, or with doas or sudo if installed. Read each step before you run it; none of them erase data, but kernel updates require a reboot.

Step 1: find out exactly what you are running

# Installed kernel, running kernel, and userland versions
freebsd-version -kru

# Running kernel only, including the patch level
uname -r

# Architecture
uname -m

freebsd-version -k shows the installed kernel, -r the running kernel and -u the installed userland. If -k and -r differ, a kernel update is installed but you have not rebooted into it. The Handbook says the same thing: compare freebsd-version -k with uname -r, and reboot if they differ.

A typical result looks like 15.1-RELEASE-p2. The part before the dash is the release, and -p2 is the patch level on releng/15.1.

Step 2: check that the release is still supported

Compare the release (not the patch level) with the supported releases table on the FreeBSD security page. On 23 October 2026, only 15.1, 14.5 and 14.4 are supported. If your host reports 15.0, 14.3, 13.x or anything older, freebsd-update fetch will not give you fixes for new advisories. Plan a minor or major upgrade first (Step 6).

Step 3: fetch and install base system security patches

freebsd-update fetch
freebsd-update install

fetch lists the files that would change; install applies them. If a kernel file changed, reboot. If userland binaries changed, restart the affected services (the advisory's Solution section says which). To check daily without applying anything automatically, the Handbook suggests this line in /etc/crontab:

@daily                                  root    freebsd-update cron

With that in place, patches are downloaded but not installed, and root gets an email to review and install them. If a patch set causes problems:

freebsd-update rollback

Two caveats from the Handbook: freebsd-update only updates the GENERIC kernel automatically, so a custom kernel must be rebuilt after updates; and the patch level reported by uname -r comes from /usr/src/sys/conf/newvers.sh, so a custom kernel shows the right patch level only after it is rebuilt.

Step 4: audit third party packages

# Fetch the latest VuXML database, then audit installed packages
pkg audit -F

# Machine readable output for a script or a ticket
pkg audit -F -R json

The pkg-audit(8) manual page says the database is "maintained by port committers and the FreeBSD security team" and that a local ports tree is not needed. The output names each vulnerable package, the CVEs, and a link to the VuXML entry, which gives the affected and fixed port versions. Then update:

pkg update
pkg upgrade
pkg audit -F

Run the audit again after upgrading; anything still listed has no fixed package yet, or depends on a port that has not been rebuilt. For those, decide whether to remove the package, disable the service, or use the workaround the upstream project gives.

Step 5: audit jails too

Each jail has its own package database, so a clean host can still host vulnerable jails. The -j flag runs pkg inside a jail:

# List running jails
jls

# Audit packages inside a jail by name or JID
pkg -j webjail audit -F
pkg -j webjail upgrade

For a jail's base system, the Handbook's jails chapter documents freebsd-update -b and -j, and warns that -b reads the release from the host's uname -r; check which flag fits your layout before patching.

Step 6: upgrade to a supported release

For a minor upgrade on the classic path:

freebsd-update -r 15.1-RELEASE upgrade
freebsd-update install
shutdown -r now
# after reboot
freebsd-update install
pkg upgrade

On ZFS, create a boot environment first with bectl create pre-15.1 so you can roll back. For a major upgrade (for example 14.5 to 15.1), read the release notes and the errata first, especially for retired platforms and removed tools, and upgrade all packages after the new userland is in place, because packages are built against a specific major ABI.

Step 7: on pkgbase hosts

On a host that was installed with pkgbase (the default for 15.x cloud and VM images), base system patches come through pkg:

# See which base packages are installed
pkg info -x '^FreeBSD-' | head

# Update everything, base and third party, from their repositories
pkg update
pkg upgrade

# Then audit third party packages
pkg audit -F

Because the method is still a technology preview in 15.0, follow the Handbook's pkgbase section for your exact release before converting a production host.

Step 8: keep evidence

After each patch window, save the output of freebsd-version -kru and pkg audit -F -R json. That shows a host was on a supported release, at a known patch level, with no known vulnerable packages, on a given date.

Common mistakes

• Treating pkg upgrade as a full system update. On a classic (non pkgbase) host, pkg upgrade does not touch the kernel or base userland. Base OpenSSL, OpenSSH and the kernel are patched only by freebsd-update or a source rebuild.
• Treating freebsd-update as a full system update. The reverse mistake: freebsd-update never updates /usr/local. A fully patched base system can still run a vulnerable database or web server.
• Not rebooting after a kernel advisory. If freebsd-version -k and uname -r differ, the fix is on disk but the old kernel is running.
• Forgetting jails. Jails have their own packages and, depending on how they were built, their own base userland. Audit and patch each one.
• Staying on a .0 or old minor release. Under the "next minor plus three months" rule, 15.0 stopped getting fixes on 30 September 2026. Minor upgrades are not optional on FreeBSD.
• Running CURRENT or STABLE in production and expecting advisories to cover you. STABLE is covered, but only if you rebuild from source; CURRENT gets no advisories at all.
• Assuming i386 has a future. i386 is retired in 15.0; such hosts top out at FreeBSD 14 and its November 2028 end of life.
• Converting to pkgbase without free space or a boot environment. The Handbook warns the migration needs up to 5 GiB and that the tool does not check.

FreeBSD's split between the base system and packages is a reminder that the operating system is only part of what you run: the applications you deploy on a FreeBSD host bring their own npm, pip, Go and Maven dependencies, and those are rebuilt and redeployed every time you patch or migrate. The fit here is indirect, because Safeguard does not patch the FreeBSD base system or the Ports Collection, but the open source code your own applications pull in is where the steps below apply.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. For a team that deploys applications to FreeBSD servers or jails, that is the route for scanning the application repositories and their dependency manifests on a workstation or build machine before the code ships to the host.

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

The second demo is a real CLI session: it asks the assistant to fix a lodash CVE in a repository, and the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow applies to a Node.js service you run in a FreeBSD jail: pkg audit covers the node package itself, while the application's own dependencies need a fix in the repository.

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. If your team already asks an assistant to summarize FreeBSD advisories or plan an upgrade window, this is how the same assistant can also look up findings for the application code you deploy on those hosts.

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

To try it yourself, download Safeguard or read the CLI documentation.

FAQ

What is the latest version of FreeBSD?

As of 23 October 2026, the newest release is FreeBSD 15.1, released on 16 June 2026. The newest release in the 14 series is 14.5, released on 8 September 2026. Under the published schedule, 15.2 is due in December 2026.

How long is a FreeBSD release supported?

A stable branch (major version) is supported for four years from its .0 release starting with FreeBSD 15; FreeBSD 13 and 14 keep five years. A minor release is supported until three months after the next minor release in the same series, which usually means about nine months. The last minor release in a series lives until the stable branch ends.

When do FreeBSD 14 and FreeBSD 15 reach end of life?

stable/14 is supported until 30 November 2028 (14.4 ends 31 December 2026, 14.5 on 30 June 2027, and a planned 14.6 runs to the branch end). stable/15 is supported until 31 December 2029; 15.0 already ended on 30 September 2026 and 15.1 runs to 31 March 2027.

Is FreeBSD 13 still supported?

No. FreeBSD 13.5, the last 13.x release, and the stable/13 branch both reached end of life on 30 April 2026, five years after 13.0.

What is the difference between FreeBSD STABLE, CURRENT and RELEASE?

CURRENT (main) is the development branch and gets no security advisories. STABLE (stable/N) is the branch for a major version, updated with tested changes from CURRENT and covered by advisories if you build from source. RELEASE builds come from releng/N.M branches, which become security branches; most production systems run these and patch them with freebsd-update.

What is the difference between a FreeBSD Security Advisory and an Errata Notice?

A Security Advisory (FreeBSD-SA) fixes a security vulnerability in the base system. An Errata Notice (FreeBSD-EN) fixes a base system bug that is not classified as a security issue, such as time zone data or driver problems. Both are delivered through the same update tools.

Does freebsd-update update installed packages?

No. freebsd-update updates only the base system (kernel and userland). Packages under /usr/local are updated with pkg upgrade and checked with pkg audit -F. On a pkgbase host, pkg updates both, from separate repositories.

What is pkgbase in FreeBSD?

pkgbase is the packaged base system: the FreeBSD kernel and userland published as pkg packages from a FreeBSD-base repository. It was experimental in 14.x, became a technology preview in 15.0, and is the default for official cloud and VM images. Distribution sets are planned for removal in FreeBSD 16.

Quick check

Sources

• FreeBSD Security Information (supported releases and support model)
• FreeBSD Unsupported Releases
• FreeBSD Security Advisories index
• FreeBSD Errata Notices index
• FreeBSD Security Officer Charter
• FreeBSD Release Information
• freebsd-announce: FreeBSD support model changes (11 July 2024)
• FreeBSD Handbook, Chapter 1: Introduction (history and governance)
• FreeBSD Handbook: Updating and Upgrading FreeBSD (freebsd-update and pkgbase)
• FreeBSD Handbook: Security (pkg audit, advisories, Capsicum)
• FreeBSD Handbook: Jails and Containers
• FreeBSD Handbook: Mandatory Access Control
• FreeBSD Handbook: Packages and Ports
• FreeBSD Project Administration and Management (core team and teams)
• FreeBSD 15.0-RELEASE Announcement
• FreeBSD 15.0-RELEASE Release Notes
• FreeBSD 14.0-RELEASE Announcement
• FreeBSD 14.0-RELEASE Release Notes
• FreeBSD 13.2-RELEASE Release Notes
• FreeBSD 13.0-RELEASE Announcement
• FreeBSD 13.0-RELEASE Release Notes
• FreeBSD 12.0-RELEASE Announcement
• FreeBSD 11.0-RELEASE Announcement
• FreeBSD 10.0-RELEASE Announcement
• FreeBSD 9.0-RELEASE Announcement
• FreeBSD 8.0-RELEASE Announcement
• FreeBSD 7.0-RELEASE Announcement
• FreeBSD 5.0-RELEASE Announcement
• FreeBSD 4.0-RELEASE Announcement
• jail(8) manual page
• mac(4) manual page
• capsicum(4) manual page
• freebsd-update(8) manual page
• pkg-audit(8) manual page
• FreeBSD VuXML
• Capsicum: practical capabilities for UNIX (University of Cambridge)
• The FreeBSD Foundation: About the Foundation

Last reviewed: 23 October 2026. FreeBSD support dates and patch levels change every quarter; check the FreeBSD security page and the advisories index before planning an upgrade.