MaxKB: Der Dispatch-Pfad des Agenten ermöglicht es einem Nutzer, dem der Zugriff auf ein Tool verweigert wurde, dieses dennoch aufzurufen und seine Zugangsdaten zu lesen.

MaxKB, der von 1Panel-dev gepflegte Open-Source-KI-Assistent für Unternehmen, bietet eine benutzer- und toolbezogene Berechtigungsliste, sodass ein Administrator einem Workspace-Mitglied ein Tool gewähren und ein anderes verweigern kann. Laut der am 2. September 2026 veröffentlichten Sicherheitsmeldung galt diese Verweigerung auf den eigenen Routen des Tools, jedoch nicht auf dem Pfad, den ein Agent oder Workflow nutzt, um dasselbe Tool aufzurufen. Ein Workspace-Mitglied mit der niedrigsten Rolle konnte beim Erstellen eines Workflows die Kennung eines verweigerten Tools angeben, den Workflow ausführen und erhielt nicht nur die Ausgabe des Tools, sondern auch die Anmeldedaten, die MaxKB serverseitig entschlüsselt, um es auszuführen. Die Versionen 2.0.0 bis 2.9.2 sind betroffen, und die Sicherheitsmeldung nannte keine gepatchte Version. Dieser Datensatz – die Umgehung der Autorisierung bei der Tool-Weiterleitung von MaxKB – ist ein Eintrag im OrcaRouter AI Incident Archive, der den vollständigen Datensatzbestand und die benachbarten Einträge dieses Vorfalls enthält.

Was diesen Fall einer genauen Lektüre wert macht, ist nicht die Bewertung. Es ist die Tatsache, dass das Produkt bereits die richtige Prüfung hatte, sie auf die offensichtliche Tür anwandte und eine zweite Tür zu derselben Funktion unüberwacht ließ. Der Sicherheitshinweis GHSA-383v-fx78-pphm wurde von dem Forscher verfasst, der ihn entdeckte, und am 2. September 2026 um 07:43 UTC über GitHubs Advisory-System veröffentlicht, mit Nennung von Matteo Panzeri (@matte1782). Der CVE-Eintrag CVE-2026-77516 folgte am 21. September 2026.

Was der Hinweis feststellt

MaxKBs Modell pro Tool ist WorkspaceUserResourcePermission, im Advisory als Default-Deny-Allowlist beschrieben, die zur Anfragezeit aufgelöst wird. Die dedizierten Tool-Routen erzwingen sie. Das Advisory führt die Durchsetzung in apps/tools/views/tool.py auf, wo Operate.put, Operate.get, Debug.post, Export.get und Delete jeweils eine View-Berechtigungsprüfung gegen die Tool-Berechtigung des Workspace des Aufrufers enthalten. Debug.post ist die Route, die dem bloßen Ausführen eines Tools am nächsten kommt, und sie ist zugriffsgeschützt.

Der Dispatch-Pfad für Agenten und Workflows wendet diese Prüfung nicht erneut an. Der Sicherheitshinweis zeigt drei separate Stellen auf, an denen sie fehlt. In apps/application/serializers/application.py bindet der Application-Serializer tool_ids, skill_tool_ids und mcp_tool_ids direkt aus der Anfrageeingabe, ohne Autorisierung pro Tool – und der Sicherheitshinweis weist darauf hin, dass die Asymmetrie in derselben Datei sichtbar ist, weil knowledge_id_list einige Zeilen weiter unten gegen die dem Benutzer zugänglichen Wissensdatenbanken validiert wird, während Tools nicht geprüft werden. In apps/common/utils/shared_resource_auth.py gibt filter_authorized_ids jedes Tool im eigenen Workspace des Aufrufers bedingungslos durch; das Cross-Workspace-Gate, auf das es sich stützt, ist ein Hook, der nur in der Enterprise-Edition vorhanden ist und in der Community-Edition fehlt, und es konsultiert nie WorkspaceUserResourcePermission. Und an der Senke führt apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py den gespeicherten Code des Tools mit seinen init_params aus, die von rsa_long_decrypt unter der Identität der Anwendung entschlüsselt werden, ohne Prüfung der Berechtigung pro Tool.

