← Back to articles
Security· 2 min read

CVE-2026-4747: an unauthenticated RPCSEC_GSS flaw opens the door to kernel-level RCE on FreeBSD

On March 26, 2026 the FreeBSD project published advisory FreeBSD-SA-26:08.rpcsec_gss, fixing a critical flaw in its RPCSEC_GSS implementation. The bug (CVE-2026-4747) mainly hits NFS servers that use Kerberos authentication, and the worst part is that a malicious client can trigger it without authenticating first.

What actually breaks

RPCSEC_GSS provides integrity and encryption for RPC calls, and it underpins NFS secured with Kerberos (sec=krb5, krb5i, krb5p). Every RPCSEC_GSS data packet is validated by a routine that checks a signature carried inside the packet. To do that, the routine copies part of the packet into a stack buffer. That is where it goes wrong: it never checks that the buffer is large enough before copying. A client that sends a crafted packet triggers a stack overflow.

A stack overflow in kernel context is not a simple crash. According to the advisory, it can lead to remote code execution with kernel privileges on the NFS server. In userspace, RPC servers linked against librpcsec_gss are equally exposed to remote exploitation from any client.

Who is affected

The flaw is present across all supported FreeBSD versions:

  • FreeBSD 15.0-RELEASE and stable/15
  • FreeBSD 14.3 and 14.4, plus stable/14
  • FreeBSD 13.5-RELEASE and stable/13

The vulnerable components are the kernel module kgssapi.ko (the RPCSEC_GSS implementation) and the userspace library librpcsec_gss. If you run an NFS server with Kerberos authentication and the module loaded, you sit in the direct line of fire. The same goes for any in-house RPC server that links against librpcsec_gss.

The lack of an authentication requirement changes the risk math considerably. This is not a user who already has shell access, but anyone who can reach the service port over the network.

How to mitigate

The right move is to update. FreeBSD applied the fixes on March 26, 2026 across every supported branch, both stable and the matching releng branches (releng/15.0, releng/14.4, releng/14.3 and releng/13.5). The usual procedure applies: patch with freebsd-update, or rebuild the kernel and librpcsec_gss from the corrected branches if you manage the system from source. A reboot is needed for the new kernel to take effect.

If you cannot patch right away and you do not use NFS with Kerberos, unloading the kgssapi.ko module shrinks the kernel-side attack surface. Even so, the risk stays as long as the service is reachable from untrusted networks, so restrict access to the NFS and RPC ports with your firewall while you roll out the proper patch.

If you run FreeBSD in production, this is one to apply without waiting for the next maintenance window. More background on the platform is on the FreeBSD page.

Source