NetBSD Release History: Every Major Version, pkgsrc and Security Support

NetBSD has shipped nineteen major releases, from NetBSD 0.8 on 20 April 1993 to NetBSD 11.0 on 30 July 2026. The project supports two major branches at a time, today netbsd-10 and netbsd-11, and a major release "generally becomes unsupported one month after the release date of the second succeeding major release." Base system security fixes arrive through signed NetBSD Security Advisories, while third party software comes from pkgsrc and is checked against the signed pkg-vulnerabilities file with pkg_admin audit.

As of this writing (24 October 2026), the NetBSD releases page lists NetBSD 11.0 and NetBSD 10.2 (released 15 September 2026) as the supported releases. The NetBSD 9 branch reached end of support on 31 August 2026, the same day its final point release, 9.5, shipped. NetBSD 8 ended on 4 May 2024. On the package side, pkgsrc-2026Q3, the 92nd quarterly pkgsrc release, was announced on 23 September 2026. If a host runs NetBSD 9.x or older, it no longer receives base system fixes of any kind.

This post sits alongside our FreeBSD and OpenBSD release histories; our Debian and Alpine posts answer the same questions for Linux. NetBSD is the BSD that cares most about running on many kinds of hardware, and that goal explains its cadence, its support rule and why pkgsrc runs on other operating systems too.

Key takeaways

• NetBSD was founded in 1993 from the Net/2 and 386BSD code base. Its first release, 0.8, is dated 20 April 1993, and its original focus was "quality and architecture independence."
• The project counts nineteen major releases: 0.8, 0.9, 1.0 through 1.6 under the old numbering, then 2.0 through 11.0.
• Two major branches are maintained at once. A series ends about one month after the second succeeding major ships, so 11.0 (30 July 2026) ended NetBSD 9 on 31 August 2026. There is no fixed number of years.
• Each major has a stable branch (netbsd-10) for minor releases and each release has a security/critical branch (netbsd-10-1) for teeny releases. NetBSD-current is versioned N.99.M and gets no advisories.
• pkgsrc holds over 26,000 packages, runs on Linux, macOS and illumos as well as NetBSD, and cuts a security only stable branch every quarter. Its signed pkg-vulnerabilities file held 30,422 entries on 24 October 2026; pkg_admin audit checks against it.
• Security features arrived in this order: Veriexec and PaX MPROTECT (4.0), ASLR support (5.0), NPF (6.0), blacklistd, now blocklistd (7.0), mitigations on by default (8.0), kernel ASLR (9.0), Argon2id and a WireGuard compatible driver (10.0), NPF layer 2 and user or group rules (11.0).

Where did NetBSD come from?

The project's history page says NetBSD "took its roots from the original UCB 4.3BSD via the Net/2 release and 386BSD." It was founded by Chris Demetriou, Theo de Raadt, Adam Glass and Charles M. Hannum, and the page gives the reason: frustration with the quality of patches circulating for 386BSD, and the difficulty of getting them accepted, led to the project's founding in 1993. Its original focus was quality and architecture independence; the same page notes that FreeBSD "was formed later with a focus on the i386 PC platform."

NetBSD 0.8 is dated 20 April 1993, followed by 0.9 on 23 August 1993 and 1.0 on 26 October 1994. The project later imported code from 4.4BSD Lite, and its code became the base of other systems; the history page names Apple's Rhapsody and Force 10's FTOS. OpenBSD's history also begins as a NetBSD fork in 1995. The BSD license terms NetBSD inherited are a big part of why its code turns up in products; our BSD 3-clause license explainer covers what they ask of anyone who ships it.

Who runs NetBSD today?

The NetBSD Foundation, Inc. is a Delaware non-profit under section 501(c)(3) of the US Internal Revenue Code. Its foundation page says it owns several project servers, handles donations and administers NetBSD copyrights. Its Board of Directors is elected by the NetBSD developer community. Two groups matter for this post:

