SGLang CVE-2026-93088: Pickle-Deserialisierung im DiffusionServer erlaubt unauthentifizierte Remote Code Execution — noch kein Fix

TL;DR — 90 Sekunden

SGLang, ein verbreitetes Open-Source-Serving-Framework für LLM- und Diffusionsmodelle, hat mit CVE-2026-93088 (CVSS 9.8, kritisch) eine unauthentifizierte Remote-Code-Execution-Lücke im DiffusionServer der Disaggregated-Diffusion-Orchestrierung. Ein ZeroMQ-ROUTER-Socket bindet ohne Authentifizierung an eine Netzwerkschnittstelle und deserialisiert eingehende Nachrichten direkt mit pickle.loads() — ein klassisches Einfallstor für beliebigen Code. Betroffen: Versionen 0.5.11 bis 0.5.14. Ein offizieller Patch war zum Redaktionsschluss (24. September 2026) noch nicht veröffentlicht. Wer SGLang im Disaggregated-Modus für Multimodal- oder Diffusion-Serving betreibt, sollte den betroffenen Port sofort vom Netz isolieren.

Was ist das Problem?

SGLang trennt bei verteiltem Inferencing die Arbeitsschritte häufig auf mehrere Prozesse oder Knoten auf: ein Encode-/Prefill-Schritt, ein Decode-Schritt und, für Multimodal- und Diffusionsmodelle, ein separater DiffusionServer-Prozess. Diese Komponenten tauschen Zwischenergebnisse über ZeroMQ-Sockets aus, statt über eine authentifizierte HTTP-API.

Der DiffusionServer öffnet dafür einen ZeroMQ-ROUTER-Socket, der an eine Netzwerkschnittstelle bindet, ohne die Herkunft eingehender Verbindungen zu prüfen. Trifft eine Multipart-Nachricht ein, übergibt der Server deren letzten Frame direkt an pickle.loads() — ohne Validierung, ohne Schema-Prüfung, ohne Authentifizierung. Python-Pickle-Daten können beliebige Objekte inklusive ausführbarem Code enthalten; ein präpariertes Payload mit einer __reduce__-Methode reicht aus, um beim Deserialisieren beliebige Shell-Kommandos auszuführen.

Das Muster ist bei SGLang kein Einzelfall: Bereits im März 2026 hatte CERT/CC unter VU#665416 zwei verwandte Lücken (CVE-2026-3059, CVE-2026-3060) in den generischen Disaggregated-Serving-Pfaden von SGLang dokumentiert (encode_receiver.py, shm_broadcast.py) — mit demselben Grundfehler: ungeprüfte pickle.loads()-Aufrufe auf Daten aus dem Netzwerk. CVE-2026-93088 zeigt, dass dasselbe Architekturmuster auch im neueren Diffusion-Pfad wiederkehrt.

Wer ist betroffen?

Betroffen sind ausschließlich Installationen, die SGLang im Disaggregated-Modus für Multimodal- oder Diffusion-Serving einsetzen und den DiffusionServer-Prozess über ein Netzwerk erreichbar machen — etwa in Multi-Node-Clustern für Bild- oder Video-Generierung. Reine Single-Node-Deployments ohne Diffusion-Orchestrierung sind von CVE-2026-93088 nicht betroffen, sollten aber die verwandten Lücken aus dem generischen Disaggregated-Pfad prüfen.

Auswirkungen

Ein Angreifer mit Netzwerkzugriff auf den ZeroMQ-Port des DiffusionServer kann ohne Authentifizierung und ohne Interaktion eines Nutzers beliebigen Code mit den Rechten des SGLang-Prozesses ausführen. Das betrifft in der Praxis oft GPU-Worker-Knoten mit Zugriff auf Modellgewichte, interne Netzwerksegmente und häufig auch Cloud-Metadaten-Endpunkte. Vertraulichkeit, Integrität und Verfügbarkeit sind vollständig kompromittiert (CVSS 9.8). Da die Portinformationen in Disaggregated-Setups teils unverschlüsselt zwischen den Knoten ausgetauscht werden, ist der verwundbare Endpunkt für einen Angreifer im selben Netzwerksegment mit einfachem Port-Scanning auffindbar.

Mitigation / Sofortmaßnahmen

