← Back to articles
Security· 2 min read

FreeBSD KTLS: a local user can overwrite files and escalate to root (CVE-2026-45257)

On June 9, 2026 the FreeBSD project published advisory FreeBSD-SA-26:26.ktls, covering CVE-2026-45257 in KTLS, the in-kernel TLS implementation. The bug lets an unprivileged local user overwrite the contents of files they only have read access to, which opens a path to privilege escalation up to root.

What actually goes wrong

KTLS moves TLS encryption and decryption into the kernel to save memory copies and improve throughput, especially when paired with sendfile(2). On the receive side, KTLS decrypts each record in place. It assumes the mbufs holding received data are anonymous and safe to modify.

That assumption does not always hold. When sendfile(2) transmits file-backed memory over a loopback connection without outbound KTLS encryption, the data arriving at the receiver points at the actual file contents rather than a private copy. If the attacker has enabled KTLS receive on that socket, the in-place decryption writes over those pages and modifies the original file.

The bar for exploitation is low. The attacker only needs read access to the target file and the ability to open a loopback connection, both of which any local user has.

Who is affected and how serious it is

All supported FreeBSD branches are affected. The advisory lists the fixed versions:

  • stable/15 (15.1-STABLE)
  • releng/15.1 (15.1-RC3-p1)
  • releng/15.0 (15.0-RELEASE-p10)
  • stable/14 (14.4-STABLE)
  • releng/14.4 (14.4-RELEASE-p6)
  • releng/14.3 (14.3-RELEASE-p15)

This is rated high. It is not remote code execution, but the ability to overwrite arbitrary files with attacker-chosen content is dangerous on any multi-user system. A tampered setuid binary, a system configuration file, or any sensitive path the user can read becomes a starting point for gaining root. On shared servers, jails with untrusted users, and hosting environments, this is exactly the kind of flaw worth closing quickly.

How to protect yourself

The right move is to update to a patched release. There are three routes:

  • freebsd-update for systems running official binaries (freebsd-update fetch install followed by a reboot).
  • Rebuilding the kernel from patched sources if you compile your own system.
  • Updating packages with pkg where that fits your deployment flow.

If you cannot patch right away, the advisory offers a mitigation: disable KTLS entirely with

sysctl kern.ipc.tls.enable=0

Keep in mind this turns off KTLS acceleration system-wide, so you lose that performance benefit until you apply the fix. Once patched, re-enable it.

If you run FreeBSD servers, this is a good moment to review the rest of the advisories published the same day, since June 9 brought a large batch. You can check the FreeBSD page for supported versions and links to the official security channels.

Source

Related systems

FreeBSD