• The core group (core@NetBSD.org) decides technical questions such as which tier a hardware port belongs to.
• The security groups. Security issues "are handled by three groups: the Security Team, the Security Alert Team, and the Security Officer." Reports go to the Security Alert Team, sensitive ones encrypted to the Security Officer's PGP key, which also signs every release's hash list. pkgsrc has its own team, pkgsrc-security, which signs the package vulnerability list.

Every major version: dated timeline

The table below uses the release history table on the NetBSD formal releases page and the release announcement list on the project's history page, both fetched on 24 October 2026. "Last point release" is the final minor or teeny release in each series. The end of support column is filled in only where the formal releases page states a date; for older series it is blank on that page and we say so.

Two date notes. The formal releases table dates NetBSD 7.0 to 25 September 2015, while the announcement list on the history page says 25 August 2015; we use the formal table. The history page also lists NetBSD 10.2 (15 September 2026), which the releases index and the 10.2 announcement confirm, but the history table on the formal releases page had not yet added a 10.2 row when we fetched it.

The 1.x years and the old numbering scheme

Before 2.0, majors were numbered 1.0 to 1.6 and minors like 1.4.3, while NetBSD-current carried letters such as 1.6ZA, according to the release glossary. That is why the count of nineteen majors includes 0.8, 0.9 and every 1.x release.

2.0 to 4.0: threads, SMP and the first hardening

The 2.0 announcement said two long standing goals had been met: native threads on all platforms, and SMP on i386, SPARC and PowerPC, with the new amd64 port also supporting SMP. 2.0 also introduced security/critical releases, still the backbone of NetBSD maintenance. NetBSD 3.0 added the PAM framework and Xen 2.0 support across 57 system architectures. NetBSD 4.0 reads like the first security release: mprotect restrictions to enforce W^X (from PaX), the kauth framework, and Veriexec improvements so it "can be used to harden the system against trojan horses." paxctl first appeared in 4.0.

5.0 and 6.0: scalability, journaling and NPF

NetBSD 5.0 rebuilt the internals for multicore machines: 1:1 threading, kernel preemption and a rewritten scheduler. It added wapbl(4), "a preview of metadata journaling for FFS" contributed by Wasabi Systems, ASLR support "in the kernel and dynamic linker," and rump_nfs(8), an early rump kernel tool. NetBSD 6.0 introduced NPF; its manual page says NPF "was written from scratch in 2009," by Mindaugas Rasiukevicius, and "first appeared in NetBSD 6.0." 6.0 also made time_t and dev_t 64 bit on every port, years before many systems dealt with 2038.

7.0 and 8.0: multiprocessor ARM, blocklistd and default mitigations

NetBSD 7.0 added multiprocessor ARM, BPF JIT by default, multiprocessor USB, Lua kernel scripting and blacklistd(8), a daemon that tells the packet filter to block abusive clients. It is now blocklistd(8), whose manual page says it "first appeared in NetBSD 7." NetBSD 8.0 turned mitigations on by default: PaX MPROTECT on i386, amd64, evbarm and landisk, PaX ASLR on those plus sparc64, and PIE userland on several architectures. Shipping after Meltdown and Spectre, it enabled SVS for Meltdown, used retpoline for Spectre v2 and added SMAP.

9.0 and 10.0: AArch64, NVMM, kernel ASLR and modern crypto

NetBSD 9.0 added AArch64, the NVMM hypervisor, kernel ASLR on 64 bit x86 through GENERIC_KASLR (partial in GENERIC), kernel sanitizers, and said "NPF is now enabled by default." ZFS became "usable for daily use," but not as root. NetBSD 10.0 came more than four years later, the longest gap between majors, which is why NetBSD 9 lived so long. It added wg(4), a VPN interface "compatible with the WireGuard specification" (experimental), Adiantum for cgd(4) disk encryption, Argon2id as the default password hash, automatic swap encryption via vm.swap_encrypt=1, constant time kernel AES, and the Armv8-A protections Privileged Access Never, Pointer Authentication and Branch Target Identification.

11.0: RISC-V and a new kernel for microVMs

