MaxKB hat jedem Assistenten mit aktivierten Tools ein Shell-Tool angehängt und es nie mit Zugriffskontrolle versehen

MaxKB, eine Open-Source-Plattform für Unternehmensassistenten, die unter der GitHub-Organisation 1Panel-dev veröffentlicht wird, baute seine Chat-Agenten auf einem Framework auf, das stillschweigend ein Shell-Tool hinzufügt, sobald ein shell-fähiges Backend übergeben wird – und MaxKB hat das Tool nie entfernt oder jemanden gebeten, seine Verwendung zu genehmigen. Die Schwachstelle ist CVE-2026-77521, veröffentlicht als GitHub-Advisory GHSA-f36j-f34j-h3rx am 2. September 2026 und mit 10,0 von 10 unter CVSS 3.1 für den Fall eines öffentlichen oder eingebetteten Assistenten bewertet. Lasso Security, das sie gefunden und gemeldet hat, zeigte, dass eine Chat-Nachricht – oder Text, den der Assistent lediglich über Retrieval oder ein hochgeladenes Dokument aufnimmt – das Modell dazu bringen konnte, Befehle auszuführen: bei einer Bare-Metal-Bereitstellung direkt auf dem Host und beim offiziellen Container über einen Wrapper, der laut den Forschern mit einem Semikolon umgangen werden kann. Keine zitierte Quelle verzeichnet eine Ausnutzung der Schwachstelle in freier Wildbahn. Die eigene Schweregrad-Einstufung, die Vertrauensbewertung und die Quellenliste des Eintrags befinden sich in dem KI-Vorfallarchiv, zusammen mit den benachbarten MaxKB- und Agent-Tooling-Einträgen aus demselben Offenlegungsbatch.

MaxKB ist ein selbst gehostetes Produkt zum Aufbau retrieval-augmentierter Assistenten: Ein Betreiber erstellt einen Assistenten, hängt Fähigkeiten daran — Tools, Model-Context-Protocol-Server, Skills, Unteranwendungen —, verbindet eine Wissensdatenbank, die aus hochgeladenen Dokumenten oder gecrawlten Websites aufgebaut wurde, und stellt den Assistenten dann entweder über eine authentifizierte Konsole oder als öffentliches, einbettbares Chat-Widget bereit. Diese Vielseitigkeit ist die Angriffsfläche. Die Auslösebedingung des Advisories ist keine ungewöhnliche Konfiguration, sondern die normale: Jeder Assistent mit mindestens einer angehängten Fähigkeit leitet seinen Chat über den betroffenen Agent-Pfad, während ein Chat ohne angehängte Fähigkeiten dies nicht tut. Lassos Analyse beschreibt das Projekt als eines der in seiner Kategorie am weitesten verbreiteten und merkt an, dass MaxKB normalerweise als Multi-Tenant-Service bereitgestellt wird — was bedeutet, dass ein als Anwendungsbenutzer ausgeführter Befehl unterhalb des Mandantenmodells angesiedelt ist und nicht innerhalb des Anteils eines einzelnen Mandanten daran.

Das Shell-Tool kam mit dem Framework, nicht mit dem Produkt.

MaxKB erstellt diese Agenten mit der deepagents-Bibliothek von LangChain, die in der pyproject.toml des Projekts sowohl am verwundbaren Tag als auch am aktuellen Tag auf Version 0.6.11 festgelegt ist. In apps/application/flow/tools.py ruft das Projekt in Zeile 467 des Tags v2.10.3-lts create_deep_agent auf, wobei backend auf SandboxShellBackend gesetzt ist, einer MaxKB-Unterklasse, die Befehle auf dem Host ausführt. Laut dem Sicherheitshinweis injiziert deepagents automatisch eine Reihe von Tools, wenn ein Shell-Backend auf diese Weise übergeben wird: execute, ls, read_file, write_file, edit_file, glob und grep. Sie sind nicht Teil des Arguments tools=list, das nur die eigenen Tools des Betreibers, MCP-Tools und Skill-Tools enthält. Sie können weder aus der Schnittstelle noch durch Konfiguration entfernt werden.

MaxKB übergibt außerdem nicht excluded_tools, das Bibliotheksargument, das sie entfernen würde. Der Sicherheitshinweis betont sorgfältig, warum das auch als Abhilfe wichtig ist: excluded_tools „entfernt das Tool aus dem, was dem Modell mitgeteilt wird, nicht aus dem Executor“. Der Unterschied zwischen einem Tool, das dem Modell nicht bekannt ist, und einem Tool, das nicht ausgeführt werden kann, ist dieser Bug im Kleinen.

