hoaxeye
Loslegen
Alle Advisories
HXA-2026-001KritischOffen

Ungeprüftes Laden nativer Addons im Server-JS-Runtime → native Codeausführung in FXServer

Produkt
FiveM / FXServer
Komponente
citizen-scripting-node (embedded libnode 22)
CVSS
9.0
Veröffentlicht
28. Juli 2026

Zusammenfassung

Server-seitige JavaScript-Resources auf einem FXServer laufen in einem eingebetteten Node.js (libnode 22). FiveM sichert dieses Runtime mit einem eigenen Permission-Handler ab, der Zugriffe wie Dateisystem, Kindprozesse, Worker und Inspector abfängt.

Das Laden nativer Addons ist von diesem Gate nicht erfasst. Node 22 kennt schlicht keinen Permission-Scope für Addons — der entsprechende Mechanismus (--allow-addons) existiert erst ab Node 24. Der Permission-Callback wird beim Laden eines Addons also niemals aufgerufen. Jede JavaScript-Resource kann eine .node-Datei (eine kompilierte DLL) laden, die sie in ihrem eigenen Ordner mitbringt, und damit beliebigen nativen Code direkt im Serverprozess ausführen.

Das ist der maximale Sandbox-Ausbruch: er umgeht jede Absicherung auf Skript-Ebene (VFS-Grenzen, Dateisystem-Rechte, Lua/JS-Sandboxing).

Ursache

Der Permission-Handler ist die einzige Schranke für Server-JS. Seine Scope-Liste (Dateisystem, Kindprozess, Worker, Inspector) entspricht exakt dem Node-22-Standard — und in Node 22 gibt es keinen Addon-Scope. Die Bindungsschicht von libnode enthält daher für den Addon-Ladepfad (dlopen) keine Rechteprüfung. Der installierte Handler wird nie konsultiert, wenn eine Resource ein natives Modul lädt.

Es gibt keine kompensierende Kontrolle: kein Modul-Whitelisting, und die abgesicherte Dateisystem-Schicht ist irrelevant, weil der native Loader des Betriebssystems die DLL direkt einliest.

Auswirkung

  • Vollständige Serverkompromittierung (Codeausführung als Serverprozess) durch jede installierte Drittanbieter-JS-Resource.
  • Persistenz und Tarnung: nativer Code kann sich der Resource-Introspektion entziehen und Neustarts des Skript-Runtimes überdauern.
  • Verfügbarkeit: schon ein fehlerhaftes Addon erzeugt in Kombination mit Auto-Restart einen dauerhaften Absturz-Loop.

Behebung

  • Den Addon-Permission-Scope aus Node 24 (kAddon, Default-Deny) in das gepatchte libnode zurückportieren und im dlopen-Pfad über den vorhandenen Permission-Handler durchsetzen.
  • Übergangsweise: process.dlopen / require('*.node') im Runtime für Nicht-System-Resources blockieren.
  • Langfristig: für Drittanbieter-Resources eine Modul-Typ-Whitelist (nur JS/Lua, keine nativen Module).