SGLang-Lücke bei NEAR AI ausgenutzt: was Sie tun, solange es weder CVE noch Fix-Version gibt

/01Was am 8. November bei NEAR AI passiert ist

Ein Angreifer hat über eine Schwachstelle in SGLang Code auf einem Inferenzserver von NEAR AI ausgeführt. NEAR AI hat das am 9. November 2026 in einem eigenen Vorfallsbericht offengelegt, The Hacker News hat am 10. November darüber berichtet und den Vorfall auf den Sonntag davor gelegt. SGLang ist eine quelloffene Engine für die Inferenz von Sprachmodellen — dieselbe Softwareklasse wie vLLM, im Mittelstand seltener, bei Anbietern mit hoher Last verbreitet.

Der Bericht von NEAR AI nennt den Schaden in Zahlen:

• Rund 100 Nutzer: Der Angreifer lud Kontodaten herunter — E-Mail-Adresse, Name, teils Tarif und Guthaben. Laut The Hacker News lagen sie in einem internen System hinter „Private Chat“, einem bereits abgekündigten Produkt.
• 18 Agenten: Auf einer Altinstallation von NEAR AI Agents wurden Chatverläufe, Einstellungen und Logs abgerufen.
• 2 API-Schlüssel: Die Schlüssel zweier Cloud-Kunden standen in Logs. NEAR AI hat beide widerrufen.
• Laufende Anfragen: Am 8. November hätte der Angreifer Anfragen beobachten können, die auf dem betroffenen Server verarbeitet wurden — ausdrücklich auch solche im „confidential mode“.

Für gespeicherte Private-Chat-Unterhaltungen und hochgeladene Dateien fand NEAR AI nach eigener Angabe keinen Hinweis auf einen Zugriff. Als Gegenmaßnahmen nennt der Bericht: alle aktiven Sitzungen und Administrator-Zugangsdaten widerrufen, alle Agenten-Token ersetzt, Private Chat vom Netz genommen, einen Fix für die SGLang-Lücke auf allen Inferenzservern ausgerollt, die übrigen Zugangsdaten rotiert, eine forensische Prüfung durchgeführt, die Betroffenen informiert und die Schwachstelle an das SGLang-Projekt gemeldet.

Die Übertragung auf ein Haus mit einem oder zwei GPU-Servern ist kurz. Die Inferenz-Engine ist der Prozess, der jede Anfrage im Klartext sieht: jeden Prompt, jedes Dokument aus dem RAG-Kontext, jede Antwort. Wer auf diesem Prozess Code ausführt, liest mit. Wo SGLang gegenüber anderen Engines steht, haben wir im Engine-Vergleich vLLM, SGLang, TensorRT-LLM beschrieben; hier geht es um den Vorfall und um das Vorgehen ohne Patch-Angabe.

/02Was nicht bekannt ist: keine CVE, kein Advisory, keine Version

Der Bericht ist offen, was den Schaden angeht, und knapp, was die Lücke angeht. NEAR AI beschreibt sie nur als „a remote code execution vulnerability in SGLang“. Welche Komponente betroffen ist, welche Version lief, wie der Angreifer den Server erreichte und mit welcher Version der Fehler behoben ist, steht nicht darin. Die Formulierung zum Fix lautet, man habe ihn „across all inference servers“ ausgerollt — ohne Versionsnummer. The Hacker News hält dieselben Lücken ausdrücklich fest.

Die letzte Zeile verdient einen zweiten Blick. Das Release v0.5.23 ist vom 2. November datiert, also sechs Tage vor dem 8. November. Seine Release Notes haben einen Abschnitt „Security“; darin steht unter anderem „Avoid unsafe pickle fallback when loading PyTorch checkpoints“ sowie ein Eintrag zu Abhängigkeiten mit RustSec-Meldungen. Einen Bezug zum Vorfall stellt niemand her: weder die Release Notes noch NEAR AI noch die Berichterstattung. Wer daraus „0.5.23 ist der Fix“ liest, rät. Das Update lohnt sich wegen der genannten Härtungen trotzdem — nur eben nicht als Entwarnung.