Die Warnmeldung bezeichnet das Ergebnis als eine Confused-Deputy-Ausführung: Der Workflow-Dispatch führt ein Tool und dessen gespeicherte Secrets aus, die demselben Aufrufer auf den eigenen Routen des Tools verweigert werden. Die Offenlegung von Anmeldedaten ist der Teil, der die gewöhnliche unbefugte Tool-Nutzung übersteigt. Die init_params eines Tools werden im Ruhezustand mit RSA verschlüsselt und erst zum Ausführungszeitpunkt serverseitig entschlüsselt, sodass ein Aufrufer, der diese Ausführung auslöst, Werte erhält, die er nie besessen hat und die er nicht hätte liefern können.

Die Demonstration – in den eigenen Zahlen des Forschers

Der Sicherheitshinweis berichtet über eine dynamische Bestätigung auf v2.9.2, ausgeführt aus dem offiziellen All-in-One-Image, 1panel/maxkb:v2.9.2. Das Setup bestand aus einem Workspace, einem Administrator und einem zweiten Mitglied mit der Rolle USER. Der Administrator erstellte Tool A und Tool B, legte ein frisches zufälliges Geheimnis in Tool Bs init_params, und schrieb den Body von Tool B so, dass er dieses Geheimnis bei Ausführung zurückgibt. Dem Mitglied wurde dann eine tool-spezifische Berechtigung nur für Tool A erteilt, und der Sicherheitshinweis besagt, dass der Zero-Grant-Zustand für Tool B nach dem Lauf in der Datenbank erneut geprüft wurde.

Die verweigerte Hälfte des Tests ergab, was das Produkt verspricht. In der Rolle des Mitglieds antwortete die Debug-Route für Tool B mit 403, die Update-Route mit 403, die Export-Route mit 403, und das freigegebene Tool A gab als Plausibilitätsprüfung 200 zurück. Die Umgehungshälfte band Tool B dann über einen Tool-Bibliotheksknoten in eine Workflow-Anwendung ein – die Bindung wurde mit HTTP 200 und ohne Prüfung pro Tool akzeptiert –, und das Ausführen des Workflows gab HTTP 200 mit einem Body zurück, der den Namen des Tools, das Sentinel-Geheimnis und die Schlüsselliste ["api_key"] enthielt.

Der Sicherheitshinweis besagt, dass das Secret auf drei Ebenen aufgetaucht ist: in der Workflow-API-Antwort, in einem Tool-Ausführungsdatensatz mit Status SUCCESS und in der Datenbankzeile, in der init_params von Tool B als 344-Byte-RSA-Chiffretext steht – womit der Forscher argumentiert, dass der Wert serverseitig unter der Anwendungsidentität entschlüsselt und nicht vom Aufrufer geliefert wurde. Dasselbe Mitglied, dem auf der Ausführungsroute des Tools der Zugriff verweigert wurde, erlangte das entschlüsselte Secret des Tools, indem es dieses in einen Workflow einband.

Eine Note veröffentlicht, eine höhere gefordert

Die CVE-2026-77516 zugeordnete Bewertung ist CVSS 3.1 5.4, Medium, mit dem Vektor AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. Der NVD-Eintrag zeigt, dass diese Bewertung aus GitHubs Advisory-Feed und nicht aus NVDs eigener Analyse stammt, und der Eintrag trägt den Status Deferred, was bedeutet, dass NVD ihn nicht angereichert hat. Die eigene Klassifizierung des Archivs folgt dieser veröffentlichten Bewertung: mittlere Schwere, kein dokumentierter realer Schaden.

Der eigene Auswirkungsabschnitt des Advisories spricht für mehr. Er nennt einen Schweregrad von 7.1, High, auf einem Vektor, der die Auswirkung auf die Vertraulichkeit auf hoch hebt, und sagt, der Wert steige auf 8.1, wenn das eingesetzte Tool privilegierte Schreibvorgänge unter der Anwendungsidentität durchführt. Das ist ein Streit darüber, wie die Offenlegung von Zugangsdaten zu bewerten ist, nicht darüber, ob die Umgehung existiert – dasselbe Dokument zeigt sowohl die Schwachstelle auf als auch argumentiert, dass sie zu niedrig gewichtet wird. Nichts in der öffentlichen Aktenlage klärt, welcher Wert richtig ist, und die Medium-Einstufung des Archivs folgt dem veröffentlichten CVE-Score statt der Argumentation des Advisories.

