Seven advisories in a single day is enough that even careful operators have to think about order. Two of these are kernel-side and trivially exploitable by any local user. One is a flashy headline (Wi-Fi-name root RCE) that mostly doesn't matter in production. The rest are this-week patches.

This post walks the batch in the order I'd actually patch them.

Priority table

# Advisory What it gets you Patch when
1 SA-26:18.setcred Kernel-level RCE via crafted supplementary group list Now
2 SA-26:21.ptrace Local privilege escalation via PTSCREMOTE (CVE-2026-45253) Now
3 SA-26:24.cap_net Capsicum permission-limit bypass This week
4 SA-26:22.libcasper Stack overflow via the select(2) 1024-fd boundary (CVE-2026-45252) This week
5 SA-26:23.bsdinstall Root RCE during Wi-Fi scan (CVE-2026-45255) Before next install/re-image
6 SA-26:20.fusefs Kernel heap disclosure/injection from a rogue FUSE daemon Only if fusefs.ko is loaded
7 SA-26:19.file file(1) / libmagic issue This week

The kernel ones — patch first

SA-26:18.setcred

The setcred(2) system call copies a user-supplied list of supplementary groups into a fixed-size kernel stack buffer without checking the length first. A stack overflow inside the kernel gets you arbitrary kernel-level code execution.

Why it's the top: any local user can hit it, no special configuration required, every supported FreeBSD version is affected.

SA-26:21.ptrace — CVE-2026-45253

Insufficient parameter validation in the PTSCREMOTE ptrace operation lets a debugger execute arbitrary system calls inside a target process. Unprivileged local user → full system control.

If you operate any multi-user box (a shared dev server, a jail host with login accounts), this is a same-day patch.

SA-26:20.fusefs

The kernel reads extended attribute lists returned by a userspace FUSE daemon without verifying that they are NUL-terminated. A malicious FUSE daemon can leak up to 253 bytes of kernel heap memory or inject up to 250 bytes into unallocated heap space.

The mitigation is right there in the name — this only matters if fusefs.ko is loaded. Check:

kldstat | grep fusefs

Empty output? Defer this one. The module isn't loaded.

The userland ones

SA-26:23.bsdinstall — CVE-2026-45255

This is the headline-grabber of the batch. bsdinstall and bsdconfig mishandle Wi-Fi network names during scanning. An attacker broadcasting a maliciously crafted SSID gets arbitrary command execution as root on a box that's actively scanning. No network selection required — the scan itself is the trigger.

Practical operator view:

  • Production servers don't run installers. Low immediate risk.
  • Laptops you reinstall periodically. Reinstall on wired or known-clean Wi-Fi until your install media carries the 14.3 / 14.4 / 15.0 patches.
  • Anyone re-imaging hardware regularly — workshop laptops, demo machines, conference rigs — treat as urgent and refresh your install media.

The patches are out for 14.3, 14.4, and 15.0. The workaround for unpatched media is manual wpa_supplicant.conf configuration instead of in-installer scanning.

SA-26:24.cap_net

The Capsicum cap_net service treats omitted keys in updated permission limits as "allow any" rather than rejecting the update. A sandboxed process can effectively widen its own capability set by sending an incomplete update.

If you run jailed or Capsicum-isolated services (FreshRSS, podman jails, internal API gateways — anywhere you've leaned on Capsicum as a defense-in-depth layer), this matters more than the raw CVSS would suggest. Patch this week.

SA-26:22.libcasper — CVE-2026-45252

libcasper doesn't verify that socket descriptors fit within select(2)'s 1024-descriptor limit. A process with enough open descriptors can trigger a stack overflow inside libcasper code paths.

Lower exploit ceiling than the kernel issues but still in the this-week bucket because libcasper is in the trust path for several base-system services.

SA-26:19.file

file(1) and libmagic. Read the official advisory directly for this one — I haven't seen a clean third-party writeup yet and file bugs are usually parser-layer issues where the technical detail matters for prioritization. Wherever you run file against attacker-controlled content (mail filters, web upload handlers, malware-triage pipelines), assume your risk surface includes it until you've patched.

How to actually patch

The usual freebsd-update flow handles all seven once they reach your version's patch channel. The kernel-side fixes (setcred, ptrace, libcasper) require a reboot.

# 1. Take a ZFS boot environment first — cheap insurance
bectl create before-may-2026-batch
 
# 2. Fetch + install
freebsd-update fetch
freebsd-update install
 
# 3. Reboot for the kernel patches to take effect
shutdown -r now

After the reboot:

freebsd-version -ku
# kernel and userland should match the new patched -p level

If bectl isn't an option (UFS root, etc.), take a snapshot or backup before freebsd-update install runs.

What ports/packages need rebuilds

If you build a custom kernel or any of these as ports rather than from base:

pkg audit -F
# lists installed packages with known vulnerabilities, including 26:18-26:24

Anything that pins to a specific libcasper or libcapsicum version in a port will get flagged by pkg audit once the vulnxml is refreshed.

Two final notes:

If you patched in the last 24 hours, you're caught up. If not, setcred and ptrace alone are enough reason to schedule a reboot today.

And: this is the kind of batch that justifies whatever monitoring tells you about boot-environment age. If your hosts haven't taken a kernel patch since January, this is the moment to fix the rest of the gap too — freebsd-update is happy to roll multiple patch levels at once.