Für den Betrieb hat das zwei Folgen. Kein Schwachstellen-Scanner meldet etwas, denn Scanner gleichen Versionen gegen Advisories ab, und es gibt keines. Und „Patchen“ hat vorerst kein Ziel, weil niemand sagen kann, welche Version sicher ist.

/03Warum die vertrauliche Umgebung nicht geholfen hat

NEAR AI bietet einen „confidential mode“ an, bei dem Anfragen in einer vertrauenswürdigen Ausführungsumgebung (TEE) laufen. Im Bericht steht dazu ein Satz, den jeder Betreiber kennen sollte: Die Umgebung schütze nicht „against a vulnerability in the software running inside the environment“. Ein TEE trennt die Arbeitslast vom Betreiber des Hosts und von dessen Administratoren. Gegen Code, der innerhalb der Umgebung im Namen der Engine läuft, hilft sie nicht — dieser Code steht auf derselben Seite der Grenze wie die Anfragen.

Dazu kommt ein zweiter Punkt aus der Berichterstattung: Die 18 betroffenen Agenten liefen laut The Hacker News auf einer älteren Installation, die gar nicht im TEE des Unternehmens lag. Altbestände und abgekündigte Produkte haben in diesem Vorfall also den größeren Teil des Datenabflusses getragen. Was ein TEE leistet und wo die Attestierung endet, steht in Confidential Computing für LLMs.

Für den Mittelstand folgt daraus keine Aussage über TEEs, sondern über Schichten. On-Premise heißt nicht automatisch abgeschottet, verschlüsselter Speicher heißt nicht, dass der Dienst unangreifbar ist. Eine Schutzschicht deckt genau das Bedrohungsbild ab, für das sie gebaut wurde. Die Netztrennung des Inferenz-Ports ist eine eigene Schicht, und sie fehlt erstaunlich oft.

/04Bestandsaufnahme: wo SGLang läuft und wer den Port erreicht

Der erste Schritt kostet zehn Minuten und braucht kein Wartungsfenster. Sie klären drei Dinge: ob SGLang überhaupt läuft, in welcher Version, und von wo der Port erreichbar ist. Die meisten Mittelständler finden SGLang nicht auf dem Produktivsystem, sondern auf einem Testserver oder der Workstation eines Entwicklers — vergessene Proof-of-Concept-Reste sind der übliche Fundort.

# 1. Läuft SGLang, und in welcher Version?
pip show sglang 2>/dev/null | grep -E '^(Name|Version)'
docker ps | grep -i sglang

# 2. Worauf lauscht der Dienst?
ss -tlnp | grep -E ':(30000|8000|11434) '
#   127.0.0.1:30000   nur vom Server selbst erreichbar
#   0.0.0.0:30000     auf allen Schnittstellen erreichbar

# 3. Gegenprobe von einem ANDEREN Rechner im Büronetz
nc -zv -w 3 gpu01.example.internal 30000
#   "succeeded" oder "open" heißt: der Port ist im Netz sichtbar

Zur Einordnung der Ausgabe: SGLang bindet laut Dokumentation standardmäßig an 127.0.0.1 und nutzt Port 30000. Ein unveränderter Start ist also von außen nicht erreichbar. Die Öffnung entsteht durch Entscheidungen im Betrieb. In einem Docker-Container muss der Dienst an 0.0.0.0 lauschen, damit die Portweiterleitung greift, und ein -p 30000:30000 veröffentlicht den Port dann auf allen Schnittstellen des Hosts. Docker schreibt dafür eigene Paketfilter-Regeln, an einer Host-Firewall wie ufw vorbei. Unter Kubernetes erledigt ein Service vom Typ NodePort oder LoadBalancer dasselbe.

Die Ports 8000 und 11434 stehen in der Prüfung, weil die Frage nicht an SGLang hängt: Auf ihnen lauschen üblicherweise vLLM und Ollama. Die Gegenprobe in Schritt 3 gehört von einem Arbeitsplatzrechner aus gemacht, nicht vom Server, und zusätzlich einmal von außerhalb des Hauses. Ein Port, der aus dem Internet antwortet, ist ein eigener Befund und wird vor allem anderen geschlossen.

