Nix und Lix schließen Daemon-Lücken, die lokal Root-Rechte ermöglichen

Die Projekte Nix und Lix haben am 13. Oktober 2026 gemeinsam Sicherheitslücken offengelegt. Verkettet können sie auf Rechnern, auf denen ihre Daemons zum Bauen von Paketen laufen, zu Root-Zugriff führen. Korrigierte Releases erschienen am selben Tag. Jede Mehrbenutzer-Installation von Nix oder Lix, bei der nicht vertrauenswürdige Nutzer den Daemon erreichen können, sollte jetzt aktualisiert werden.

Nix ist ein Paketmanager und Build-System, auf dem die Linux-Distribution NixOS aufbaut. Lix ist eine eigenständige Implementierung von Nix. Beide betreiben einen Hintergrunddienst, den Daemon, der Software im Auftrag lokaler Nutzer baut.

Die Lücken

Der gemeinsame Sicherheitshinweis auf NixOS Discourse nennt mehrere Probleme. Das schwerste erlaubt einem lokalen Nutzer, Dateien zu manipulieren, die später als Root laufen.

Problem	Wer betroffen ist	Schweregrad
Nicht privilegierte „repair“-Anfragen (Reparatur) können Store-Dateien ersetzen, bevor diese geprüft werden	Mehrbenutzer-Installationen unter Linux und macOS	Hoch, 8,4 von 10 (Nix-Hinweis)
Ein Integer-Überlauf in builtins.genList führt zu einem Schreibzugriff auf den Heap-Speicher	Systeme, die nicht vertrauenswürdigen Nix-Code auswerten	Mittel
Ausbruch aus der macOS-Sandbox, wenn das Sandbox-Profil eines Builds eine Größengrenze überschreitet	macOS mit sandbox = true oder relaxed	Mittel
Der Mehrbenutzer-Installer hinterlässt Store-Dateien, die dem installierenden Nutzer gehören	Neuinstallationen über den Skript-Installer; NixOS ist nicht betroffen	Mittel, 5,6
Der Daemon nimmt Verbindungen von Build-Nutzern an	macOS und FreeBSD; Linux ist nicht betroffen	Niedrig, 3,8

Auf der Nix-Seite sind fünf GitHub-Sicherheitshinweise erschienen. Keiner hat bisher eine CVE-Nummer.

Wie die Root-Rechteausweitung funktioniert

Der Hauptfehler liegt darin, wie der Daemon Dateien in den Nix-Store aufnimmt, das Verzeichnis, in dem alle gebaute Software liegt. Laut dem Nix-Sicherheitshinweis GHSA-jwvx-xq5j-gc56 entpackte der Daemon ein hochgeladenes Archiv direkt in seinen endgültigen Store-Pfad. Den Hash des Archivs prüfte er erst danach.

Angreifbare Versionen ließen nicht vertrauenswürdige Nutzer zudem eine Reparatur („repair“) anfordern, die einen bestehenden Store-Pfad ersetzt. Schlug die Hash-Prüfung fehl, blieben die schädlichen Dateien auf der Festplatte. Läuft der Daemon als Root, konnte laut dem Hinweis jeder in allowed-users eingetragene Nutzer Code als Root ausführen.

Die Lücke reicht bis Nix 2.1 zurück, das Uploads per Streaming eingeführt hat. Der Fix sperrt nicht vertrauenswürdige Nutzer vom Reparaturmodus aus. Außerdem entpackt er Uploads in einen privaten temporären Ordner und verschiebt sie erst an ihren Platz, wenn der Hash stimmt.

Der Hinweis nennt Guthrie McAfee Armstrong und einen Forscher, der als joaoviictorti bekannt ist, als Entdecker.

Welche Versionen Sie installieren sollten

Projekt	Behobene Versionen
Nix	2.35.3, 2.34.9, 2.31.6, 2.30.6, 2.28.8
Lix	2.95.4, 2.94.3

Laut dem Hinweis sollten die nicht mehr unterstützten Nix-Zweige 2.29, 2.32 und 2.33 als angreifbar gelten. Lix 2.93 und älter sind betroffen, werden aber nicht mehr gepflegt. Updates für die NixOS-Channels unstable und 26.05 sind in Arbeit.

Der Paketmanager Guix ist nicht betroffen.

Ein Zeitplan über Monate

Der Bericht des Lix-Teams zeigt, wie lange die Abstimmung dauerte. Der Überlauf-Fehler wurde dem Team am 29. Juli gemeldet, und die Fixes waren am 29. August fertig. Die Kette zur Rechteausweitung unter macOS kam am 12. September hinzu, der Sandbox-Ausbruch am 9. Oktober.

Der Lix-Beitrag betont, dass sein Daemon keine Sicherheitsgrenze ist. Er rät Build-Farmen, den Daemon nach Möglichkeit als nicht privilegierten Nutzer laufen zu lassen.

Tech AI Wire hat im vergangenen Monat über ein anderes Lieferketten-Problem berichtet: ein manipuliertes strip-Binary, das NixOS mit einer Hintertür versehen konnte.

Was das für Entwickler bedeutet

• Jede Mehrbenutzer-Installation aktualisieren. Jeder Rechner, auf dem mehr als eine Person oder ein Dienst mit dem Nix-Daemon spricht, ist gefährdet. Einzelbenutzer-Setups tragen ein geringeres Risiko, sollten aber trotzdem aktualisiert werden.
• Den richtigen Upgrade-Weg für Lix wählen. Der Hinweis warnt, dass ein einfaches nix upgrade-nix Lix 2.95.x deinstallieren kann, bevor die neue Version installiert ist. Nutzen Sie stattdessen das Upgrade-Skript von Lix 2.95.4.
• Nach Skript-Installationen die Eigentümer im Store prüfen. Wurde Nix mit dem Mehrbenutzer-Skript installiert, nennt der Hinweis Befehle, mit denen jeder Store-Pfad wieder Root gehört.
• allowed-users prüfen. Bis zum Upgrade kann praktisch jeder auf dieser Liste Root werden. Beschränken Sie sie auf die Konten, die bauen müssen.
• Nicht vertrauenswürdigen Nix-Code als nicht vertrauenswürdig behandeln. CI-Systeme, die Pull Requests von Fremden auswerten, könnten auf den Überlauf-Fehler stoßen. Führen Sie diese Auswertungen auf isolierten Maschinen aus.