Zwei weitere Bewertungen sind aktenkundig. Die SSVC-Entscheidungspunkte von CISA, die am 28. September 2026 zum NVD-Eintrag hinzugefügt wurden, erfassen Ausnutzung als „poc“, Automatisierbarkeit als „no“ und technische Auswirkung als „partial“ — der Wert „poc“ spiegelt wider, dass ein Proof of Concept existiert, was er tut, und zwar im Advisory selbst; es ist keine Feststellung einer Ausnutzung in freier Wildbahn. Das EPSS-Modell von FIRST bezifferte die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen in der Schätzung vom 27. Oktober 2026 auf 0,242 %, am 15,2. Perzentil.

Ein Fix, der vor dem Advisory liegt, und keiner innerhalb des betroffenen Bereichs.

Die Versionstabelle des Advisorys gibt an, dass die Versionen 2.0.0 bis 2.9.2 betroffen sind, gepatchte Versionen: keine, und im Text heißt es, dass zum Zeitpunkt der Überprüfung keine feste Version verfügbar ist, wobei ergänzt wird, dass ein Fix in einem getaggten Release einem CVE als Anknüpfungspunkt dienen würde. Das Repository des Herstellers erzählt eine etwas andere Geschichte, und der Unterschied ist für alle wichtig, die entscheiden, was sie ausführen.

Im MaxKB-Repository fehlen die Funktionen, die den Dispatch-Pfad abschließen — validate_bound_tool_permissions und get_authorized_tool_ids in apps/application/serializers/application.py — im Tag v2.9.2 sowie in v2.10.2-lts, v2.10.3-lts und v2.10.4-lts und sind ab v2.10.5-lts vorhanden. Dieses Release wurde am 6. August 2026 veröffentlicht, vier Wochen vor dem Advisory. Derselbe Tag ergänzt in base_tool_lib_node.py eine Tool-Prüfung pro Benutzer, die auf WorkspaceUserResourcePermission zurückgreift, und ergänzt in shared_resource_auth.py einen benutzerbezogenen Filter — das heißt, er setzt in Grundzügen die drei Behebungsschritte um, die das Advisory später empfiehlt.

Niemand hat diesen Zusammenhang öffentlich genannt. Die Versionshinweise zu v2.10.5-lts erwähnen keine Korrektur der Tool-Berechtigungen; sie führen vier unabhängige Sicherheitspunkte und eine Reihe von Funktions- und Fehlerarbeiten auf. Der Hinweis nennt 2.10.5 nicht, und sein betroffener Bereich endet einfach bei 2.9.2, der letzten Version der 2.9-Reihe. Die Versionshistorie zeigt nach dem Hinweis keinen 2.9.x-Patch, sodass eine Bereitstellung auf 2.9.2 innerhalb ihrer eigenen Reihe keinen korrigierten Build hat. Die aktuelle Version ist v2.10.8-lts, veröffentlicht am 22. Oktober 2026, deren Hinweise X-Pack-Korrekturen an der Autorisierung gemeinsam genutzter Tools beschreiben statt etwas im Dispatch-Pfad der Community-Edition.

Was ist nicht etabliert?

Drei Punkte sollten getrennt von der Demonstration betrachtet werden. Erstens gibt es keinen öffentlichen Bericht darüber, dass die Umgehung gegen jemanden eingesetzt wurde. Der Sachstand ist eine gefundene Schwachstelle, nicht ein untersuchter Eindringfall; es gibt kein Opfer, keinen zugeschriebenen Akteur und keinen Schaden, und der Proof of Concept des Advisory wurde vom Forscher in einer kontrollierten Arbeitsumgebung ausgeführt. Zweitens scheint keine Nachrichtenorganisation, keine Regulierungsbehörde und kein zweites Forschungsteam die Schwachstelle analysiert zu haben: Die vorhandene Berichterstattung beschränkt sich auf Schwachstellendatenbanken und Aggregatoren — darunter VulDB, die Datenbank von Rapid7, Armis, SOCRadar und openCVE —, die die CVE auflisten und die Beschreibung des Advisory übernehmen und von denen keine eine unabhängige Bewertung des Codes bietet. Drittens gibt es keine Zahl dafür, wie viele MaxKB-Installationen im betroffenen Bereich liegen, und weder der Anbieter noch der Forscher hat eine veröffentlicht.