The 11.0 announcement calls it the first stable release with 64 bit RISC-V support (StarFive JH71XX boards and QEMU). It adds POSIX.1-2024 and C23 work, more Linux system calls in compat_linux(8), initial Snapdragon X Elite support, a MICROVM x86 kernel the project says boots in about 10 ms on 2020 era CPUs, and a virt68k port. Security relevant changes: NPF layer 2 and user or group filtering, a blocklistd configuration directory, PaX MPROTECT and ASLR on by default on macppc, and the stack protector on by default on MIPS. It ships OpenSSL 3.5.7, GCC 12.5.0 and binutils 2.42. Among incompatible changes, the new OpenSSH "does not support DSA keys any more," and 32 bit and 64 bit compatibility libraries moved into new base32/base64 and debug32/debug64 sets. build.sh gained a pkg=CATEGORY/PACKAGE target that cross builds a pkgsrc package.

How does the NetBSD release and support model work?

NetBSD's release glossary page describes three forms of the system: formal releases, maintenance branches and NetBSD-current. Getting this vocabulary right is most of the work of understanding NetBSD support.

Formal releases: major, minor and teeny

A formal release is "an official, believed to be reliable, source and binary distribution." There are three kinds:

• Major releases such as 10.0 or 11.0.
• Minor releases, sometimes called maintenance or stable releases, such as 10.1 and 10.2.
• Security/critical releases, sometimes called teeny releases, such as 6.1.5.

Maintenance branches: stable and security/critical

Every major has a stable branch named after it. When 10.0 shipped, its branch was netbsd-10, which "will give rise to" 10.1, 10.2 and later minors; builds between releases show versions like 10.1_STABLE. Each major and minor release also gets a security/critical branch from its release point (for 6.0, the tag netbsd-6-0), which only takes fixes for security or other critical problems, so you get the fix without other changes. Builds there show versions like 6.1.0_PATCH. The glossary notes that following the maintenance branches is "an easy way to get the most up-to-date fixes," and the project publishes daily or weekly binary builds of netbsd-10 and netbsd-11 that advisories point to.

NetBSD-current

NetBSD-current is the development branch, versioned N.99.M; 7.99.21 eventually became 8.0. The glossary calls it "normally an alpha quality distribution," and the project issues no advisories for it.

The support rule, in the project's words

The formal releases page states:

A NetBSD major release, including all minor releases of the major release, generally becomes unsupported one month after the release date of the second succeeding major release.

The project says it will revisit the policy if majors come much closer together. The releases page lists the 11.x series (11.0) and the 10.x series (10.2) as supported, warns that anything older "will not receive any bug fixes, including security fixes," and explains that "changes made to NetBSD 11.0 will appear in 11.1."

How the rule played out

The policy says "generally," and the record shows some flexibility. This table compares each ended series with the major release that triggered its end, using the formal releases table.

The last two series ended with a final point release on their end of support date, and the 10.2 announcement says 9.5 "will be the final release from the netbsd-9 stable branch." Because the end date depends on when the second next major ships, support length varies: NetBSD 9 ran from February 2020 to August 2026, about six and a half years, because 10.0 took over four years. There is no published end date for NetBSD 10; expect it to end about a month after 12.0, and plan to be on 11.x before then.

Why is portability NetBSD's identity?

Ports and the tier system

NetBSD calls each supported hardware platform a port. The ports page groups them into three tiers, decided by core@NetBSD.org "based on input from users and developers":

Most Tier II ports list 11.0 as their latest release, so Digital VAX machines, Sega Dreamcast consoles and Sun 3 workstations all have a current, supported NetBSD. One inconsistency: the 11.0 announcement describes RISC-V as a new port with release images, but the ports page we fetched did not yet list it. Treat the announcement and download directory as the authority.

How one source tree reaches 50 plus platforms

Most of the kernel is machine independent, and drivers are written against bus abstractions, so one driver serves many ports; the 11.0 announcement has a whole section of new "Machine-independent device drivers." The other half is build.sh, which cross compiles the whole system, toolchain included, from any supported host. That is how a volunteer project produces release images for dozens of architectures. In practice NetBSD runs on servers and VMs (amd64, Xen, the MICROVM kernel, its own NVMM hypervisor), Arm boards (Raspberry Pi 4 and 5 with UEFI, Rockchip, Allwinner, Apple M1), embedded products and network equipment, and vintage hardware.

