CERT/CC hat den Sicherheitshinweis VU#645818 veröffentlicht, in dem eine Schwachstelle zur Umgehung der Authentifizierung im Console API der Such- und Indexierungs-Engine Xerj beschrieben wird – einer offenen Lösung, die auf AI-Agenten ausgerichtet ist und mit dem Elasticsearch API kompatibel ist. Die Schwachstelle CVE-2026-97406 ermöglicht es einem Angreifer, der über einen gültigen API-Token verfügt, unabhängige „untergeordnete“ Zugangsdaten mit demselben Zugriffslevel zu erstellen und dabei die Anforderung der passkey-Authentifizierung zu umgehen. Ein kritischer Punkt: Der Widerruf des kompromittierten übergeordneten Tokens hat keine Auswirkung auf die daraus erzeugten untergeordneten Tokens. Zum Zeitpunkt der Veröffentlichung des Sicherheitshinweises stand kein offizieller Patch zur Verfügung, und es gelang den CERT/CC-Koordinatoren nicht, den Entwickler zu kontaktieren. Organisationen, die Xerj einsetzen, sollten unverzüglich alle ausgegebenen API-Tokens prüfen und den Zugriff auf das Console API einschränken.
Technische Details der Schwachstelle
Dem Sicherheitshinweis von CERT/CC zufolge sieht die Xerj-Architektur vor, dass das Ausstellen neuer API-Tokens ausschließlich durch eine Sitzung autorisiert werden darf, die über einen passkey bestätigt wurde. In der Implementierung werden jedoch sowohl gewöhnliche Browsersitzungen als auch API-Bearer-Tokens in ein einheitliches generisches Objekt AuthSession konvertiert. Der Handler zur Erstellung von Tokens akzeptiert dieses Objekt, ohne zu überprüfen, ob die Sitzung tatsächlich per passkey authentifiziert wurde.
Die angreifbare Oberfläche ist das integrierte Console-Backend, das gemäß der Architekturdokumentation des Projekts unter dem Pfad /_xerj-console/api/v1/* eingebunden wird. Gleichzeitig besagt die Dokumentation zur Autorisierung, dass nur ein Superuser Schlüssel mit eingeschränktem Geltungsbereich erstellen darf – die Schwachstelle ermöglicht es jedoch, diese Einschränkung zu umgehen.
Wesentliche Merkmale der Schwachstelle:
- Voraussetzung: Der Angreifer muss einen gültigen Xerj API-Token erlangen oder abfangen
- Mechanismus: Direkter Aufruf des Token-Erstellungsendpunkts über Bearer-Authentifizierung ohne passkey-Bestätigung
- Ergebnis: Erstellung unabhängiger Zugangsdaten mit Rechten, die den Rechten des ursprünglichen Tokens entsprechen
- Persistenz: Die Plattform implementiert keine hierarchische Widerrufslogik – untergeordnete Tokens bleiben auch nach Widerruf des übergeordneten Tokens aktiv
Für CVE-2026-97406 wird in den verfügbaren Unterlagen keine CVSS-Bewertung angegeben. Der Bereich der betroffenen Versionen ist ebenfalls nicht festgelegt.
Szenario der Eskalation bis zur vollständigen Übernahme einer Instanz
Nach Angaben von CERT/CC stellt die Schwachstelle die größte Gefahr dar, wenn ein Token kompromittiert wird, das dem Inhaber eines Xerj-Kontos gehört. In diesem Fall wird folgende Angriffskette beschrieben: Der Angreifer erstellt ein untergeordnetes Token mit vollen Administrationsrechten und nutzt dieses anschließend, um eine Einladung für ein neues Konto auszustellen, aktiviert die Einladung im eigenen Browser und registriert einen vollständig unabhängigen passkey unter seiner Kontrolle. Das Ergebnis ist ein dauerhafter Zugriff auf die Xerj-Instanz und ihre Datenindizes, der sich durch den Widerruf des ursprünglich kompromittierten Tokens nicht beseitigen lässt.
Im Sicherheitshinweis wird dies als vollständige Umgehung von Mehrfaktor-Kontrollen charakterisiert, da die passkey-Anforderung – das zentrale Schutzelement – vollständig neutralisiert wird.
Auswirkungsanalyse
Xerj wird als Such-Engine für AI-Agenten positioniert, die lokale Daten indexiert. Die Kompromittierung einer Instanz eröffnet potenziell Zugriff auf alle indexierten Daten – einschließlich Quellcode, Dokumentation und anderer Materialien, die AI-Agenten bei ihrer Arbeit verwenden. Für Organisationen, die Xerj in AI-gestützte Entwicklungsprozesse integriert haben, können die Folgen die Offenlegung geistigen Eigentums und die Kompromittierung der Lieferkette der Daten für AI-Modelle umfassen.
Hinweise auf eine aktive Ausnutzung der Schwachstelle in realen Angriffen fanden sich in den verfügbaren Unterlagen nicht. Eine Zuordnung zu konkreten Gruppen oder Kampagnen liegt ebenfalls nicht vor.
Status der Fehlerbehebung und Empfehlungen
CERT/CC berichtet, dass der Entwickler für eine koordinierte Offenlegung nicht erreicht werden konnte und zum Veröffentlichungsdatum des Sicherheitshinweises (20. Oktober 2026) kein offizieller Patch vorlag. Auf der Release-Seite des Projekts ist die Version v1.0.0-rc.96 veröffentlicht, in deren Release-Beschreibung jedoch kein Hinweis auf die Behebung von CVE-2026-97406 zu finden ist. Dies schließt das Vorhandensein einer Korrektur nicht aus, bestätigt sie jedoch auch nicht.
Bis ein bestätigter Patch vorliegt, wird empfohlen:
- Den Netzwerkzugang zum Console API (
/_xerj-console/api/v1/*) einzuschränken – Verbindungen nur aus vertrauenswürdigen Netzen zuzulassen oder den Endpunkt vollständig zu schließen, falls die Konsole nicht genutzt wird - Einen Audit aller ausgegebenen API-Tokens durchzuführen – Tokens zu identifizieren, die über das API (und nicht über eine passkey-Sitzung) erstellt wurden, und sowohl diese als auch alle potenziell von ihnen abgeleiteten untergeordneten Zugangsdaten zu widerrufen
- Die Historie von Einladungen und passkey-Registrierungen zu überprüfen – jede Einladung oder Registrierung eines neuen passkey, die auf die Erstellung eines API-Tokens folgt, sollte als verdächtig eingestuft werden
- Monitoring einzurichten – Aufrufe des Endpunkts zur Token-Erstellung und anschließende Vorgänge zum Ausstellen von Einladungen oder zur Registrierung von passkeys zu überwachen, da genau diese Abfolge von Aktionen für die beschriebene Angriffskette charakteristisch ist
- Updates zu verfolgen im offiziellen Xerj-Repository und ein Update nicht als Behebung von CVE-2026-97406 zu betrachten, solange dies nicht ausdrücklich in den Release Notes bestätigt wird
Es ist von grundlegender Bedeutung zu verstehen, dass der einfache Widerruf eines kompromittierten Tokens keine ausreichende Reaktionsmaßnahme darstellt. Aufgrund der fehlenden hierarchischen Widerrufslogik bleiben alle untergeordneten Tokens, die vor der Entdeckung erstellt wurden, weiterhin gültig. Die Reaktion auf einen Vorfall muss einen vollständigen Austausch aller Tokens der Instanz und eine Überprüfung der registrierten passkeys umfassen.
