How FreeBSD dey Handle Security Updates

FreeBSD dey handle security updates

FreeBSD dey handle security updates with two separate tools, because FreeBSD server na two separate things. The base system, meaning the kernel and the userland wey come with the release, dey receive patches with freebsd-update. Everything wey you install on top of am na package, and pkg dey patch packages. If you run one and skip the other, half of the machine go remain unpatched, and nothing for the system go tell you.

SSD Nodes no dey offer FreeBSD images. Our plans dey run Linux. This post still dey useful because the readers overlap completely: people wey dey run our Ubuntu and Debian servers also dey run FreeBSD for firewall or for the one machine wey dem inherit. The split patching model na the part wey dey catch Linux admin, so na that part wey worth writing down. We check every command, advisory format, and support date against the FreeBSD security page and the project's manual pages for August 2026.

One thing before the commands. FreeBSD no dey install sudo for the base system. Everything here need root. Use su -, or first install sudo or doas from packages.

Base system and packages na separate worlds

For Ubuntu, apt dey control the whole machine. Kernel, openssl, nginx and your own tools all dey come as .deb files from one tool, and apt upgrade dey move all of dem together.

FreeBSD dey divide this into two parts. Dem build and version the base system as one unit: 15.1-RELEASE-p3 na one number wey cover kernel, C library, sshd and the OpenSSL copy for /usr/lib. None of dem dey come from pkg. Everything else dey under /usr/local, dey come as binary package wey dem build from ports tree, and e get im own version.

So one machine fit get two OpenSSL copies: the base copy for /usr/lib, wey na only freebsd-update fit patch, and the package copy for /usr/local/lib, wey na only pkg fit patch. The copy wey program go use depend on the one wey dem link am against, and software wey dem install from packages normally dey link the package copy. If you patch one, e no go affect the other.

Three commands fit show you the current state:

freebsd-version -u
freebsd-version -k
uname -r

freebsd-version -u dey print patch level of the installed userland. freebsd-version -k dey print patch level of the installed kernel, and freebsd-version(1) clearly explain why e no be the same as uname: "if a new kernel has been installed but the system has not yet rebooted, freebsd-version will print the version and patch level of the new kernel". uname -r dey print the kernel wey dey run now. freebsd-version -r dey also print the running kernel, but e be "unaffected by environment variables". This matter inside a jail, where UNAME_r often dey set to another value.

Security Advisories and Errata Notices

Notice wey FreeBSD Security Team dey publish come for two types, and each one get different meaning.

A Security Advisory dey cover security vulnerability for the base system. The identifier dey look like FreeBSD-SA-26:55.elf: the letters SA, the two-digit year, one number wey dey count up for that year, then the affected component. FreeBSD-SA-26:52.if_wg and FreeBSD-SA-26:50.kqueue both publish for 2026-07-29. Full list dey for FreeBSD advisories page.

An Errata Notice dey cover correctness or stability problem wey worth pushing go release branch, but e no get security impact. E get the same format, with EN for place of SA: FreeBSD-EN-26:19.zfs, FreeBSD-EN-26:18.tzdata. Time zone data update na the classic example. Nobody fit attack you with stale time zone data, but your timestamps go wrong until you apply the fix. Errata dey listed for FreeBSD errata notices page.

Both types get signature with Security Officer's PGP (pretty good privacy) key, and dem dey archived for security.FreeBSD.org. Both dey delivered go your machine through freebsd-update.

Na this part dey catch Linux admins. Neither type cover packages. The security page talk am clearly: problems for FreeBSD Ports Collection "are covered separately in the FreeBSD VuXML document". Remote vulnerability for nginx package no go ever receive SA number. If advisory feed na the only thing wey you dey monitor, you no go ever hear about am.

How I fit hear about FreeBSD security update?

The list to join na freebsd-security-notifications. Dem dey moderate am, and traffic for there low. Na there advisories and errata notices dey come directly. Subscribe for lists.freebsd.org.

freebsd-announce sef dey moderated, and e dey carry advisories together with release announcements. E good if you want one list for everything. freebsd-security na the discussion list. E useful to read, but no be there you go learn say you need patch.

All these lists dey carry base system news only. Package vulnerabilities no dey arrive by mail. You go find dem when you run command.

pkg audit, and di database wey e use

VuXML, wey mean Vulnerabilities and Exposures Markup Language, na FreeBSD project record of security problems for ports and packages. Each entry name the affected package, the version ranges wey get vulnerability, the CVE (common vulnerabilities and exposures) identifiers, and short description. You fit browse the complete set for VuXML index, and sort am by package, CVE, or date.

pkg audit na the tool wey dey read am:

pkg audit -F

-F go fetch fresh copy of the database before e check. Use am every time. If you no use -F, the check go match against the copy wey the machine already get. That copy fit don stale for months, so clean result no mean anything. The command dey compare every installed package version with every VuXML entry. E dey print each match with the CVE numbers and link to the VuXML page. Then e go end with count line wey tell you how many problems e find for how many installed packages.