Rump kernels: portability turned into a security tool

Rump kernels run NetBSD kernel components, such as file system drivers, as ordinary userspace processes. The NetBSD wiki explains the security use: "whenever an untrusted file system image is mounted using an in-kernel driver, system compromise should be expected." Mounting with -o rump (or rump in /etc/fstab) runs the driver in userspace instead, so damage from a malicious image "is restricted to a userspace process." NetBSD 10.0 also ships a userspace WireGuard compatible implementation built on a rump kernel server.

What is pkgsrc, and why does it run on other operating systems?

pkgsrc is NetBSD's package framework. Its home page describes it as "a framework for managing third-party software on UNIX-like systems, currently containing over 26,000 packages." It is the default package manager of NetBSD and SmartOS, and it can build software on many other systems.

Why it is portable

pkgsrc was built for a project that runs on dozens of CPU types, so it never assumed one platform. The site lists four primary platforms with active bulk builds (NetBSD, Solaris/SmartOS/illumos, Linux and macOS) and says code exists for "20+ Unix-like operating systems and 15+ CPU architectures." Off NetBSD, you bootstrap pkgsrc into its own prefix, such as /opt/pkg-2026Q3. Teams use this to keep the same package names, options and versions across mixed fleets. On NetBSD the usual front end is pkgin, "an apt / yum like tool for managing pkgsrc binary packages," on top of pkg_add, pkg_info and pkg_admin; source builds use bmake in a package directory.

Quarterly branches

The pkgsrc guide says the stable branch "is forked on a quarterly basis from the current branch and only gets modified for security updates," and is named for the year and quarter, such as pkgsrc-2026Q2.

The active quarterly branch receives security pull ups: NetBSD-SA2024-002 lists fix dates for both pkgsrc-current and pkgsrc-2024Q2. Once the next branch is cut, move to it, or packages on the old branch stop getting fixes.

The pkg-vulnerabilities file

The pkgsrc Security Team keeps one list of known vulnerabilities for packages that are, or have been, in pkgsrc, at https://cdn.NetBSD.org/pub/NetBSD/packages/vulns/pkg-vulnerabilities. The copy we fetched on 24 October 2026 carried revision 1.806 dated 2026/10/21, a PGP signature, and this rule in its header:

NEVER remove entries from this file; this should document all known package vulnerabilities

Each entry has a package pattern (such as openssh<9.8p1), an exploit type and an advisory URL. We counted 30,422 entries; the most common types were denial-of-service (7,438), multiple-vulnerabilities (2,201) and cross-site-scripting (1,636). The vulnerability list and a separate package end of life database are both signed with the pkgsrc-security GPG key. The pkgsrc guide adds that "not every 'vulnerability' with a CVE assignment is exploitable in every configuration," so an audit hit is a reason to look, not proof of exposure.

The pkg_admin(1) manual page documents the commands that read it:

• fetch-pkg-vulnerabilities [-su]: download and check the file; -s verifies the signature, -u downloads only if newer.
• audit [-eis] [-t type]: check installed packages; -s verifies the signature, -e also reports end of life packages, -t filters by type.
• audit-pkg and audit-batch: check named packages or a list, useful in build pipelines.
• audit-history: every recorded vulnerability for a package base name.

The pkgsrc guide says fetch_pkg_vulnerabilities=YES in /etc/daily.conf makes the daily security script fetch the list, and the system audits packages by default.

Which security features does NetBSD ship?

The NetBSD security page summarises the security features as IPsec, the NPF firewall, the Veriexec file integrity system, the kauth kernel authorization framework and CGD disk encryption, "among others." For exploit mitigations it lists "W^X (in both userland and the kernel), Userland ASLR, Kernel ASLR, SMEP, SMAP," and notes that support sometimes depends on the hardware. It also states that "no services are enabled by default for new installations." The security(7) manual page is the practical guide.

Veriexec in more depth

