CVE-2026-77776: Headroom-LLM-Proxy erlaubt fremden Zugriff auf gespeicherten Chat-Speicher

Kurzfassung

Bei Headroom liegt eine kritische Schwachstelle vor. Der LLM-Proxy übernimmt die Identität eines Nutzers direkt aus einem HTTP-Header und prüft sie nicht sauber gegen den tatsächlichen Absender. Das öffnet den Weg zu fremden gespeicherten LLM-Memory-Daten.

Für Angreifer reicht damit im Kern ein manipuliertes Header-Feld. Sie können sich als anderer Nutzer ausgeben und dessen Memory lesen oder überschreiben.

Was ist passiert?

Die Schwachstelle steckt in Headrooms Proxy-Schicht. Dort wird der Wert aus dem Header x-headroom-user-id an mehreren Stellen direkt verwendet, unter anderem bei Chat-Completion-Anfragen und über WebSockets.

Das Problem: Der Proxy bindet diesen Wert nicht an den echten Aufrufer. Wer den Header setzt, kann eine beliebige Nutzerkennung vorgeben. Genau daraus leitet der Dienst dann den Speicherbesitzer ab.

Die Folge ist ein klassischer Identitätsbruch auf Anwendungsebene. Der Server vertraut einem vom Client gelieferten Wert, obwohl dieser nie eine belastbare Authentisierung darstellt.

Technische Details

Die betroffene Logik sitzt laut Quelle in headroom/proxy/handlers/openai.py. Dort liest der Proxy den Header direkt aus und nutzt ihn für die Zuordnung des Memorys.

Der Fix führt eine zentrale Stelle ein, resolve_memory_identity in headroom/proxy/identity.py. Diese Funktion akzeptiert den Header nur noch für Loopback oder ausdrücklich erlaubte Aufrufer. In allen anderen Fällen bindet sie die Identität an den Fingerprint des Proxy-Tokens oder an den Betriebssystemnutzer.

Wichtig für den Betrieb: Das per pip gestartete Konsolen-Skript bindet standardmäßig an 127.0.0.1. Die mitgelieferte docker-compose.yml startet den Dienst laut Quelle aber mit --host 0.0.0.0, veröffentlicht Ports und verlangt kein HEADROOM_PROXY_TOKEN. Der Server warnt beim Start sogar selbst vor dieser Konfiguration. Wer das Compose-Setup unverändert übernimmt, stellt die betroffenen Datenpfade damit ins Netz.

Zur CVSS-Bewertung nennt die Quelle nur den Schweregrad CRITICAL. Eine konkrete Punktzahl ist im Auszug nicht enthalten.

Wer ist betroffen?

Betroffen sind Systeme, auf denen Headroom mit dem verwundbaren Proxy läuft. Besonders relevant ist das für Installationen, die das mitgelieferte Docker-Setup nutzen und den Dienst nach außen exponieren.

Für Unternehmen im DACH-Raum ist das kein Randthema, wenn Headroom produktiv an interne LLM-Workflows, Wissensspeicher oder Support-Assistenten angebunden ist. Dann kann ein Angreifer mit Netzwerkkontakt auf gespeicherte Inhalte zugreifen, die oft sensible Informationen enthalten: Gesprächsverläufe, interne Prompts, Notizen oder Kontextdaten.

Ob auch andere Bereitstellungswege außer dem genannten Compose-Stack verwundbar sind, lässt die Quelle offen. Klar ist nur: Die direkte Übernahme eines Header-Werts ohne Bindung an die echte Identität ist das eigentliche Problem.

Empfohlene Maßnahmen

Wer Headroom betreibt, sollte zuerst prüfen, wie der Dienst erreichbar ist. Wenn der Proxy aus dem Netz erreichbar ist, sofort Zugriff einschränken oder den Dienst vorübergehend abschotten.

Dann das Update bzw. den Hersteller-Fix einspielen, sobald verfügbar. Der zentrale Punkt ist die neue Identitätsauflösung über resolve_memory_identity; genau dort liegt die Korrektur.

Bis dahin gilt: keine offene Veröffentlichung über 0.0.0.0, kein unveränderter Betrieb des gelieferten Docker-Setups, und wenn möglich ein zwingend gesetzter HEADROOM_PROXY_TOKEN. Wer den Dienst nur lokal braucht, sollte ihn konsequent an 127.0.0.1 binden.

Admins sollten außerdem prüfen, ob bereits fremde Memory-Zugriffe in Logs oder Applikationsdaten auftauchen. Das ist kein hübscher Forensik-Job, aber oft der schnellste Weg, Missbrauch zu erkennen.

Einschätzung von CyberSecurity-News.de

Die Schwachstelle ist fachlich klar und praktisch relevant. Kritisch ist vor allem, dass die unsichere Standard- oder Referenzkonfiguration den Dienst direkt angreifbar machen kann. Das ist kein exotischer Sonderfall, sondern ein typischer Fehler aus der Praxis: Ein Produkt verlässt sich auf einen vom Client gesetzten Identitätswert.

Die Kommunikation wirkt zugleich wenig komfortabel für Betreiber, weil die eigentliche Gefahr erst aus dem Zusammenspiel von Code und Deployment sichtbar wird. Wer nur auf den Patch schaut, übersieht leicht das offene Docker-Setup. Genau dort liegt im Alltag das Risiko.

Für die meisten Leser ist das Thema nur dann dringend, wenn Headroom tatsächlich im Einsatz ist. Dann aber sollte das Prüfen der Exponierung heute noch auf die Liste.

Fazit

CVE-2026-77776 erlaubt nach Angaben der Quelle das Lesen und Schreiben fremder gespeicherter LLM-Memory-Daten über einen manipulierten Header. Das ist ein ernstes Identitätsproblem mit direkter Auswirkung auf Vertraulichkeit und Integrität.

Besonders heikel ist die bereitgestellte Docker-Konfiguration. Wer Headroom produktiv nutzt, sollte die Netzexponierung sofort prüfen und den Fix einspielen, sobald er verfügbar ist.