The setcred

CVE-2026-45250 is a FreeBSD kernel stack overflow in setcred(2): the kernel copies a user-controlled supplementary group list into a fixed-size stack buffer before enforcing the privilege check. That turns a syscall intended for privileged callers into a local privilege escalation path for unprivileged users. The affected supported branches called out by FreeBSD are releng/14.3, releng/14.4, releng/15.0, stable/14, and stable/15; the visible release exposure starts with FreeBSD 14.3, when setcred(2) first shipped.

The vendor's HIGH 7.8 is technically fair in a vacuum because successful exploitation ends in kernel-context code execution and root. In enterprise reality, though, the decisive friction is that the attacker must already have local code execution or a valid low-privilege account on the target host. That makes this a post-initial-access privilege escalator, not an initial entry bug, so it lands lower than a remotely reachable flaw even though the per-host impact is severe.

Why this verdict

• Requires local code execution first: AV:L/PR:L means the attacker already has a shell, job, or code-exec foothold on the host. That is post-initial-access friction and deserves a meaningful drop from the vendor's 7.8 baseline.
• Reachable population is narrower than CVSS implies: this is FreeBSD-only, and the vulnerable syscall first appeared in the 14.3 era. Most enterprise estates have a much smaller FreeBSD footprint than Linux or Windows, reducing aggregate risk.
• Exploit quality keeps it out of LOW: there is a public write-up, public PoC, no user interaction, no workaround, and demonstrated root on modern amd64 builds including a path that survives SMAP/SMEP.

Why not higher?

It is not a front-door vulnerability. There is no unauthenticated remote path, no lateral spread mechanic, and no evidence of active exploitation strong enough to override the attacker-position friction. In a 10,000-host program, post-compromise LPEs do not outrank remotely reachable perimeter bugs.

Why not lower?

Once an attacker has a local foothold, this looks dangerously usable: low complexity, no user interaction, public exploit material, and kernel-context impact. That matters on shared-shell servers, CI workers, bastions, storage/admin nodes, and any FreeBSD system where multiple users or workloads land.

1. Restrict local shell access — Reduce the number of accounts and workflows that can execute code locally on affected FreeBSD hosts, especially bastions, CI runners, and shared admin systems. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this should still be done immediately on high-trust FreeBSD boxes because attacker foothold is the entire gateway to exploitation.
2. Segregate multi-tenant FreeBSD systems — Move shared-user, jail-hosting, build, and jump-host roles into a priority patch cohort and tighten who can log in or submit jobs. This does not remove the bug, but it materially cuts the number of users who can exercise the local attack path while you work through the 365-day remediation window.
3. Monitor for anomalous privilege transitions — Alert on suspicious root acquisition, unexpected sudo/su activity, kernel crashes, and unusual user sessions on FreeBSD hosts. There is no mitigation SLA for MEDIUM, but visibility is still worth adding now because successful exploitation ends with kernel-level control and can erase simpler traces.
4. Prioritize hosts with tenant or developer access — Even with a MEDIUM fleet verdict, treat FreeBSD systems that expose shell, SSH, CI, or shared service accounts as a higher-risk subset and patch them first. The control here is prioritization discipline: the more users who can run code locally, the more this CVE behaves like a practical threat instead of a theoretical one.

Run this on each target FreeBSD host as a normal user; root is not required. Save it as check-cve-2026-45250.sh and run sh check-cve-2026-45250.sh. It checks release builds by freebsd-version and returns UNKNOWN for custom/source-built -STABLE trees where advisory commit-level validation is needed.

#!/bin/sh
# check-cve-2026-45250.sh
# Detect likely exposure to CVE-2026-45250 on FreeBSD release builds.
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

if ! command -v freebsd-version >/dev/null 2>&1; then
  echo "UNKNOWN: freebsd-version not found"
  exit 2
fi

KV=$(freebsd-version -k 2>/dev/null || true)
UV=$(freebsd-version -u 2>/dev/null || true)
V="${KV:-$UV}"

if [ -z "$V" ]; then
  V="$UV"
fi

if [ -z "$V" ]; then
  echo "UNKNOWN: unable to determine FreeBSD version"
  exit 2
fi

case "$V" in
  *-STABLE*|*-CURRENT*)
    echo "UNKNOWN: STABLE/CURRENT source trees require commit-level validation against FreeBSD-SA-26:18.setcred"
    exit 2
    ;;
esac

# Extract major.minor and patch level from strings like:
# 14.3-RELEASE-p13
# 14.4-RELEASE-p5
# 15.0-RELEASE
BASE=$(printf '%s' "$V" | sed -E 's/^([0-9]+\.[0-9]+).*/\1/')
PATCH=$(printf '%s' "$V" | sed -nE 's/.*-p([0-9]+).*/\1/p')

if [ -z "$BASE" ]; then
  echo "UNKNOWN: could not parse version string: $V"
  exit 2
fi

if [ -z "$PATCH" ]; then
  PATCH=0
fi

case "$BASE" in
  14.3)
    if [ "$PATCH" -ge 14 ]; then
      echo "PATCHED: $V (fixed in 14.3-RELEASE-p14 or later)"
      exit 0
    else
      echo "VULNERABLE: $V (needs 14.3-RELEASE-p14 or later)"
      exit 1
    fi
    ;;
  14.4)
    if [ "$PATCH" -ge 5 ]; then
      echo "PATCHED: $V (fixed in 14.4-RELEASE-p5 or later)"
      exit 0
    else
      echo "VULNERABLE: $V (needs 14.4-RELEASE-p5 or later)"
      exit 1
    fi
    ;;
  15.0)
    if [ "$PATCH" -ge 9 ]; then
      echo "PATCHED: $V (fixed in 15.0-RELEASE-p9 or later)"
      exit 0
    else
      echo "VULNERABLE: $V (needs 15.0-RELEASE-p9 or later)"
      exit 1
    fi
    ;;
  *)
    echo "UNKNOWN: $V is outside the directly validated release patterns; check the advisory and source branch state"
    exit 2
    ;;
esac

Sources

1. NVD CVE-2026-45250
2. FreeBSD advisory mirror: FreeBSD-SA-26:18.setcred
3. Openwall disclosure thread
4. FatGid technical write-up
5. FreeBSD setcred(2) manual page
6. PoC repository referenced by researcher
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS documentation and data access