Ein offizieller Fix für CVE-2026-93088 lag zum Zeitpunkt dieses Beitrags (24. September 2026) noch nicht vor. Bis ein Patch verfügbar ist, gilt: den DiffusionServer-Port ausschließlich intern erreichbar machen und niemals an 0.0.0.0 binden.

# DiffusionServer nur an ein internes Interface binden, nicht an alle Interfaces
python -m sglang.srt.disaggregation.diffusion_server --host 10.0.30.5 --port 5757

# Firewall: ZeroMQ-Port nur für die eigenen Inferenz-Knoten freigeben (Beispiel iptables)
iptables -A INPUT -p tcp --dport 5757 -s 10.0.30.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 5757 -j DROP

# In Kubernetes/K3s: NetworkPolicy statt offenem Service
kubectl apply -f - <<'EOF'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sglang-diffusionserver-restrict
spec:
  podSelector:
    matchLabels:
      app: sglang-diffusionserver
  policyTypes: [Ingress]
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: sglang-worker
    ports:
    - protocol: TCP
      port: 5757
EOF

Zusätzlich empfehlen sich: das Verteilen von Inferenz-Traffic ausschließlich über private Netzwerke oder VPN-Tunnel zwischen Knoten, das Deaktivieren des Diffusion-Orchestrierungspfads, sofern er nicht produktiv genutzt wird, sowie ein Downgrade auf eine Konfiguration ohne Disaggregated-Diffusion-Modus, falls betrieblich vertretbar. Ein Wechsel von pickle auf ein sicheres Serialisierungsformat wie MessagePack ist die langfristig korrekte Lösung, aber Sache des SGLang-Projekts — bis dahin bleibt Netzwerkisolation der wirksamste Hebel.

Detection / Prüfung

Prüfen Sie zunächst, ob DiffusionServer-Prozesse überhaupt an öffentlich oder breit erreichbaren Interfaces lauschen:

# Offene ZeroMQ-Ports auf SGLang-Knoten identifizieren
ss -tulpn | grep -i python
nmap -p 5000-6000 <interner-IP-Bereich>

# Prozessliste auf ungewöhnliche Kindprozesse von SGLang-Workern prüfen
ps --forest -C python3

Werten Sie Netzwerk- und Prozess-Logs auf folgende Indikatoren aus: eingehende ZeroMQ-Verbindungen von IP-Adressen außerhalb des eigenen Cluster-Netzes, unerwartete Subprozesse, die vom SGLang-Serving-Prozess gestartet wurden (insbesondere Shell-Aufrufe), sowie Abstürze oder Neustarts des DiffusionServer-Prozesses ohne erkennbaren Auslöser — ein typisches Muster bei fehlgeschlagenen Exploit-Versuchen mit inkompatiblen Payloads.

Betreiberempfehlung

Akut handeln, wenn: Sie SGLang 0.5.11 bis 0.5.14 im Disaggregated-Diffusion-Modus betreiben und der DiffusionServer-Port von außerhalb des eigenen Inferenz-Clusters erreichbar ist. Isolieren Sie den Port sofort per Firewall oder NetworkPolicy und beobachten Sie die Projekt-Repository-Advisories für einen Fix.

Beobachten genügt, wenn: Sie SGLang ausschließlich im Single-Node-Betrieb ohne Diffusion-Orchestrierung einsetzen oder Ihre Inferenz-Knoten bereits konsequent in einem isolierten, nicht von außen erreichbaren Netzwerksegment laufen. Ein Update auf eine gepatchte Version bleibt dennoch Pflicht, sobald sie erscheint.

Fazit

CVE-2026-93088 reiht sich in ein wiederkehrendes Muster bei SGLang ein: verteilte Serving-Architekturen tauschen Daten über ZeroMQ aus und deserialisieren sie ungeprüft mit pickle. Für Betreiber von selbst gehosteten LLM- und Diffusion-Serving-Stacks bedeutet das, Inferenz-Cluster grundsätzlich wie internes, nicht vertrauenswürdiges Netzwerk zu behandeln und niemals ungeprüft ans offene Netz zu binden — unabhängig davon, ob gerade ein CVE aktiv ist oder nicht.

Quellen

• OSV: CVE-2026-93088
• Strix AI: CVE-2026-93088 — SGLang Insecure Deserialization
• CERT/CC VU#665416: SGLang vulnerable to code execution via unsafe pickle deserialization
• Chocapikk: sglang — Unauthenticated RCE via Pickle Deserialization in ZMQ Transport
• SGLang-Projekt auf GitHub