Die gefährdete Gruppe ist klein, aber nicht trivial zu beziffern: selbst gehostete MaxKB-Installationen der Community-Edition in den Versionen 2.0.0 bis 2.9.2 mit mehr als einem Workspace-Mitglied, bei denen ein Administrator über toolbezogene Berechtigungen ein Tool vorenthalten hat, das Anmeldedaten enthält. Die Schwachstelle ist keine Remote-Code-Execution und erfordert ein gültiges Konto mit geringen Berechtigungen, weshalb die Auswirkung auf die Vertraulichkeit und nicht der Angriffspfad die Bewertung bestimmt. Was ein Angreifer erlangt, ist dadurch begrenzt, was die vorenthaltenen Tools enthalten – API-Schlüssel, Token und alles, was diese freischalten –, weshalb die Autoren des Advisorys auch argumentieren, dass die Auswirkung größer ist, als eine niedrige Vertraulichkeitsbewertung nahelegt.

Was ein Operator tun kann

Die Behebung aus dem Advisory richtet sich an die Maintainer statt an Betreiber, und ihre drei Schritte entsprechen dem Code, der in v2.10.5-lts erschienen ist: wende die per-Tool-Berechtigung an, bevor ein Tool in den Tool-Library- und Tool-Node-Implementierungen ausgeführt wird, validiere alle gebundenen tool_ids, skill_tool_ids und mcp_tool_ids zum Bindungszeitpunkt so, wie knowledge_id_list bereits validiert wird, und veranlasse, dass filter_authorized_ids die per-Tool-Berechtigung heranzieht statt allein die Workspace-Mitgliedschaft.

Für ein Team, das einen betroffenen Build ausführt, sind die praktischen Schritte, die sich aus der Beschreibung des Advisories selbst ergeben, folgende.

• Behandle jedes Secret, das in den init_params eines Tools auf einer betroffenen Bereitstellung gespeichert ist, als von jedem Workspace-Mitglied erreichbar, einschließlich der niedrigsten Rolle, und rotiere diese Anmeldedaten, statt anzunehmen, dass die toolbezogene Verweigerung sie geschützt hat.

• Mitgliedschaft im Workspace prüfen. Der Bypass erfordert ein authentifiziertes Konto im Workspace, daher verringert das Entfernen inaktiver oder nicht vertrauenswürdiger Mitglieder die Angriffsfläche, selbst dort, wo der Code nicht gepatcht werden kann.

• Prüfen Sie, welche Workflows und Agenten Tools binden, die Anmeldeinformationen mitführen, denn diese Bindung ist der Schritt, der laut dem Sicherheitshinweis ohne eine Prüfung je Tool akzeptiert wird.

• Wenn Sie ein Upgrade durchführen, beachten Sie, dass die Prüfung pro Benutzer ab v2.10.5-lts im Repository enthalten ist und dass im Advisory keine Release als Fix benannt ist – wer sich auf das Upgrade verlässt, verlässt sich auf den getaggten Quellcode und nicht auf eine Patch-Erklärung des Anbieters.

Nichts davon macht den Fehler dramatisch. Es macht ihn auf eine spezifische und lehrreiche Weise gewöhnlich: Das Autorisierungsmodell wurde korrekt entworfen, korrekt dokumentiert und auf den Routen durchgesetzt, an denen jemand daran dachte, sie abzusichern. Der Dispatch-Pfad wurde von Leuten geschrieben, die darüber nachdachten, was ein Workflow tun können sollte, nicht darüber, wer fragte – und in einer Agentenplattform ist das der Pfad, den die meisten Anfragen tatsächlich nehmen.

Die Lehre aus diesem Fall ist struktureller und nicht numerischer Art. Eine Berechtigung pro Ressource ist nur so stark wie ihr am wenigsten geschützter Einstiegspunkt, und eine Agentenplattform häuft schnell Einstiegspunkte an: eine Debug-Route, eine Export-Route, einen Workflow-Knoten, einen Chat-Trigger. MaxKB hatte die Berechtigungsliste und die Prüfung; was ihm für die Produktlinie 2.0 bis 2.9 fehlte, war die Gewohnheit, an jeder Tür dieselbe Frage zu stellen.