The veriexec(8) manual page describes Veriexec as "an in-kernel, real-time, file-system independent, file integrity subsystem" with uses including "defense against trojaned binaries." It needs a signatures database, generated with veriexecgen(8) and loaded with veriexecctl(8), and a kernel with fileassoc support and SHA-256, SHA-384 or SHA-512 fingerprint options. It runs at four strict levels:

• Level 0, learning mode: no enforcement; the only level at which the fingerprint tables can be changed.
• Level 1, IDS mode: monitored files cannot be removed, and access to files whose fingerprint does not match is denied. Writes are still allowed.
• Level 2, IPS mode: everything in level 1, plus write access to monitored files is denied and access types are enforced.
• Level 3, lockdown mode: everything in level 2, plus access to files that are not monitored is denied and new files cannot be created. The manual page describes it as "high assurance integrity for the entire system."

The point of Veriexec is narrow and useful: it detects and blocks changes to the binaries and configuration you chose to monitor. It does not tell you whether those binaries had known vulnerabilities before you fingerprinted them, which is the job of advisories and pkg_admin audit.

PaX ASLR, NPF and blocklistd in practice

security(7) explains that PaX ASLR randomizes only the stack for non-PIE executables, but the program base, shared libraries, data segment and stack for PIE executables, which is why 8.0's PIE userland mattered as much as turning ASLR on. Programs that generate code at runtime may need MPROTECT disabled per binary with paxctl; the page names the JVM. NPF is a stateful layer 3 filter for IPv4 and IPv6 with NAT, NPTv6, tables and BPF JIT. blocklistd(8) receives notices from daemons such as sshd about failed connections and, once an address crosses the configured limit, runs a control script that adds a packet filter block rule, removing it when the duration expires.

How are NetBSD security advisories published, and how do you check that a system is patched?

When serious problems are found and fixed, the project issues a Security Advisory "describing the problem and containing a pointer to the fix," PGP signed and sent to the netbsd-announce and security-announce lists, archived online and in an RSS feed. The security team may delay an advisory so that "one unique, comprehensive Security Advisory covering several vulnerabilities can be issued," but fixes still go into stable branches as fast as possible. No advisories are issued for NetBSD-current.

The advisory archive lists 289 advisories, from NetBSD-SA1998-001 to NetBSD-SA2024-002, as of 24 October 2026. The yearly count peaked early (27 in 2002, 26 in 2006) and has fallen: 15 in 2014, 6 in 2016, 3 in 2020, 7 in 2023 and 2 in 2024, with none listed for 2025 or 2026. That is what the archive shows, not a measure of fixes: many base fixes land in stable branches with a release note, and package issues go into pkg-vulnerabilities.

Reading an advisory

Advisories follow a fixed layout. Using NetBSD-SA2024-002, the most recent in the archive, as a format example: a Topic and Severity; a Version block listing each affected line (NetBSD-current, each supported release, and pkgsrc with its affected range); a Fixed block with a date per branch, including pkgsrc-current and the active quarterly branch; a reminder of unsupported releases; plain language Abstract and Technical Details; and Solutions and Workarounds, which offer a configuration workaround, the pkgsrc version of the component, fixed binaries from a release branch build dated after the fix, or a source rebuild. The Fixed block is the key: the question is whether your system was built from sources dated on or after the fix on your branch.

Checking a system

# Which release and kernel is this?
uname -srm
sysctl kern.version     # shows the kernel version string and build date

# Is the release still supported? Compare with the releases page:
#   supported today: 11.0 and 10.2 (10.x series)

Then:

1. Compare the release with the supported list on the releases page. If it is 9.x or older, stop here: no further fixes will come, and the answer is an upgrade.
2. For each advisory that names your branch, compare the fix date with the build date of your kernel and userland. A system installed from 10.2 release sets has everything fixed on netbsd-10 before 10.2 was built, but not fixes committed afterwards.
3. Check packages separately with pkg_admin audit. Base system advisories never cover pkgsrc packages, and package audits never cover the base system.

Step by step: install, add packages, audit and upgrade

The walkthrough below targets an amd64 machine and NetBSD 11.0. Adjust the architecture and version for your hardware. Run commands as root on the NetBSD host unless noted.

Step 1: download the image and the signed hash list

On any machine with curl:

