In der Linux-Welt haben zuletzt Schwachstellen mit einprägsamen Namen wie „CopyFail“, „DirtyFrag“ oder „Fragnesia“ für Aufsehen gesorgt – allesamt lokale Rechteausweitungslücken, die den Page Cache von Dateien im Speicher manipulieren. Nun hat dieselbe Schwachstellenklasse auch FreeBSD erreicht. Sicherheitsforscher veröffentlichten am 9. Juni 2026 Details zu einer kritischen Kernel-Lücke, die sie mit einem Augenzwinkern „Bumsrakete[tm]“ tauften [1].
Die als CVE-2026-45257 verzeichnete Schwachstelle erlaubt es lokalen Angreifern ohne erweiterte Rechte, beliebige Dateien im System zu überschreiben – einschließlich setuid-Binärdateien – und sich so Root-Zugriff zu verschaffen. Das FreeBSD-Projekt hat umgehend Sicherheitsupdates bereitgestellt und stuft das Risiko als kritisch ein [2].
Technischer Angriffsvektor: Wenn drei Schutzmechanismen ins Leere laufen
Der Fehler liegt in der unglücklichen Kombination dreier für sich genommen korrekter Kernel-Subsysteme. Den Kern bildet die Kernel-TLS-Implementierung (KTLS), die TLS-Verarbeitung auf Socket-Ebene direkt im Kernel durchführt, um Kopiervorgänge zwischen Kernel- und Userspace zu vermeiden [2].
Konkret läuft der Angriff wie folgt ab: Ein unprivilegierter Nutzer schickt eine Datei, die er lesen darf, mittels sendfile(2) über eine Loopback-Verbindung. Der Systemaufruf erzeugt dabei sogenannte M_EXTPG-mbufs, die direkt auf die physischen Speicherseiten des Page Cache der Datei verweisen – eine Performance-Optimierung, die auf allen gängigen Architekturen (amd64, arm64, riscv) standardmäßig aktiv ist [3].
Auf der Empfängerseite aktiviert der Angreifer KTLS RX – eine Operation, für die FreeBSD keinerlei Privilegienprüfung vorsieht. Die AES-GCM-Entschlüsselung läuft dann in place über den PHYS_TO_DMAP-Zeiger, der direkt in die Page-Cache-Seite der Datei zeigt. Da der Angreifer sowohl Schlüssel als auch Initialisierungsvektor selbst wählt, kann er den resultierenden Plaintext vollständig kontrollieren [3].
„Der Schreibvorgang modifiziert den Page Cache direkt und umgeht damit sämtliche VFS-Schichten“, heißt es im offiziellen FreeBSD-Advisory. „Datei-Flags wie schg werden ignoriert, die Änderungen werden auf das Laufwerk zurückgeschrieben“ [2].
Drei im Kernel vorhandene Schutzmechanismen greifen jeweils nicht: mb_unmapped_compress ist auf Payloads bis maximal 224 Byte beschränkt und wird mit 240-Byte-Records umgangen; mb_unmapped_to_ext kopiert die Daten nicht, sondern erzeugt nur neue mbufs, die auf dieselben physischen Seiten zeigen; und sb_mark_notready prüft beim Verschieben der Daten in die KTLS-Decrypt-Queue überhaupt nicht auf M_EXTPG-Herkunft [3].
Betroffene Systeme und verfügbare Patches
Verwundbar sind alle FreeBSD-Versionen ab 13.0 (April 2021) bis einschließlich 15.0 auf Architekturen mit PMAP_HAS_DMAP. Der zugrundeliegende Code wurde bereits 2020 mit Commit 3c0e56850511 eingeführt – die Lücke blieb rund fünf Jahre unentdeckt [3]. FreeBSD 12.x enthält den verwundbaren Code noch nicht [1].
Das FreeBSD-Security-Team hat mit Advisory FreeBSD-SA-26:26.ktls Patches für folgende Versionen veröffentlicht [2]:
- FreeBSD 14.3-RELEASE-p15
- FreeBSD 14.4-RELEASE-p6
- FreeBSD 15.0-RELEASE-p10
- FreeBSD 15.1-RC3-p1
Systeme, die mit Base-Paketen installiert wurden, aktualisieren Admins via pkg upgrade -r FreeBSD-base; bei binären Distributionssets kommt freebsd-update zum Einsatz. In beiden Fällen ist ein Neustart erforderlich. Quellcode-Patches stehen ebenfalls bereit [2].
Als temporäre Sofortmaßnahme ohne Kernel-Neubau nennen die Entdecker das Setzen von kern.ipc.mb_use_ext_pgs=0 in /etc/sysctl.conf, womit der sendfile-Fast-Path über EXTPG-mbufs deaktiviert wird. Das FreeBSD-Projekt selbst wiederholt diesen Workaround in seinem Advisory allerdings nicht [1].
CVSS 13 von 10: Satire als Seitenhieb auf die Aufmerksamkeitsökonomie
Die Entdecker – die unter dem Pseudonym „Bumsrakete“ auftreten und über eine Protonmail-Adresse kommunizieren – haben der Schwachstelle eine aufwendig gestaltete Website unter bumsrake.de gewidmet. Der Text ist durchgängig im Sprachstil Donald Trumps verfasst, die Schriftart Comic Sans unterstreicht den parodistischen Charakter [3].
Die Aufmachung ist ein gezielter Seitenhieb auf die zunehmende „Markenbildung“ bei Sicherheitslücken: In den vergangenen Jahren haben Entdecker von Kernel-Schwachstellen regelmäßig eigene Logos, Namen und Landingpages produziert – ein Trend, den die Bumsrakete-Macher mit übertriebener Bombastik kommentieren. So wird etwa der CVSS-Score kurzerhand mit „13 von 10“ angegeben, weil die Lücke zusätzlich chflags schg aushebelt [1].
Der reale CVSS-3.1-Wert liegt bei 9,3 und entspricht damit der Einstufung „kritisch“. Der angenommene Angriffsvektor ist lokal (AV:L), die Komplexität gering (AC:L), Privilegien sind keine erforderlich (PR:N) [1].
Einordnung: FreeBSD rückt in den Fokus der Page-Cache-Forschung
Die „Bumsrakete“-Schwachstelle reiht sich in eine Serie von Page-Cache-basierten Rechteausweitungslücken ein, die bislang vor allem Linux betrafen. „Dirty Pipe“ (CVE-2022-0847) hatte 2022 den Anfang gemacht, gefolgt von „CopyFail“, „DirtyFrag“ und zuletzt „Fragnesia“ (CVE-2026-46300) im Mai 2026 [1].
Dass nun auch FreeBSD – das oft als besonders sicherheitsbewusstes Unix-System gilt – eine strukturell ähnliche Lücke aufweist, zeigt, dass die zugrundeliegende Problematik nicht betriebssystemspezifisch ist. Die Kombination aus Performance-Optimierungen im Speichermanagement und kryptografischen Operationen im Kernel erzeugt eine Angriffsfläche, die in verschiedenen Unix-Derivaten auf ähnliche Weise ausgenutzt werden kann.
Für IT-Verantwortliche bedeutet das: Auch auf FreeBSD-Servern sollte das Advisory ernst genommen werden. Ein Demo-Exploit ist öffentlich verfügbar und benötigt laut Entdeckern auf einem Standard-System weniger als zwei Sekunden für eine vollständige Rechteausweitung [3]. Die Tatsache, dass der Bug in Jails mit Standard-Fähigkeitenset ebenso funktioniert, macht ihn für Hosting-Umgebungen besonders relevant.
Das FreeBSD-Projekt hat mit der zügigen Bereitstellung von Patches innerhalb weniger Stunden nach der koordinierten Veröffentlichung reagiert. Die Entdecker hatten die Schwachstelle nach eigenen Angaben am 21. Mai 2026 an das Security-Team gemeldet [3].