Kurzfassung

Cocos AI enthält mit CVE-2026-92702 eine kritische Schwachstelle in Versionen bis einschließlich 0.8.2. Der CVSS-Basiswert liegt bei 9.1 und damit im kritischen Bereich. Betroffen ist die Verifikation von AMD-SEV-SNP-Attestierungen im aTLS-Handshake, wenn erwartete reportData fehlen, leer sind oder weggelassen werden.

In dieser Konstellation kann ein Gegenüber unter Umständen eine veraltete oder nicht zur aktuellen Verbindung gehörende Attestierung vorlegen, die dennoch akzeptiert wird. Behoben ist das Problem laut NVD in Cocos AI 0.9.0.

Was ist passiert?

Die Schwachstelle sitzt nicht in der Verschlüsselung selbst, sondern in der Vertrauensprüfung rund um attestiertes TLS. Cocos AI nutzt vertrauliche Ausführungsumgebungen, damit KI-Workloads in geschützten Enklaven laufen. Dabei soll die Gegenstelle kryptografisch nachweisen, dass sie tatsächlich in der erwarteten vertrauenswürdigen Umgebung arbeitet.

Genau diese Bindung an die aktuelle Verbindung kann in bestimmten Fällen ausfallen. Wenn die prüfende Seite kein erwartetes reportData vorgibt, einen leeren Wert verwendet oder diesen Schritt ganz auslässt, wird die Frische der Attestierung nicht erzwungen. Dadurch kann eine Partei einer Attestierung vertrauen, die gar nicht für diese konkrete Verbindung ausgestellt wurde.

Für Unternehmen ist das vor allem dort relevant, wo Attestierungen als Grundlage für Freigaben, Autorisierung oder Vertrauensentscheidungen dienen. Wer Cocos AI nur testweise einsetzt oder die betroffene Verifikationslogik nicht nutzt, hat möglicherweise kein akutes Risiko. In produktiven vertraulichen KI-Umgebungen sollte das Thema aber zügig geprüft werden.

Technische Details

Betroffen ist laut NVD der AMD-SEV-SNP-Verifikationspfad im intra-handshake attested TLS von Cocos AI bis einschließlich 0.8.2. Wenn expected reportData nil, leer oder nicht gesetzt ist, bleibt das SEV-SNP-Policy-Feld ReportData ungesetzt. Der Verifier akzeptiert dann auch Evidence, die nicht an die aktuelle Verbindung gebunden ist oder aus einem früheren Kontext stammt.

Der CVSS-Basiswert beträgt 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). Das bedeutet technisch: Angriffe sind über das Netzwerk möglich, mit geringer Komplexität, ohne Anmeldung und ohne Nutzerinteraktion; der Wert beschreibt die technische Schwere, nicht automatisch eine bereits beobachtete Ausnutzung in der Praxis.

Die Auswirkungen liegen laut Bewertung vor allem bei Vertraulichkeit und Integrität auf hohem Niveau, nicht bei der Verfügbarkeit. Das passt zum Fehlerbild: Es geht um falsches Vertrauen in eine Attestierung, nicht um einen klassischen Absturz oder einen Denial-of-Service-Effekt. Ein nicht leer gesetztes reportData wird weiterhin validiert.

Wer ist betroffen?

Betroffen sind Installationen von Cocos AI bis einschließlich Version 0.8.2. Als behobene Version nennt NVD 0.9.0.

Praktisch relevant ist die Schwachstelle vor allem für Organisationen, die Cocos AI in Verbindung mit AMD SEV-SNP und attestiertem TLS einsetzen und dabei Attestierungsdaten für Vertrauens- oder Autorisierungsentscheidungen heranziehen. Wer diesen Verifikationspfad nicht nutzt oder immer ein korrektes, nicht leeres reportData setzt, reduziert das Risiko deutlich, sollte sich aber nicht auf Annahmen verlassen.