curl -O https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0/images/NetBSD-11.0-amd64-install.img.gz
curl -O https://cdn.netbsd.org/pub/NetBSD/security/hashes/NetBSD-11.0_hashes.asc

The release announcement links that hash list as "Hashes, signed with the NetBSD Security Officer's PGP key, of all files in the distribution." It contains SHA1, SHA512 and RMD160 lines for every file in the release.

Step 2: verify the signature, then the checksum

Import the NetBSD Security Officer's PGP key from the link on the NetBSD security page, and confirm its fingerprint through a second channel before you trust it. Then:

gpg --verify NetBSD-11.0_hashes.asc

expected=$(grep '^SHA512 (NetBSD-11.0/images/NetBSD-11.0-amd64-install.img.gz)' \
  NetBSD-11.0_hashes.asc | awk '{print $NF}')
actual=$(shasum -a 512 NetBSD-11.0-amd64-install.img.gz | awk '{print $1}')
[ "$expected" = "$actual" ] && echo "checksum OK" || echo "checksum MISMATCH"

On Linux you can use sha512sum instead of shasum -a 512. On NetBSD, cksum -a sha512 does the same job. Do not continue on a mismatch or a bad signature.

Step 3: write the image to a USB stick

Warning: this step destroys everything on the target device. Writing to the wrong device path will wipe that disk without asking. Unplug other removable drives first, then identify the stick by its size and model before you run dd.

Check the device path first:

# Linux
lsblk -o NAME,SIZE,MODEL,TRAN
# macOS
diskutil list
# NetBSD
sysctl hw.disknames
dmesg | grep -i sd

Only when you are certain which device is the USB stick (for example /dev/sdX on Linux, /dev/rdiskN on macOS, or /dev/rsd0d on NetBSD), write the image:

gunzip NetBSD-11.0-amd64-install.img.gz
# Replace /dev/sdX with the device you confirmed above
dd if=NetBSD-11.0-amd64-install.img of=/dev/sdX bs=1m
sync

GNU dd on Linux spells the block size bs=1M. On macOS, unmount the disk with diskutil unmountDisk /dev/diskN before writing.

Step 4: install with sysinst

Boot from the stick and follow sysinst(8). The NetBSD Guide's example installation chapter walks through each screen. Keep the default sets unless you have a reason to remove one, and note that 11.0 moved the compatibility libraries into new base32/base64 and debug32/debug64 sets that may need to be selected separately. Set a strong root password; on 10.0 and later it is hashed with Argon2id by default. Remember that no network services are enabled by default, so enable only what you need, such as sshd, in /etc/rc.conf.

Step 5: set up binary packages with pkgin

The pkgsrc site gives the canonical bootstrap for binary packages on NetBSD:

PKG_PATH="https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/$(uname -p)/$(uname -r | cut -f '1 2' -d.)/All/"
export PKG_PATH
pkg_add pkgin

pkgin search nginx
pkgin install nginx
pkgin upgrade

The site warns that the release part of the URL "should be something like 10.1, not 10.1_STABLE." If you run a stable branch build, set the release number by hand.

Step 6: audit installed packages

# Download the signed vulnerability list and check its signature
pkg_admin fetch-pkg-vulnerabilities -s

# Audit every installed package, verifying the signature again
pkg_admin audit -s

# Also report packages that pkgsrc marks as end of life
pkg_admin audit -e

# Show every recorded issue for one package base name
pkg_admin audit-history openssl

To make this a daily habit, add the following to /etc/daily.conf so the daily security run fetches the list:

fetch_pkg_vulnerabilities=YES

and, optionally, make the audit explicit in /etc/security.conf:

check_pkg_vulnerabilities=YES

Fix anything the audit reports with pkgin upgrade, or pkgin install of the fixed package, then run the audit again.

Step 7: turn on the hardening you want

# Check the current PaX state
sysctl security.pax

# Enable Veriexec: generate fingerprints, load them, then enforce at boot
veriexecgen
veriexecctl load
# In /etc/rc.conf:
#   veriexec=YES
#   veriexec_strict=1   # IDS mode; raise later once the database is stable