/05Den Inferenz-Port unerreichbar machen

Ziel ist ein Zustand, in dem genau ein System mit der Engine spricht: das Gateway oder der Reverse Proxy, der Benutzer anmeldet und Anfragen weiterreicht. Alle anderen — Arbeitsplätze, Entwicklerrechner, Nachbarserver — erreichen den Port nicht. Dafür gibt es vier Stellschrauben, die sich ergänzen.

Bindung und Schlüssel beim Start

# Gateway und Engine auf demselben Host: nur lokal binden
python -m sglang.launch_server \
  --model-path /models/ihr-modell \
  --host 127.0.0.1 --port 30000 \
  --api-key "$(cat /etc/sglang/api.key)" \
  --admin-api-key "$(cat /etc/sglang/admin.key)"

# Im Container: Port nur auf der Loopback-Adresse des Hosts veröffentlichen
docker run --gpus all -p 127.0.0.1:30000:30000 ...

Die Dokumentation beschreibt --api-key als Schlüssel des Servers, der auch für die OpenAI-kompatible Schnittstelle gilt, und --admin-api-key als Schlüssel für Verwaltungsendpunkte wie Gewichts-Update, Cache-Leerung und /server_info. Beide stehen im Auslieferungszustand auf „None“. Die Verwaltungsendpunkte verlangen den Admin-Schlüssel laut Dokumentation nur, „when this is set“ — er gehört also gesetzt. Ein Nachteil der Schreibweise oben: Die Schlüssel stehen in der Prozessliste des Hosts. Auf einem GPU-Server sollten deshalb keine fremden Benutzerkonten liegen.

Paketfilter, wenn das Gateway auf einem anderen Host steht

# /etc/nftables.d/inferenz.nft — nur das Gateway (10.20.0.10) darf an Port 30000
table inet inferenz {
  chain input {
    type filter hook input priority 0; policy accept;
    tcp dport 30000 ip saddr 10.20.0.10 accept
    tcp dport 30000 drop
  }
}

Die Regel greift für Dienste, die direkt auf dem Host laufen. Für veröffentlichte Container-Ports gilt sie nicht, weil Docker den Verkehr vor der Eingangskette umleitet; Einschränkungen gehören dort in die von Docker vorgesehene Kette DOCKER-USER oder — einfacher und robuster — in die Portangabe mit Loopback-Adresse wie oben.

Gateway mit Anmeldung davor

Die Engine kennt einen Schlüssel für alle, keine Benutzer. Wer wissen will, welche Anwendung welche Anfrage gestellt hat, und wer einzelne Zugänge sperren können will, braucht davor eine Schicht mit eigenen Schlüsseln je Anwendung, TLS und Protokoll. Das allgemeine Muster — Bindung, Proxy, Schlüssel, Ratenbegrenzung für vLLM und Ollama — steht in LLMjacking stoppen und gilt für SGLang unverändert.

/06Schaden begrenzen: Schlüssel, Logs und Rechte des Dienstes

Die zweite Hälfte der Arbeit geht davon aus, dass die erste versagt. Wenn auf dem Inferenzserver fremder Code läuft, entscheidet die Umgebung, was er findet. Bei NEAR AI waren es unter anderem zwei API-Schlüssel in Logs. Das ist keine Formsache: Ein Schlüssel im Log überlebt jede Rotation des Dienstes, weil er in Sicherungen und Log-Sammlern weiterlebt.

Logs auf Schlüssel prüfen

# Stehen Schlüssel oder Bearer-Token in Logs? (-l nennt nur die Dateien)
grep -rlE 'Bearer [A-Za-z0-9._-]{20,}|sk-[A-Za-z0-9_-]{20,}' /var/log /srv/sglang/logs 2>/dev/null

# Dasselbe für das Journal des Dienstes (zählt nur die Treffer)
journalctl -u sglang --since "2026-10-01" | grep -cE 'Bearer |api[_-]?key'