Two more flags from pkg-audit(8) dey useful to know. pkg audit -r dey also “prints packages that depend on vulnerable packages and are thus potentially vulnerable as well”. Na so you go know say vulnerable library matter because six installed things dey link to am. pkg audit -R dey print the same result as JSON or another machine format. Na this format you fit give monitoring check.

The pkg package dey install periodic script for /usr/local/etc/periodic/security/410.pkg-audit. E dey run as part of the daily security check and e dey mail the result to root. Confirm say e dey enabled with one line for /etc/periodic.conf:

daily_status_security_pkgaudit_enable="YES"

That daily mail na the closest thing wey FreeBSD get to the unattended-upgrades habit for Ubuntu. The difference na the main point: unattended-upgrades dey install the fix while you sleep, but pkg audit only dey tell you say fix dey needed. pkg audit dey report. E never dey patch. Nothing for standard FreeBSD system dey install security update without you.

Fixing a vulnerable package

pkg update
pkg upgrade

FreeBSD package repositories no get security-only pocket. Ubuntu fit pull from noble-security alone and leave every other package as e dey. FreeBSD no get equivalent, so to fix one vulnerable package mean say you go take the version wey repository dey offer now, plus any dependencies wey move with am. Plan package patching as a change, no be background job.

The repository branch wey you dey use determine how fast fix go reach you. The default na quarterly branch, wey the handbook describe as giving "a more predictable and stable experience" because e only accept non-feature updates. The latest branch dey take the newest version of everything. So when pkg audit -F report say package get vulnerability and pkg upgrade say nothing dey to do, the fix never reach your branch yet. Na this cause the confusion.

To move machine go latest branch, copy the repository file wey come with the system, then edit the copy:

mkdir -p /usr/local/etc/pkg/repos
cp /etc/pkg/FreeBSD.conf /usr/local/etc/pkg/repos/FreeBSD.conf

Change quarterly to latest for the url line inside the copy, then run pkg update -f to pull the new catalogue. Copy the file instead of typing the repository name from memory: the name inside /etc/pkg/FreeBSD.conf na the one wey your system actually dey use, and file under /usr/local/etc/pkg/repos only overrides repository wey get exactly the same name.

Applying base system patches

freebsd-update fetch
freebsd-update install

fetch go download patches for your current release and print the list of files wey e go change. If nothing dey to do, e go print No updates needed to update system to 15.1-RELEASE-p3. and exit. If something dey to do, e go finish by telling you to run the install command. Nothing go apply until you run freebsd-update install, so fetch safe to run anytime.

freebsd-update(8) dey provide binary updates for ALPHA, BETA, RC and RELEASE versions, but e no dey provide updates for PRERELEASE, STABLE or CURRENT. If you dey track stable/15, you build from source, so this tool no get anything for you.

Automate the download, but keep the install manual. The handbook line for /etc/crontab na:

@daily                                  root    freebsd-update cron

freebsd-update cron go sleep for random time between 1 and 3600 seconds, then download updates exactly as fetch dey do, and mail root when something dey wait. The random sleep dey prevent every FreeBSD machine for internet from hitting the update mirrors for the same second.

Two things for the output dey confuse people. src component not installed, skipped normal for server wey no get source tree, and e no be error. A Components line inside /etc/freebsd-update.conf dey control the components wey e go update. The available choices na src, world and kernel.

If install get problem, freebsd-update rollback go uninstall the updates wey you install most recently. If your root dey on ZFS, you fit do better by creating boot environment first:

bectl create pre-patch
freebsd-update fetch install

If the patched system no boot, select the old boot environment from the loader menu, and you go return to where you start. This escape option na one practical reason to run ZFS as the root filesystem, and e use almost no disk space until the two environments diverge.

My FreeBSD release still dey supported?

Every release get fixed support period. Dem publish am for branch table on the security page. As of August 2026, the table na this:

• releng/15.1, wey be 15.1-RELEASE, until 31 March 2027
• releng/15.0, wey be 15.0-RELEASE, until 30 September 2026
• releng/14.4, wey be 14.4-RELEASE, until 31 December 2026
• stable/15 until 31 December 2029
• stable/14 until 30 November 2028

Point releases get short support periods. 15.0-RELEASE go expire about seven weeks after dem write this post, because 15.1 ship and put am on countdown. Stable branches last for years, and dem na source branches wey freebsd-update no serve.

Check your own with freebsd-version -u and compare am with the table. freebsd-update go warn you too. As the date dey near, fetch go print:

WARNING: FreeBSD 15.0-RELEASE is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.

After the date pass, the warning go become WARNING: FreeBSD 15.0-RELEASE HAS PASSED ITS END-OF-LIFE DATE.. Unsupported release still dey work. But e no go receive security advisories again, so any new vulnerability for the base system na your problem forever.

To move up to another release, run freebsd-update -r 15.1-RELEASE upgrade, then freebsd-update install, reboot, then run freebsd-update install again. After that, use pkg-static upgrade -f to reinstall every package against the new libraries, then run final freebsd-update install. The handbook talk say e fit be only two install phases instead of three, depending on whether any library version numbers change. Schedule maintenance window, and read FreeBSD 15 server setup guide before you start.