Ein Gate, das drei Tools auflistet und das vierte auslässt

Die Human-in-the-Loop-Kontrolle in demselben Aufruf ist eine Zeile, und sie zählt drei Operationen auf: interrupt_on={"write_file": False, "read_file": False, "edit_file": False}. Das Schreiben einer Datei, das Lesen einer Datei und das Bearbeiten einer Datei werden benannt. Die Befehlsausführung ist überhaupt kein Schlüssel im Dictionary. In der Lesart des Advisory bedeutet das, dass für execute keine Genehmigung eingeholt wird — die drei Dateisystemoperationen werden benannt und ausdrücklich so gesetzt, dass sie nicht unterbrechen, und das Shell-Tool wird überhaupt nicht benannt.

Zusammengenommen ergibt sich folgender Pfad: Nicht vertrauenswürdiger Text erreicht das Modell, das Modell ruft execute auf, und der Befehl wird ausgeführt. Die Sicherheitsmeldung nennt zwei Wege, auf denen nicht vertrauenswürdiger Text ankommt. Der direkte ist der Chat – ein öffentliches oder eingebettetes Widget oder die Konversation eines anderen Mandanten. Der indirekte sind Inhalte, die der Assistent aufnimmt: ein RAG-Dokument, eine hochgeladene Datei oder eine Webseite, die die Plattform in eine Wissensdatenbank crawlt. Lassos Beitrag macht den zweiten Weg konkret und stellt fest, dass „die Menge der Personen, die Text vor das Modell bringen können, größer ist als die Menge der Personen, die mit ihm chatten können“.

Bei einer Bare-Metal-Installation ist der Befehl einfach ein Befehl.

Was MaxKB zur Eindämmung tut, geschieht in apps/application/flow/backend/sandbox_shell.py, und in v2.10.3-lts beginnt es mit einem Standardwert. Zeile 9 lautet _enable_sandbox = bool(int(CONFIG.get("SANDBOX", 0))), und SANDBOX erscheint nicht in Config.defaults in apps/maxkb/conf.py. Ohne eine explizite MAXKB_SANDBOX-Einstellung ist der Wert null, der Wrapper-Zweig in Zeile 65 wird übersprungen, und execute erreicht subprocess.run mit shell=True direkt auf dem Host, als der Benutzer, der den Dienst ausführt — root, in der Formulierung des Advisories, wenn der Dienst als root läuft.

Das ist die Konfiguration, die die Forscher für ihren Host-Proof-of-Concept verwendeten. Sie führten MaxKBs echten Code aus der Quelle mit nicht gesetztem MAXKB_SANDBOX aus, erstellten einen Assistenten mit einem angehängten Tool und baten ihn in einer einzigen Chat-Nachricht, Befehle zur Systeminformation auszuführen. Das execute-Tool wurde ausgelöst und schrieb eine Datei, deren Inhalt die uname-, id- und sw_vers-Ausgabe des Hosts selbst war – eine Ausgabe, von der der Sicherheitshinweis bestätigt, dass sie in keinem Container vorhanden war. Lasso hält außerdem die Grenze dessen fest, was es aufhielt: Eine offensichtlich benannte Proof-Datei wurde vom Modell abgelehnt, eine harmlose betriebliche Formulierung jedoch nicht. Die Modellausrichtung ist, in ihren Worten, „ein teilweiser Bremsklotz, keine Kontrolle“.

Auf dem offiziellen Image lief die Sandbox und leckte trotzdem.

Der offizielle Container setzt MAXKB_SANDBOX=1 im Basisimage, in installer/Dockerfile-base Zeile 48, sodass der Wrapper dort aktiv ist – und der Wrapper ist die zweite Schwachstelle. Er erzeugte eine einzige Zeichenkette: env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so, gefolgt von gosu sandbox und dann dem vom Modell gelieferten Befehl, übergeben an eine als root laufende Shell. Da der Befehl als Text interpoliert wurde, befand sich nur sein erstes Token unter gosu. Jedes Semikolon, jede Pipe, jede Umleitung oder Befehlssubstitution in der Ausgabe des Modells wurde von der äußeren Root-Shell ausgewertet, bevor die Sandbox ihn überhaupt zu sehen bekam.

