Kurzfassung
MaxKB vor Version 2.10.5-lts weist zwei zusammenhängende kritische Schwachstellen auf: CVE-2026-77521 und CVE-2026-79916. Besonders gravierend ist CVE-2026-77521 mit CVSS 10.0, kritisch: Darüber kann ein Angreifer über das Netzwerk ohne Anmeldung und ohne Nutzerinteraktion Befehle auslösen. Unternehmen, die MaxKB produktiv einsetzen, sollten zügig auf 2.10.5-lts aktualisieren und bis dahin den externen Zugriff begrenzen.
Was ist passiert?
Betroffen ist MaxKB, ein quelloffener KI-Assistent für Unternehmen. Die beiden Schwachstellen hängen mit der Art zusammen, wie MaxKB Werkzeuge, Shell-Aufrufe und Zugangsdaten verarbeitet.
Bei CVE-2026-77521 kann nicht vertrauenswürdiger Chat-Inhalt oder importierter Inhalt dazu führen, dass Shell-Befehle ausgeführt werden. Der Schutzmechanismus zur Bestätigung durch einen Menschen greift dabei nicht wie vorgesehen. In bestimmten Bereitstellungen laufen diese Befehle direkt mit den Rechten des Anwendungsbenutzers; im offiziellen Container konnte die Ausführung laut NVD sogar über Metazeichen aus dem beabsichtigten Rahmen ausbrechen.
CVE-2026-79916 betrifft die Verarbeitung von AWS-Bedrock-Zugangsdaten. Authentifizierte Mitglieder eines Workspace können Steuerzeichen in Zugangsdaten einschleusen. Dadurch lässt sich später bei einer Modellvalidierung ein präpariertes AWS-Profil auswählen, sodass ein vom Angreifer kontrollierter Befehl als root ausgeführt wird.
Beide Schwachstellen sind laut NVD in MaxKB 2.10.5-lts behoben.
Technische Details
CVE-2026-77521 betrifft Instanzen vor 2.10.5-lts, bei denen Assistenten mit Werkzeugen, MCP-Werkzeugen, Skills oder Unteranwendungen das Backend SandboxShellBackend verwenden. Dort war ein Werkzeug zur Shell-Ausführung erreichbar, ohne wirksam ausgeschlossen zu werden. Zugleich fehlte die Aktion execute in der Unterbrechungslogik, die eigentlich eine Freigabe durch einen Menschen erzwingen sollte.
Das führt dazu, dass schädliche Eingaben aus Chats oder übernommenen Inhalten Befehle anstoßen können. Ist MAXKB_SANDBOX in einer Quellcode-Bereitstellung deaktiviert, laufen diese Kommandos direkt als Anwendungsbenutzer. Im offiziellen Root-Container kam hinzu, dass ein zeichenkettenbasierter gosu-Aufruf Shell-Metazeichen nicht ausreichend begrenzte.
Der Schweregrad von CVE-2026-77521 liegt bei CVSS 10.0. Der Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H bedeutet: Angriffe sind über das Netzwerk möglich, mit geringer Komplexität, ohne Berechtigungen und ohne Nutzerinteraktion; Vertraulichkeit, Integrität und Verfügbarkeit können jeweils schwer betroffen sein. Dieser Wert beschreibt die technische Schwere, nicht automatisch eine aktive Ausnutzung in realen Umgebungen.
CVE-2026-79916 ist ebenfalls vor 2.10.5-lts relevant, setzt aber ein vorhandenes Konto mit niedrigen Rechten voraus. Nach den NVD-Informationen können Workspace-Mitglieder Steuerzeichen in die Felder access_key_id und secret_access_key für AWS Bedrock einschleusen. Diese landen unsicher in /root/.aws/credentials. Anschließend lässt sich ein zusätzliches AWS-Profil mit credential_process einfügen, das bei einer späteren Modellvalidierung über botocore zur Ausführung eines fremden Befehls als root missbraucht werden kann.
Für CVE-2026-79916 nennt NVD einen CVSS-Basiswert von 9.1 und damit ebenfalls einen kritischen Schweregrad. Praktisch ist diese Lücke vor allem dort relevant, wo mehrere interne Nutzer oder Mandanten Zugriff auf Workspaces haben.
Wer ist betroffen?
Betroffen sind MaxKB-Installationen vor Version 2.10.5-lts. Besonders kritisch ist die Lage für Systeme, die aus dem Internet erreichbar sind oder Inhalte aus wenig vertrauenswürdigen Quellen verarbeiten, etwa Chat-Eingaben, importierte Dokumente oder angebundene Werkzeuge.
Für CVE-2026-77521 ist keine Anmeldung erforderlich. Das macht die Schwachstelle für öffentlich erreichbare Instanzen unmittelbar brisant. Bei internen Testsystemen sinkt das Risiko nur dann spürbar, wenn der Zugriff zuverlässig auf wenige vertrauenswürdige Netze begrenzt ist.
CVE-2026-79916 setzt eine Authentifizierung als Workspace-Mitglied voraus. In Unternehmen mit gemeinsam genutzten KI-Plattformen, Self-Service-Zugängen oder externen Projektbeteiligten kann das trotzdem sicherheitsrelevant sein, weil eine Rechteausweitung bis root im Raum steht.
Für die meisten Leser ohne MaxKB-Einsatz hat die Meldung keine direkte operative Bedeutung. Wer die Software jedoch produktiv oder in Pilotprojekten einsetzt, sollte sie als hoch priorisiert behandeln.
Empfohlene Maßnahmen
Erstens: Aktualisieren Sie MaxKB so schnell wie möglich auf Version 2.10.5-lts. Beide genannten Schwachstellen sind dort nach den NVD-Informationen behoben.
Zweitens: Begrenzen Sie bis zum Update den Netzwerkzugriff auf MaxKB strikt. Entfernen Sie öffentliche Erreichbarkeit, setzen Sie vorgeschaltete Zugriffskontrollen durch und erlauben Sie den Zugang nur aus administrativ freigegebenen Netzen oder über VPN.
Drittens: Prüfen Sie, ob Ihre Instanz Werkzeuge, MCP-Werkzeuge, Skills oder Unteranwendungen verwendet, die Shell-Ausführung ermöglichen. Deaktivieren Sie solche Funktionen vorübergehend, wenn sie nicht zwingend benötigt werden.
Viertens: Kontrollieren Sie Konfigurationen rund um Sandbox und Containerbetrieb. Wo MAXKB_SANDBOX deaktiviert ist, steigt das Risiko deutlich. Ebenso sollten Sie prüfen, ob Container unnötig mit hohen Rechten laufen.
Fünftens: Überprüfen Sie AWS-bezogene Konfigurationen in MaxKB. Wenn Workspace-Mitglieder Bedrock-Zugangsdaten pflegen können, sollten Sie bestehende Einträge kontrollieren, verdächtige Profile entfernen und Zugangsdaten rotieren. Achten Sie besonders auf unerwartete Profileinträge oder Hinweise auf credential_process in AWS-Konfigurationsdateien.
Sechstens: Sichten Sie Protokolle auf auffällige Modellvalidierungen, unerwartete Shell-Aufrufe, verdächtige importierte Inhalte und Änderungen an /root/.aws/credentials. Wenn MaxKB auf denselben Hosts weitere Dienste betreibt, ist eine weitergehende Kompromittierungsprüfung sinnvoll.
Einschätzung von CyberSecurity-News.de
Die Kombination aus einer nicht authentifizierten Remote-Code-Ausführung und einer zweiten Schwachstelle zur Root-Ausführung nach Anmeldung ist für Betreiber von KI-Plattformen ernst. CVE-2026-77521 sticht klar heraus, weil sie ohne Konto und ohne Nutzerinteraktion ausnutzbar ist. Wer MaxKB öffentlich betreibt, sollte das nicht als gewöhnliches Routine-Update behandeln.
Die Informationslage ist für die operative Einordnung brauchbar, aber knapp. NVD liefert die Kerndaten zu Auswirkungen, Voraussetzungen und Fix-Version 2.10.5-lts. Was fehlt, sind belastbare Angaben dazu, wie häufig bestimmte unsichere Betriebsarten in realen Installationen vorkommen und ob bereits Angriffe beobachtet wurden.
Für den DACH-Raum ist die Relevanz vor allem dort hoch, wo Unternehmen interne Wissensassistenten, Retrieval-Systeme oder KI-Chatbots mit Dateiuploads und externen Modellen testen oder produktiv einsetzen. Gerade diese Plattformen landen oft zunächst in Pilotumgebungen mit lockerer Härtung. Genau das macht solche Schwachstellen gefährlich.
Fazit
Wenn Sie MaxKB vor 2.10.5-lts einsetzen, besteht akuter Handlungsbedarf. Priorität hat das Update, direkt gefolgt von einer harten Zugriffsbeschränkung und einer Prüfung auf verdächtige Shell- oder AWS-Aktivitäten.
Wer MaxKB nicht nutzt, muss hier nichts unternehmen. Betreiber sollten die beiden CVEs aber als Anlass nehmen, KI-Plattformen nicht wie harmlose Fachanwendungen zu behandeln, sondern wie sicherheitskritische Systeme mit Angriffsfläche bis in Betriebssystem und Cloud-Zugangsdaten.
