Kurzfassung

Mnemosyne vor Version 3.10.1 enthält mit CVE-2026-59163 eine kritische Schwachstelle in der Prüfung von JSON Web Tokens. Der Eintrag erreicht CVSS 9.1, kritisch. Angreifer können über das Netzwerk ohne Anmeldung und ohne Nutzerinteraktion gültig wirkende, aber manipulierte Tokens einschleusen, sofern der betroffene Sync-Server erreichbar ist.

Was ist passiert?

Betroffen ist die Synchronisationskomponente von Mnemosyne, einer Speicher- und Persistenzschicht für KI-Agenten. In älteren Versionen wurde bei der Authentifizierung ein JWT zwar verarbeitet, die Signatur aber faktisch nicht verlässlich geprüft. Dadurch akzeptierte der Server auch Tokens, die mit dem falschen Schlüssel signiert wurden oder ganz ohne wirksame Signatur auskamen.

Der Fehler liegt damit nicht in einer exotischen Randfunktion, sondern direkt im Vertrauensmodell des Sync-Servers. Wer den Endpunkt aus dem Netz erreichen kann, kann unter Umständen die Authentifizierung umgehen. Die Korrektur steckt laut NVD in Version 3.10.1.

Technische Details

Die Schwachstelle betrifft die Token-Prüfung in mnemosyne/core/sync_server.py. Dort wurden Header und Nutzdaten des JWT per Base64 verarbeitet und anschließend an eine Bibliotheksfunktion übergeben, deren Optionen die Signaturprüfung effektiv außer Kraft setzten. Akzeptiert wurden damit beliebige formal korrekt aufgebaute Tokens, auch mit alg: none oder mit einer Signatur, die nicht zum vorgesehenen Schlüssel passte.

Der CVSS-Basiswert liegt bei 9.1 nach CVSS 3.1 mit dem Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Das bedeutet: angreifbar über das Netzwerk, geringe Komplexität, keine Berechtigungen erforderlich und keine Nutzerinteraktion nötig; Vertraulichkeit und Integrität sind stark betroffen, die Verfügbarkeit laut Bewertung nicht. Der Wert beschreibt die technische Schwere der Schwachstelle, nicht automatisch eine bereits beobachtete Ausnutzung in freier Wildbahn.

Als Abhilfe nennt der Eintrag für Version 3.10.1 eine neue HS256-Prüfung, die ausschließlich mit der Python-Standardbibliothek umgesetzt wurde. Ob darüber hinaus weitere Schutzmechanismen ergänzt wurden, ist nicht beschrieben.

Wer ist betroffen?

Betroffen sind Installationen von Mnemosyne vor Version 3.10.1. Besonders relevant ist die Lücke für Umgebungen, in denen der Sync-Server direkt aus internen Netzen, aus Kubernetes-Clustern, über Entwicklungszugänge oder sogar aus dem Internet erreichbar ist.

Für Unternehmen im DACH-Raum ist das Thema vor allem dort relevant, wo KI-Agenten, Automatisierungsdienste oder experimentelle Assistenzsysteme produktionsnah betrieben werden. In klassischen Office-Umgebungen ohne Mnemosyne-Einsatz spielt die Schwachstelle keine Rolle. Das Risiko steigt deutlich, wenn Teams solche Komponenten schnell in DevOps- oder Lab-Umgebungen ausrollen und Netzwerkfreigaben großzügig setzen.

Ist der betroffene Endpunkt nicht erreichbar, ist die Schwachstelle nach den bekannten Informationen nicht ausnutzbar. Genau diese Erreichbarkeit sollten Administratoren aber nicht annehmen, sondern aktiv prüfen.

Empfohlene Maßnahmen

Erstens: Aktualisieren Sie Mnemosyne so schnell wie möglich auf Version 3.10.1 oder neuer. Das ist die wichtigste Maßnahme, weil sie die fehlerhafte Token-Prüfung direkt beseitigt.

Zweitens: Wenn ein Update kurzfristig nicht möglich ist, schotten Sie den Sync-Server strikt ab. Sinnvoll sind Firewalls mit Positivliste, ein Reverse Proxy mit gegenseitiger Zertifikatsprüfung, ein Bind an localhost mit Zugriff nur über SSH-Tunnel oder eine vergleichbar enge Segmentierung.

Drittens: Prüfen Sie sofort, ob der Dienst unbeabsichtigt von anderen Segmenten, Build-Systemen, Jump-Hosts oder dem Internet aus erreichbar ist. Gerade in Container- und Testumgebungen entstehen solche Freigaben schnell durch Standard-Ingress-Regeln oder falsch gesetzte Port-Mappings.

Viertens: Kontrollieren Sie Protokolle und Telemetrie auf ungewöhnliche Zugriffe auf den Sync-Endpunkt. Achten Sie auf Token-Nutzung aus unerwarteten Quellnetzen, abrupte Änderungen an gespeicherten Daten und API-Aufrufe außerhalb üblicher Betriebszeiten.

Fünftens: Rotieren Sie vorsorglich relevante Geheimnisse und Sitzungsschlüssel, wenn Sie nicht sicher ausschließen können, dass unautorisierte Zugriffe stattgefunden haben. Das gilt besonders dann, wenn über Mnemosyne sensible Kontexte, Agentenstatus oder interne Arbeitsdaten gespeichert werden.

Einschätzung von CyberSecurity-News.de

Die technische Tragweite ist hoch, weil hier nicht eine Nebenfunktion scheitert, sondern die Authentifizierung selbst. Eine JWT-Prüfung, die Signaturen praktisch nicht durchsetzt, ist ein gravierender Konstruktionsfehler. Positiv ist immerhin, dass die Abhilfen für den Notbetrieb klar benannt sind: Netzwerkzugriff minimieren, idealerweise bis zum Update vollständig auf vertrauenswürdige Clients begrenzen.

Die Informationslage bleibt trotzdem begrenzt. Es gibt keine Angaben dazu, wie verbreitet Mnemosyne in produktiven Unternehmensumgebungen tatsächlich ist, ob bereits aktive Ausnutzung beobachtet wurde und ob neben 3.10.1 weitere unterstützte Versionszweige existieren. Für die Einordnung heißt das: technisch sehr kritisch, in der Praxis aber vor allem dort dringend, wo der Sync-Server überhaupt erreichbar ist.

Gegenüber vielen pauschalen Schwachstellenmeldungen ist hier ein Punkt entscheidend: Nicht jede verwundbare Installation ist automatisch akut exponiert. Wer den Endpunkt nie auslieferte oder sauber isoliert hat, senkt das Risiko stark. Wer ihn jedoch netzweit oder extern erreichbar betreibt, sollte das Problem als unmittelbaren Handlungsfall behandeln.

Fazit

Wenn Sie Mnemosyne einsetzen, prüfen Sie jetzt zuerst die eingesetzte Version und die Erreichbarkeit des Sync-Servers. Steht noch eine Version vor 3.10.1 im Einsatz, sollte das Update priorisiert und bis dahin der Netzwerkzugang strikt auf vertrauenswürdige Systeme begrenzt werden.

Quellenangabe

Weiterführende technische Details bietet der NVD-Eintrag zu CVE-2026-59163.