# Welche Log-Schalter kennt die installierte Version?
python3 -m sglang.launch_server --help | grep -i log

Schlüssel geraten auf vier Wegen ins Log: über ein Proxy-Logformat, das den Authorization-Header mitschreibt; über Schlüssel in der URL statt im Header; über Debug-Protokollierung ganzer Anfragen; und über Anwendungen, die beim Start ihre Konfiguration ausgeben. Jeder Treffer der Suche oben wird wie ein offengelegter Schlüssel behandelt — widerrufen, neu ausstellen, Logformat korrigieren. Das geht nur ohne Betriebsstillstand, wenn jede Anwendung ihren eigenen Schlüssel hat.

Den Dienst entrechten

# /etc/systemd/system/sglang.service.d/haertung.conf — Ausgangspunkt, im Testbetrieb prüfen
[Service]
User=sglang
Group=sglang
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/lib/sglang
IPAddressDeny=any
IPAddressAllow=localhost 10.20.0.10
# PrivateDevices bewusst NICHT setzen: der Dienst braucht die GPU-Geräte

Die Direktiven sind Standard von systemd; ob die Engine mit ihnen sauber startet, zeigt nur ein Probelauf mit Ihrem Modell. Der Gedanke dahinter ist wichtiger als die einzelne Zeile. Die Engine läuft unter einem eigenen Konto ohne Anmelderecht. Die Gewichte liegen in einem Verzeichnis, das der Dienst nur lesen darf. Auf dem Host liegen keine Zugangsdaten, die mit Inferenz nichts zu tun haben: keine Cloud-Schlüssel, kein Hugging-Face-Token mit Schreibrecht, keine SSH-Schlüssel für andere Server. Und der Dienst darf keine Verbindungen nach außen aufbauen — eine Engine mit lokal liegenden Modellen braucht im Betrieb kein Internet. IPAddressDeny=any setzt das für den Dienst durch, eine Ausgangsregel am Paketfilter für den ganzen Host.

Dasselbe gilt für die Daten neben der Engine. Chatverläufe, Agenten-Einstellungen und Benutzerkonten gehören nicht auf denselben Host wie die GPU-Arbeitslast, wenn es sich vermeiden lässt. Bei NEAR AI führte der Weg vom Inferenzserver zu einem internen System und zu einer Altinstallation; je weniger Nachbarn ein Inferenzserver erreichen kann, desto kürzer wird diese Liste.

/07Grenzen: was Abschottung nicht löst

Die Maßnahmen aus /05 und /06 sind richtig, aber sie beantworten eine Frage, die der Bericht offen lässt. Niemand außerhalb von NEAR AI und dem SGLang-Projekt weiß, ob der Angreifer den Port direkt erreichen musste oder ob eine präparierte Anfrage genügt, die auf dem regulären Weg durch ein Gateway läuft. Im ersten Fall schließt die Netztrennung den Weg. Im zweiten senkt sie nur die Zahl derer, die ihn gehen können: von „jeder im Netz“ auf „jeder mit gültigem Zugang“ — und auf jeden Inhalt, den ein Agent oder eine Dokumentenstrecke ungeprüft an das Modell weiterreicht.

Weitere Grenzen, die Sie kennen sollten:

• Der API-Schlüssel ist ein geteiltes Geheimnis. Er steht in Konfigurationsdateien mehrerer Anwendungen und lässt sich nicht einer Person zuordnen. Er ist eine zweite Schicht, kein Benutzerkonzept.
• Die Firewall vertraut dem Gateway. Wird der Gateway-Host übernommen, steht der Inferenz-Port wieder offen. Das Gateway ist damit das System mit dem höchsten Schutzbedarf im KI-Netz.
• Es gibt keine veröffentlichten Erkennungsmerkmale. Der Bericht nennt weder Adressen noch Dateinamen noch Log-Muster. Ob ein eigener Server betroffen war, lässt sich deshalb nicht gezielt prüfen, nur allgemein: unerwartete Kindprozesse der Engine, ausgehende Verbindungen des Dienstkontos, neue Dateien außerhalb des Arbeitsverzeichnisses.
• Ein Update ohne Advisory ist eine Wette. Aktuell zu bleiben ist richtig; „aktuell“ ist aber nicht dasselbe wie „behoben“, solange das Projekt nichts dazu sagt.