Für die meisten Leser im DACH-Raum ist das kein breit streuendes Massenproblem. Es betrifft eher spezialisierte Umgebungen in Cloud-, KI- und Confidential-Computing-Projekten, dort allerdings mit hoher Priorität.

Empfohlene Maßnahmen

Erstens: Aktualisieren Sie Cocos AI auf Version 0.9.0, wenn Sie das Produkt produktiv einsetzen. Das ist die zentrale Maßnahme.

Zweitens: Prüfen Sie Ihre Implementierung des aTLS-Handshake mit AMD SEV-SNP. Wenn reportData in Ihrer Umgebung leer, optional oder gar nicht gesetzt ist, sollten Sie diese Konfiguration sofort als unsicher behandeln.

Drittens: Kontrollieren Sie, ob Attestierungen in Ihren Abläufen für Freigaben, Mandantentrennung, Zugriff auf Modelle, Schlüsselmaterial oder vertrauliche Daten verwendet werden. Wo diese Entscheidungen auf der betroffenen Prüfung beruhen, ist eine Neubewertung nötig.

Viertens: Sichten Sie Protokolle und Telemetrie, soweit vorhanden. Gesucht werden ungewöhnliche oder wiederverwendete Attestierungsnachweise, inkonsistente Verbindungszusammenhänge und Vertrauen in Nachweise, die nicht eindeutig an eine einzelne Sitzung gebunden sind.

Fünftens: Wenn ein sofortiges Update nicht möglich ist, erzwingen Sie bis zur Umstellung die Verwendung eines nicht leeren expected reportData in allen relevanten Verifikationspfaden. Diese Zwischenmaßnahme ersetzt das Update nicht, kann das unmittelbare Risiko aber senken.

Einschätzung von CyberSecurity-News.de

Die technische Schwere ist hoch, die praktische Reichweite aber begrenzt auf einen spezialisierten Einsatzbereich. CVSS 9.1 klingt nach akuter Breitengefahr, tatsächlich betrifft die Schwachstelle vor allem Organisationen, die Confidential Computing mit AMD SEV-SNP und attestiertem TLS bewusst einsetzen. Für diese Zielgruppe ist die Lücke allerdings ernst, weil sie genau den Vertrauensanker angreift, auf dem sensible Entscheidungen aufbauen.

Die Informationslage ist knapp, aber ausreichend für eine erste Einordnung: betroffene Versionen bis 0.8.2, behoben in 0.9.0, klarer technischer Auslöser. Was fehlt, sind weitergehende Herstellerdetails zu realistischen Angriffsszenarien, möglichen Erkennungsmerkmalen und Empfehlungen für forensische Prüfungen. NVD hat den Fall technisch präzise beschrieben, aber ohne zusätzliche Herstellerhinweise bleibt für Admins noch Arbeit bei der Risikoanalyse im eigenen Betrieb.

Andere Medien werden den kritischen CVSS-Wert vermutlich stark betonen. Entscheidend ist hier jedoch weniger die reine Zahl als die Frage, ob Ihr Unternehmen diesen Attestierungsmechanismus tatsächlich im Sicherheitsmodell nutzt. Wenn ja, hat das Thema Priorität. Wenn nein, ist die Schwachstelle für viele Leser kaum relevant.

Fazit

Unternehmen mit Cocos AI in vertraulichen KI- oder Enklaven-Umgebungen sollten jetzt prüfen, ob sie den betroffenen aTLS-Verifikationspfad mit AMD SEV-SNP einsetzen, und rasch auf Version 0.9.0 aktualisieren. Besonders kritisch ist jede Umgebung, in der Attestierungen direkt über Vertrauen, Zugriff oder Autorisierung entscheiden.

Wer Cocos AI nicht nutzt oder keine SEV-SNP-basierte Attestierung im beschriebenen Pfad verwendet, muss das Thema in der Regel nicht priorisieren. Für betroffene Spezialumgebungen ist die Schwachstelle dagegen klar handlungsrelevant.

Quellenangabe

Weiterführende Informationen: NVD-Eintrag zu CVE-2026-92702