Reboot, abi service restart don do?

FreeBSD dey answer this with one comparison:

freebsd-version -k
uname -r

freebsd-version -k na the kernel wey dey disk. uname -r na the kernel wey dey memory. If the strings no match, e mean say dem install new kernel but you never dey run am, so reboot. If the strings match, the patch no touch kernel, and reboot no go add anything.

For userland patch, restart anything wey dey use the patched code. Fix wey dem apply to the base OpenSSL for /usr/lib no go affect sshd wey start three weeks ago and still get the old library mapped for im address space. The file for disk don new. The running process no new.

service sshd restart

The same rule apply to packages. pkg upgrade replace the binary for disk while the running process still get the old one open, so service nginx restart na the step wey make the fix take effect.

The base system no get anything like Debian's needrestart, so nothing go prompt you and nothing go keep list. You fit track which services link each patched library, or reboot after any patch wey touch base libraries. For server wey keep im configuration for version control, reboot na normal operation, and e cheaper pass to think say you don patch when you never patch am.

Machine wey dey run jails patch

Jail dey share host kernel, so kernel advisory na host problem, and every jail for that box go inherit am. Patch host and reboot am, then kernel side don complete for all of dem. Userland wey dey inside each jail na separate installation with its own patch level, and freebsd-version -j <jail> dey report am from host. Packages wey dey inside jail separate too, and pkg -j <jail> audit -F dey audit dem without entering the jail. That shared kernel and separate userland split na the same structural difference wey shape how jails compare with Docker containers.

The Ubuntu translation

Each FreeBSD habit get one equivalent, so you fit carry the same routine for either direction.

• Base system patches: freebsd-update fetch then freebsd-update install. For Ubuntu, na apt update && apt upgrade, wey dey cover the base system and everything else at once.
• Third party software: pkg update && pkg upgrade for FreeBSD. For Ubuntu, na apt again.
• Known vulnerability check: pkg audit -F for FreeBSD. For Ubuntu 24.04, the nearest command na pro security-status, wey dey show security updates for installed packages, including Expanded Security Maintenance content.
• Automatic installation: unattended-upgrades for Ubuntu go apply security updates for you. FreeBSD no get anything equivalent by default, so freebsd-update cron go download and send mail while you install updates by hand.
• Advisory feed: freebsd-security-notifications dey carry FreeBSD-SA and FreeBSD-EN items. ubuntu-security-announce dey carry Ubuntu Security Notices.
• Vulnerability database: VuXML for FreeBSD ports and packages. Ubuntu CVE tracker for Ubuntu packages.
• Reboot check: freebsd-version -k against uname -r for FreeBSD. For Ubuntu, check whether /var/run/reboot-required dey present.
• Support window: the branch table for the FreeBSD security page. For Ubuntu, na the release schedule and pro security-status.

The main routine dey the same for both systems: subscribe to the feed, run the audit on schedule, then decide wetin to install and when to restart. FreeBSD just make you talk the second part clearly, because e no go do am for you. The wider comparison of Linux and FreeBSD as server platforms cover other things wey change when you move workload between dem.

FAQ

FreeBSD update fit patch my packages too?

No. freebsd-update na base system only, meaning the kernel and the userland wey come with the release. Software wey dem install under /usr/local come from packages, and dem dey patch am with pkg upgrade. Run pkg audit -F to find which installed packages get known vulnerabilities, because base advisories no dey mention dem and security mailing lists no dey announce dem.

How I fit know whether FreeBSD update need reboot?

Compare freebsd-version -k with uname -r. The first one print the kernel wey dey installed for disk, including one wey dem just write but system never boot from am. The second one print the kernel wey dey run. If the strings different, you need reboot. If the strings match, the patch na userland only, so restart the affected services instead, for example service sshd restart, because running process keep the old library mapped until e restart.

Wetin be the difference between Security Advisory and Errata Notice?

Security Advisory, like FreeBSD-SA-26:55.elf, fix security vulnerability for the base system. Errata Notice, like FreeBSD-EN-26:18.tzdata, fix correctness or stability problem wey no get security impact, like outdated time zone data. Both use the pattern year, colon, sequence number, component. Security Officer sign both, and freebsd-update deliver dem. Neither one cover software wey dem install from ports or packages.

FreeBSD get equivalent of unattended-upgrades?

No, e no dey for the base system. freebsd-update cron download pending base patches and send mail to root, but e never install dem. The periodic script wey pkg install run pkg audit every day and send the result by mail, but e never upgrade anything. You go need build unattended installation yourself with a cron job. Since FreeBSD package upgrade take the newest version instead of security-only backport, most admins read the mail and install am by hand.

How I fit check whether my FreeBSD release still get support?

Run freebsd-version -u to see your userland version, then compare am with the supported branch table for the FreeBSD security page. Point releases get short support windows: as of August 2026, 15.0-RELEASE end on 30 September 2026, while 15.1-RELEASE continue reach 31 March 2027. freebsd-update fetch warn you as the date dey near. Once the date pass, e print one line say the release HAS PASSED ITS END-OF-LIFE DATE. After that time, no further advisories apply to you.