# Let users see only the processes and sockets they own
sysctl -w security.curtain=1

Write firewall rules in /etc/npf.conf (see npf.conf(5)), enable npf=YES in /etc/rc.conf, and load them with npfctl(8). If sshd faces the Internet, configure blocklistd to add NPF block rules after repeated failures.

Step 8: apply system updates with sysupgrade

Warning: sysupgrade replaces the kernel, modules and base system. Take a backup or snapshot first, confirm you have console access, and check which disk the root file system lives on (df / and /etc/fstab) before you start, so you can recover if the new kernel does not boot.

sysupgrade is in pkgsrc (sysutils/sysupgrade). Its package description calls it "a script to automate NetBSD system upgrades" that fetches distribution sets, upgrades the system and then makes sure the configuration is up to date.

pkgin install sysupgrade

For a minor upgrade inside one branch, for example 10.1 to 10.2, the NetBSD Guide's pattern is a single command:

sysupgrade auto https://cdn.NetBSD.org/pub/NetBSD/NetBSD-10.2/amd64

For a major upgrade, for example 10.2 to 11.0, the Guide says to upgrade the kernel and modules first and reboot, because "your running kernel is never older than the userspace":

sysupgrade fetch https://cdn.NetBSD.org/pub/NetBSD/NetBSD-11.0/amd64
sysupgrade kernel
sysupgrade modules
reboot
sysupgrade sets
sysupgrade etcupdate
sysupgrade postinstall
sysupgrade clean
reboot

After a major upgrade, the 11.0 announcement reminds you to "adjust any package repository URL and update all third-party packages." Point pkgin's repository at the 11.0 package path and run pkgin upgrade, then repeat the audit from step 6. The alternative is to boot the new install image and choose the Upgrade option in sysinst, which the announcement also documents.

NetBSD, FreeBSD and OpenBSD compared

All three projects ship a complete base system from one source tree and keep third party software in a separate package system. They differ in cadence, support length and emphasis. FreeBSD and OpenBSD facts below come from their own security pages and from our sibling posts, which cite those pages.

There is no ranking here. The right choice depends on hardware, workload and how often you want to upgrade. NetBSD is the clear fit when the hardware is unusual or old, or when you want the same package tree across several operating systems.

Common mistakes

• Treating 9.x as long term support. NetBSD 9 lasted six and a half years because 10.0 was late. It ended on 31 August 2026, and 9.5 is its last release.
• Planning around a fixed end date for 10.x. There is none; it ends about a month after 12.0 ships.
• Assuming pkg_admin audit covers the base system. It does not. Base OpenSSH, OpenSSL and the kernel are covered by advisories and branch fixes. Check both.
• Staying on an old quarterly pkgsrc branch. Only the current quarterly branch gets security fixes.
• Using _STABLE in PKG_PATH. The pkgsrc site says the URL needs a release number such as 10.1.
• Upgrading userland before the kernel across a major release. Kernel and modules first, reboot, then sets.
• Forgetting packages after a major upgrade. Binary packages are built per major; change the repository URL and upgrade all of them.
• Disabling MPROTECT globally for one runtime. Exempt that binary with paxctl instead.
• Treating Veriexec as a vulnerability check. It stops changes to files you trust; it does not decide whether they deserved trust.
• Skipping signature checks on release hashes and pkg-vulnerabilities.

Patching the NetBSD base system and keeping pkgsrc audited protects the operating system, but the services you run on a NetBSD host usually bring their own open source dependencies through npm, pip, Go modules or Maven, and those are rebuilt every time you redeploy or move to a new release. The fit for Safeguard here is indirect: Safeguard does not patch the NetBSD base system or pkgsrc packages, but the application code and dependencies you build and ship to NetBSD machines 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 services to NetBSD servers or Arm boards, this is the route for scanning the application repositories and their dependency manifests on a workstation or build machine before the code reaches 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 split applies on NetBSD: pkg_admin audit covers the nodejs package from pkgsrc, while a vulnerable library inside your own application needs a fix in your 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 read a NetBSD advisory or plan a 10.x to 11.0 upgrade window, this is how the same assistant can also look up findings for the application code you deploy on those machines.

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 NetBSD?