Lassos Write-up liefert die funktionierende Form dafür: eine Payload aus env -i LD_PRELOAD=... PATH="$PATH" gosu sandbox ls; whoami; id, bei der ls eingeschränkt ist, whoami nicht, und alles danach frei läuft. Beim Testen schrieben die Forscher mit einer Umleitung eine Datei, die root gehört, während der innere Befehl in der Sandbox blockiert war. Erschwerend kommt hinzu, dass weder installer/Dockerfile noch installer/Dockerfile-base eine USER-Direktive enthalten, sodass das Anwendungsimage als UID 0 läuft — der Advisory berichtet von einer Bestätigung von root zur Laufzeit. Der Container führte Befehle daher unabhängig davon aus, und die Sandbox entschied nur, welche davon kosmetisch dem Benutzer mit geringen Privilegien zugeordnet wurden.

Der vollständige von Lasso beschriebene Angriffsablauf benötigt keinerlei Zugriff auf das Ziel. Der Angreifer platziert Befehle auf einer Webseite, wartet darauf, dass der Agent eines Opfers sie in eine Wissensdatenbank crawlt, und das Opfer stellt dann eine gewöhnliche Frage. Die Antwort kommt korrekt und legitim zurück; das injizierte curl hat bereits den Server des Angreifers kontaktiert. Der Sicherheitshinweis merkt an, dass die Forscher nur ihre eigenen Bereitstellungen getestet haben, nicht irgendeine MaxKB-Instanz von Drittanbietern oder eine gehostete MaxKB-Instanz.

Was die Quellen belegen und was schlicht nicht gemessen wird

Der Mechanismus, die beiden Bereitstellungsmodi, die Anerkennung und die feste Version stimmen über vier Dokumente hinweg überein: die GitHub-Advisory, den am 21. September 2026 veröffentlichten NVD-Eintrag, Lassos eigenen technischen Bericht vom 10. September 2026 und den Bericht von GBHackers vom 22. September 2026, der die einzige unabhängige Berichterstattung ist, die für diese CVE gefunden wurde. Keine Quelle bestreitet irgendeinen Teil des Befunds, und das Archiv verzeichnet den Eintrag als unbestritten mit seiner höchsten Vertrauensstufe.

Was die Quellen nicht enthalten, ist irgendein Maß für Exposition. Es gibt keine Zahl der MaxKB-Bereitstellungen, keine Zahl internetzugewandter oder eingebetteter Assistenten, kein Scan-Ergebnis, keine Telemetrie und kein benanntes Opfer. Nichts in den Unterlagen zeigt, dass die Schwachstelle gegen jemanden eingesetzt wurde, und CISAs eigene Ausnutzungsbewertung stimmt zu: Der am 22. September 2026 an den NVD-Eintrag angehängte SSVC-Block bewertet die Ausnutzung als „poc“, die Automatisierbarkeit als „yes“ und die technische Auswirkung als „total“. FIRSTs EPSS-Modell bezifferte die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen am 27. Oktober 2026 auf 1,05 Prozent, das 64. Perzentil, und die CVE erscheint nicht im CISA-Katalog bekannter ausgenutzter Schwachstellen (Known Exploited Vulnerabilities) mit Stand vom 27. Oktober 2026. Die Bewertung des Archivs selbst spiegelt dieselbe Evidenz wider: Schweregrad hoch, tatsächlicher Schaden falsch.

Für die 10,0 sollte der Geltungsbereich ausdrücklich genannt werden, denn sie ist die Zahl, die am ehesten aus dem Zusammenhang gerissen zitiert wird. Sie ist die Bewertung für den Fall des öffentlichen oder eingebetteten Assistenten, bei dem der CVSS-Vektor AV:N/AC:L/PR:N/UI:N/S:C lautet – über das Netzwerk erreichbar, keine Berechtigungen, keine Benutzerinteraktion, mit einem Scope-Wechsel, weil ein Befehl innerhalb des Assistenten in das Host-Betriebssystem übergreift. Die Bewertung stammt vom CNA, und der CNA ist hier das Advisory-Programm von GitHub, worauf auch die Quellenkennung des CVE-Eintrags verweist. NVD führt denselben Vektor als sekundäre Metrik und listet den Eintrag mit Stand vom 28. Oktober 2026 im Status „Deferred“, was bedeutet, dass NVD die Analyse des Zuweisers und nicht seine eigene veröffentlicht hat.

Der Patch wurde einen Monat vor der Sicherheitsmitteilung veröffentlicht.