Ehrlich: Für ein Haus, das ausschließlich vLLM oder Ollama betreibt, ist dieser Vorfall kein Handlungsauftrag. Die Lücke steckt in SGLang, nicht im Model Serving an sich. Übrig bleibt die Portprüfung aus /04 — die ist für jede Engine dieselbe und in zehn Minuten erledigt.

/08Entscheidung: wer sofort handeln muss und wer nicht

Die Dringlichkeit hängt an zwei Fragen: ob SGLang läuft und wie weit der Port sichtbar ist. Daraus ergeben sich vier Lagen.

Eine Frage kommt in solchen Wochen regelmäßig: ob man die Engine wechseln sollte. Als Reflex nein. Ein Wechsel der Engine ist ein Projekt mit eigener Abnahme — Durchsatz, Prompt-Vorlagen, Verhalten bei strukturierter Ausgabe —, und er tauscht ein Risiko mit unbekannter Fix-Version gegen die Risiken einer Umstellung unter Zeitdruck. Auch andere Engines veröffentlichen Sicherheitsmeldungen; was das im Alltag heißt, zeigt unser Beitrag zum Sicherheitsupdate vLLM 0.32. Ein belastbares Kriterium für die Engine-Wahl ist, ob ein Projekt Lücken mit Version und Datum meldet. Ob SGLang das für diesen Fall tut, ist wenige Tage nach dem Bericht noch nicht zu beurteilen.

Abschalten ist dort die richtige Antwort, wo die Abschottung kurzfristig nicht herzustellen ist — etwa bei einem Testsystem in einem gemieteten Netz, auf dessen Firewall Sie keinen Zugriff haben. Ein abgeschaltetes Testsystem kostet nichts, ein übernommenes kostet die Schlüssel, die darauf liegen.

/09Beobachten, bis ein Advisory erscheint

Die Abschottung bleibt, auch wenn ein Advisory kommt. Was sich mit dem Advisory ändert, ist die Möglichkeit, Versionen zu vergleichen und gezielt zu aktualisieren. Bis dahin lohnt eine kleine Routine im Rahmen des LLMOps-Alltags.

# Veröffentlichte Advisories des Projekts (leere Liste = keines)
gh api repos/sgl-project/sglang/security-advisories

# Die fünf jüngsten Releases
gh release list -R sgl-project/sglang -L 5

# Installierte Version zum Abgleich
pip show sglang | grep '^Version'

Drei Quellen genügen: die Advisory-Seite des SGLang-Repositorys, die Release Notes und der Vorfallsbericht von NEAR AI, falls er ergänzt wird. Sobald eine betroffene Version genannt ist, vergleichen Sie sie mit der Ausgabe aus /04, planen das Update in ein Wartungsfenster und prüfen danach mit einem festen Satz eigener Anfragen, dass Antworten und Durchsatz stimmen. Ein Update der Engine kann Verhalten ändern; ein Checkpoint, der unter der alten Version lud, lädt nach einer Härtung des Ladewegs womöglich nicht mehr — die Zeile zum Pickle-Rückfallweg in v0.5.23 ist ein Beispiel für genau diese Art Änderung.

Halten Sie außerdem fest, was Sie geprüft haben: Datum, Version, Ergebnis der Portprüfung, Treffer der Log-Suche, getroffene Maßnahmen. Das ist eine halbe Seite. Sie beantwortet die Frage der Geschäftsführung, ob das Haus betroffen ist, und sie ist der Nachweis, den ein Informationssicherheits-Management bei der nächsten Prüfung sehen will. Wer die Inferenz als Teil eines größeren Angriffsbilds testen möchte, nimmt den Fall in das nächste Red-Teaming auf: nicht als Nachbau des Angriffs, den niemand kennt, sondern als Annahme „auf dem Inferenzserver läuft fremder Code“ — und als Frage, was er von dort aus erreicht.