NetBSD 11.0, released on 30 July 2026, is the latest major release and the nineteenth in the project's count. The newest release in the 10 series is NetBSD 10.2, released on 15 September 2026. Both are supported as of 24 October 2026.

Is NetBSD 9 still supported?

No. Under NetBSD's policy, a major series ends about one month after the second succeeding major release. NetBSD 11.0 shipped on 30 July 2026, and the formal releases page lists end of support for the 9 series on 31 August 2026, the same day 9.5 was released. Upgrade to 10.2 or 11.0.

How long is a NetBSD release supported?

There is no fixed number of years. A major series, including all its minor releases, is supported until about a month after the second next major release. In recent history that has ranged from under six years (NetBSD 8) to about six and a half years (NetBSD 9). At any time, two major branches are supported.

When was NetBSD first released?

NetBSD 0.8 is dated 20 April 1993 on the project's history page, and NetBSD 1.0 on 26 October 1994. The project was founded in 1993 by Chris Demetriou, Theo de Raadt, Adam Glass and Charles M. Hannum.

Can I use pkgsrc on Linux or macOS?

Yes. The pkgsrc site lists Linux and macOS among its primary platforms, alongside NetBSD and Solaris, SmartOS and illumos. On those systems you bootstrap pkgsrc into its own prefix, such as /opt/pkg-2026Q3, and then build or install packages with the same tools used on NetBSD.

How do I check a NetBSD system for vulnerable packages?

Run pkg_admin fetch-pkg-vulnerabilities -s to download the signed vulnerability list, then pkg_admin audit -s to check every installed package. Add fetch_pkg_vulnerabilities=YES to /etc/daily.conf to have the daily security script do it automatically.

How do I upgrade NetBSD to a new major release?

Either boot the new install image and choose Upgrade in sysinst, or use sysupgrade from pkgsrc. For a major upgrade, update the kernel and modules first, reboot, then install the sets, run etcupdate and postinstall, and reboot again. Afterwards, point pkgin at the new release's package repository and upgrade all packages.

What is Veriexec in NetBSD?

Veriexec is NetBSD's in kernel file integrity subsystem. You generate fingerprints of the files you want to protect with veriexecgen, load them with veriexecctl load, and choose a strict level from learning mode up to lockdown. At IDS level and above, files whose fingerprints no longer match are refused.

Quick check

Sources

• NetBSD releases (supported releases)
• NetBSD formal releases: history table and support policy
• NetBSD release glossary and graphs
• The History of the NetBSD Project
• Announcing NetBSD 11.0
• Announcing NetBSD 10.2
• Announcing NetBSD 10.1
• Announcing NetBSD 10.0
• Announcing NetBSD 9.5
• Announcing NetBSD 9.0
• Announcing NetBSD 8.0
• Announcing NetBSD 7.0
• Announcing NetBSD 6.0
• Announcing NetBSD 5.0
• Announcing NetBSD 4.0
• Announcing NetBSD 3.0
• Announcing NetBSD 2.0
• NetBSD security page
• NetBSD security advisory archive
• NetBSD-SA2024-002 (advisory format example)
• NetBSD 11.0 signed hash list
• Platforms supported by NetBSD (ports and tiers)
• The NetBSD Foundation
• NetBSD wiki: rump kernels
• NetBSD Guide: upgrading NetBSD (sysinst and sysupgrade)
• NetBSD Guide: example installation
• pkgsrc home page
• pkgsrc guide: using pkgsrc (security checks)
• pkgsrc guide: getting pkgsrc (quarterly branches)
• pkg-vulnerabilities file
• sysupgrade package description
• pkgin package description
• veriexec(8) manual page
• security(7) manual page
• paxctl(8) manual page
• npf(7) manual page
• blocklistd(8) manual page
• pkg_admin(1) manual page
• FreeBSD security information
• OpenBSD FAQ: system management (errata and syspatch)

Last reviewed: 24 October 2026. NetBSD support depends on when the next major release ships, and pkgsrc branches change every quarter; check the NetBSD releases page and the advisory archive before planning an upgrade.