Die Chronologie verläuft von der Veröffentlichung rückwärts, und sie ist der am wenigsten intuitive Teil der Aufzeichnung. Lasso meldete den Fehler am 8. Juli 2026 privat über GitHubs Advisory-Kanal. MaxKB antwortete am nächsten Tag, grenzte den Bericht auf das offizielle Image ein und bat um einen Container-Proof-of-Concept; die Forscher lieferten diesen und die Sandbox-Umgehung am 10. Juli. Ein Fix-Commit, 594f50f2, landete am 9. Juli – einen Tag nach der Meldung – und schrieb sandbox_shell.py so um, dass die Befehlszeichenkette des Modells zuerst geparst und das gosu-Präfix auf jeden einfachen Befehl angewendet wird statt nur auf den ersten, wobei jede Argumentliste erneut in Anführungszeichen gesetzt wird, damit eine Substitution nicht in die übergeordnete Shell entweichen kann. Lassos Bericht beschreibt die Änderung dahingehend, dass das gosu-Präfix „auf jeden einfachen Befehl, nicht nur auf den ersten“ angewendet wird.

Das Release, in dem es enthalten war, v2.10.5-lts, wurde am 6. August 2026 veröffentlicht. Die GitHub-Advisory ging am 2. September online, NVD veröffentlichte die CVE am 21. September, CISA-SSVC-Block wurde hinzugefügt und GBHackers berichtete am 22. September, und Lassos eigener Artikel erschien am 10. September — mitten in dieser Abfolge, nicht an deren Anfang. Ein Betreiber, der Release-Tags statt Advisory-Feeds verfolgte, hatte den Patch rund vier Wochen vor der Warnung.

Die Versionsgrenze verdient mehr Aufmerksamkeit, als das Advisory ihr beimisst, denn die beiden Primärquellen widersprechen sich, und das Repository entscheidet die Frage. Das Formularfeld des Advisory verzeichnet die betroffenen Versionen als „<= 2.10.3-lts“, mit dem Hinweis, dass dies auf 2.10.3-lts verifiziert wurde und dass der anfällige Pfad „wahrscheinlich“ alle Versionen betrifft, die Agents auf diese Weise bauen. Lassos eigener Bericht gibt den betroffenen Bereich als „<= 2.10.4-lts“ an. Die Tags bestätigen den größeren Bereich: v2.10.4-lts, veröffentlicht am 16. Juli 2026, enthält dieselbe 75-zeilige sandbox_shell.py wie v2.10.3-lts, und die neu geschriebene 311-zeilige Datei erscheint erstmals in v2.10.5-lts. Ein Betreiber auf 2.10.4-lts, der nur den Bereich im Advisory gelesen hätte, wäre zu dem Schluss gekommen, außerhalb davon zu liegen. Das war nicht der Fall.

Was die Korrektur nicht bewirkt hat

Was 2.10.5-lts behebt, ist der Wrapper: Er baut unter root keine einzelne Shell-Zeichenkette mehr zusammen. Was er nicht tut, ist irgendetwas an dem Tool. Die direkte Einsicht in das Repository beim Tag v2.10.8-lts, veröffentlicht am 22. Oktober 2026, zeigt, dass der Agent weiterhin mit backend=SandboxShellBackend konstruiert wird und interrupt_on weiterhin genau drei Schlüssel enthält — write_file, read_file und edit_file — ohne execute. Die ersten beiden Behebungsvorschläge des Advisories, standardmäßig auf einem Nicht-Ausführungs-Backend aufzubauen und "execute": True zur Genehmigungszuordnung hinzuzufügen, sind in dieser Version nicht vorhanden.

Die Fail-Closed-Empfehlung kam später, in v2.10.7-lts, und sie ist für den Bereitstellungsmodus relevant, der am schlechtesten dran war. Veröffentlicht am 15. Oktober 2026, ändert sie die Zeile in sandbox_shell.py von CONFIG.get("SANDBOX", 0) zu CONFIG.get("SANDBOX", 1). Eine Quell- oder Bare-Metal-Installation, die die Variable nie gesetzt hat, hat den Wrapper nun standardmäßig eingeschaltet statt ausgeschaltet, was im engeren Sinne der Empfehlung „fail closed on non-container deploys“ entspricht. Die Sicherheitsmitteilung verlangte unter derselben Überschrift mehr – nämlich dass der ausführungsfähige Ablauf den Start verweigert, wenn die Sandbox-Laufzeit nicht verfügbar ist – und verlangte separat, dass der Wrapper niemals eine Befehlszeichenkette für eine Root-Shell erstellt. Auf der Containerseite, eine Tatsache statt einer Empfehlung: Weder installer/Dockerfile noch installer/Dockerfile-base enthält zum Tag v2.10.8-lts eine USER-Direktive, sodass das Anwendungsimage weiterhin als Root startet.

Zusammengenommen stellt sich der Stand der Aktenlage zum 28. Oktober 2026 so dar. Die zweite Hälfte der Sicherheitslücke – die Sandbox, aus der ein Semikolon herausspazierte – ist geschlossen, und die Fail-open-Voreinstellung bei Host-Deployments ist geschlossen. Die erste Hälfte – ein Execute-Tool, das mit einem Backend-Objekt ankommt und kein Schlüssel in der Genehmigungs-Map ist – ist nach wie vor die Art und Weise, wie MaxKB einen tool-fähigen Assistenten aufbaut. Die eigene Behebungsempfehlung der Forscher war die eng gefasste: auf 2.10.5-lts oder höher aktualisieren und die Docker-Version mit aktivierter Sandbox betreiben. GBHackers gab dieselbe Anweisung weiter, plus eine breitere Liste für Administratoren – shell-fähige Agent-Backends deaktivieren, sofern Codeausführung nicht ausdrücklich erforderlich ist, vor jeder Execute-Aktion eine menschliche Genehmigung verlangen, Container als Nicht-Root ausführen und gecrawlte Seiten, RAG-Dokumente und Uploads als nicht vertrauenswürdige Eingaben behandeln.

Der andere MaxKB-Datensatz aus derselben September-Charge

Der zweite MaxKB-Eintrag aus diesem Stapel im Archiv ist ein anderer Fehler mit einem schlimmeren Ausgang. CVE-2026-77516, ebenfalls am 21. September 2026 bei NVD veröffentlicht, ist eine Umgehung der Berechtigungen statt einer Befehlsinjektion: Von Version 2.0.0 bis 2.9.2 konnte ein Workspace-Mitglied mit der niedrigsten Rolle, dem der Zugriff auf ein Tool über WorkspaceUserResourcePermission ausdrücklich verweigert wurde, dennoch die Kennung dieses Tools über tool_ids, skill_tool_ids oder mcp_tool_ids binden und es über den Dispatch-Pfad des Agenten oder Workflows ausführen. Der Dispatch-Pfad wendet die toolbezogene Berechtigung, die die dedizierten Tool-Routen durchsetzen, nicht erneut an, und die Tool-Ausführung entschlüsselt serverseitige init_params, sodass der Aufrufer Anmeldeinformationen erhält, die von dem Tool mitgeführt werden, für das ihm der Zugriff verweigert wurde. Sein Score beträgt 5,4, und die NVD-Beschreibung endet mit einem Satz, den CVE-2026-77521 nicht tragen muss: „Zum Zeitpunkt dieser Prüfung ist keine korrigierte Version verfügbar.“

{{1}}Der Kontrast{{/1}} ist der nützliche Teil für alle, die das Paar triagieren. {{2}}Bei der Schwachstelle mit der Bewertung 10,0 wurde innerhalb eines Tages ein Fix committet, der einen Monat vor ihrer Veröffentlichung veröffentlicht wurde.{{/2}} {{3}}Die Schwachstelle mit der Bewertung 5,4 hatte zum Zeitpunkt ihrer CVE keine veröffentlichte korrigierte Version.{{/3}}

Was tatsächlich noch offen ist, ist {{1}}kleiner, als die Bewertung vermuten lässt{{/1}} und {{2}}größer, als eine Patch-Notiz andeutet{{/2}}. Der Befund ist {{3}}nicht umstritten{{/3}}, und der Mechanismus wurde von dem Team, das ihn gefunden hat, in beiden Bereitstellungsmodi durchgängig verifiziert. Die Exposition ist {{4}}vollständig ungemessen{{/4}} — niemand hat veröffentlicht, wie viele MaxKB-Assistenten ein Tool enthalten, wie viele davon für eine nicht vertrauenswürdige Partei erreichbar sind oder wie viele auf einem Host ohne die Sandbox laufen —, sodass die reale Auswirkung der Schwachstelle eine Funktion der Bereitstellungsgewohnheiten ist, die keine zitierte Quelle erfasst. Und der Teil des Designs, der die Bewertung auf das Maximum trieb, ist in der aktuellen Version {{5}}immer noch vorhanden{{/5}}: eine Fähigkeit, die Befehle ausführt, standardmäßig angehängt ist und in der Übersicht fehlt, die zuerst einen Menschen fragt.