MaxKB: het agent-dispatchpad stelt een gebruiker aan wie een tool is geweigerd in staat die tool toch aan te roepen en de inloggegevens ervan te lezen.

MaxKB, de opensource AI-assistent voor bedrijven die door 1Panel-dev wordt onderhouden, biedt een machtigingslijst per gebruiker en per tool, zodat een beheerder aan een lid van een werkruimte de ene tool kan toestaan en een andere kan weigeren. Volgens het op 2 september 2026 gepubliceerde beveiligingsadvies gold die weigering wel op de eigen routes van de tool, maar niet op het pad dat een agent of workflow gebruikt om dezelfde tool aan te roepen. Een lid van een werkruimte met de laagste rol kon bij het bouwen van een workflow de identificatie van een geweigerde tool opgeven, de workflow uitvoeren en niet alleen de uitvoer van de tool ontvangen, maar ook de inloggegevens die MaxKB server-side ontsleutelt om die tool te kunnen uitvoeren. Versies 2.0.0 tot en met 2.9.2 zijn getroffen, en in het advies werd geen gepatchte versie genoemd. Dit record — de autorisatieomzeiling bij tool-dispatch in MaxKB — is één vermelding in het OrcaRouter AI Incident Archive, dat de volledige recordset en de aangrenzende vermeldingen van dit incident bevat.

Wat de zaak de moeite waard maakt om nauwgezet te lezen, is niet de score. Het is dat het product al de juiste controle had, deze op de voor de hand liggende deur toepaste en een tweede deur naar dezelfde functionaliteit onbewaakt liet. De advisory, GHSA-383v-fx78-pphm, is geschreven door de onderzoeker die het probleem vond en gepubliceerd via het advisorysysteem van GitHub op 2 september 2026 om 07:43 UTC, met vermelding van Matteo Panzeri (@matte1782). Het CVE-record, CVE-2026-77516, volgde op 21 september 2026.

Wat het advies vaststelt

Het per-toolmodel van MaxKB is WorkspaceUserResourcePermission, in het advies beschreven als een allow-list met standaardweigering die op het moment van het verzoek wordt bepaald. De specifieke toolroutes handhaven dit. Het advies vermeldt de handhaving in apps/tools/views/tool.py, waar Operate.put, Operate.get, Debug.post, Export.get en Delete elk een controle op de weergavemachtiging uitvoeren aan de hand van de workspace-toolmachtiging van de aanvrager. Debug.post is de route die het dichtst bij het simpelweg uitvoeren van een tool komt, en deze is afgeschermd.

Het agent- en workflow-dispatchpad past die controle niet opnieuw toe. De advisory traceert drie afzonderlijke plaatsen waar deze ontbreekt. In apps/application/serializers/application.py koppelt de applicatieserializer tool_ids, skill_tool_ids en mcp_tool_ids rechtstreeks vanuit de request-invoer zonder autorisatie per tool — en de advisory merkt op dat de asymmetrie zichtbaar is in hetzelfde bestand, omdat knowledge_id_list een paar regels verder wordt gevalideerd tegen de knowledge bases waartoe de gebruiker toegang heeft, terwijl dat voor tools niet gebeurt. In apps/common/utils/shared_resource_auth.py geeft filter_authorized_ids elke tool in de eigen workspace van de aanroeper onvoorwaardelijk door; de cross-workspace-poort waarop het vertrouwt is een hook die alleen in de enterpriseversie bestaat en die ontbreekt in de community-editie, en er wordt nooit WorkspaceUserResourcePermission geraadpleegd. En bij de sink voert apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py de opgeslagen code van de tool uit, waarbij de init_params worden ontsleuteld door rsa_long_decrypt onder de identiteit van de applicatie, zonder controle van de toekenning per tool.

Het beveiligingsadvies noemt het resultaat een confused-deputy-uitvoering: de workflow-dispatch voert een tool uit, en de opgeslagen secrets daarvan, waarvoor dezelfde aanroeper op de eigen routes van de tool wordt geweigerd. De blootstelling van inloggegevens is het onderdeel dat verder gaat dan gewoon ongeautoriseerd gebruik van een tool. De init_params van een tool worden in rust met RSA versleuteld en pas op het moment van uitvoering aan de serverzijde ontsleuteld, zodat een aanroeper die die uitvoering activeert waarden ontvangt die hij nooit heeft gehad en niet had kunnen aanleveren.

De demonstratie, in de eigen cijfers van de onderzoeker

Het advies meldt dynamische bevestiging op v2.9.2, uitgevoerd vanaf de officiële all-in-one-image, 1panel/maxkb:v2.9.2. De opstelling bestond uit één workspace, een beheerder en een tweede lid met de rol USER. De beheerder maakte Tool A en Tool B aan, stopte een nieuw willekeurig geheim in de init_params van Tool B, en schreef de body van Tool B zo dat deze dat geheim retourneert wanneer hij wordt uitgevoerd. Aan het lid werd vervolgens alleen voor Tool A een per-toolmachtiging toegekend, en volgens het advies werd de staat zonder toekenning voor Tool B na de uitvoering opnieuw gecontroleerd in de database.

De geweigerde helft van de test leverde op wat het product belooft. Als lid gaven de debugroute voor Tool B 403, de updateroute 403 en de exportroute 403, en de toegekende Tool A gaf 200 als sanity check. De omzeilingshelft koppelde Tool B vervolgens via een node uit de toolbibliotheek aan een workflowapplicatie — de binding werd geaccepteerd met HTTP 200 en zonder controle per tool — en het uitvoeren van de workflow gaf HTTP 200 met een body die de naam van de tool, het sentinel-geheim en de sleutellijst ["api_key"] bevatte.

Het beveiligingsadvies zegt dat het geheim op drie lagen aan het licht kwam: in de workflow-API-respons, in een tooluitvoeringsrecord met status SUCCESS, en in de databaserij waar Tool B's init_paramsals een RSA-cijfertekst van 344 bytes staat — wat de manier is waarop de onderzoeker betoogt dat de waarde server-side onder de applicatie-identiteit is ontsleuteld in plaats van door de aanroeper te zijn aangeleverd. Hetzelfde lid dat werd geweigerd op de run-route van de tool verkreeg het ontsleutelde geheim van de tool door het in een workflow te binden.

Eén score gepubliceerd, een hogere bepleit.

De score die aan CVE-2026-77516 is toegekend, is CVSS 3.1 5.4, Medium, met de vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. Uit het record van NVD blijkt dat die score afkomstig is van de adviesfeed van GitHub en niet van NVD's eigen analyse, en de vermelding heeft de status Deferred, wat betekent dat NVD deze niet heeft verrijkt. De eigen classificatie van het archief volgt die gepubliceerde score: medium ernst, geen geregistreerde schade in de praktijk.

Het impactgedeelte van het advies zelf pleit voor meer. Het vermeldt een ernst van 7,1, Hoog, op een vector die de impact op vertrouwelijkheid naar hoog verhoogt, en stelt dat het cijfer stijgt naar 8,1 wanneer het ingezette hulpmiddel geprivilegieerde schrijfacties uitvoert onder de applicatie-identiteit. Dat is een meningsverschil over hoe de blootstelling van inloggegevens moet worden meegeteld, niet over of de bypass bestaat — hetzelfde document toont zowel de fout aan als betoogt dat die te laag wordt gewogen. Niets in het openbare dossier beslist welk cijfer juist is, en de medium-beoordeling van het archief volgt de gepubliceerde CVE-score in plaats van de argumentatie van het advies.

Er staan nog twee beoordelingen in het dossier. {{1}}De SSVC-beslispunten van CISA, toegevoegd aan de NVD-vermelding op 28 september 2026, registreren exploitatie als "poc", automatiseerbaar als "no" en technische impact als "partial" — de waarde "poc" weerspiegelt dat er een proof of concept bestaat, wat inderdaad het geval is, in het advies zelf; het is geen vaststelling dat er in het wild wordt geëxploiteerd.{{/1}} {{2}}Het EPSS-model van FIRST raamde de kans op exploitatie in de komende 30 dagen op 0,242%, op het 15,2e percentiel, in de schatting van 27 oktober 2026.{{/2}}

Een oplossing van vóór het advies, en geen enkele binnen het getroffen bereik.

De versietabel van het advies vermeldt dat 2.0.0 tot en met 2.9.2 getroffen zijn, dat er geen gepatchte versies zijn, en de tekst ervan zegt dat er op het moment van de beoordeling geen opgeloste versie beschikbaar is, met de toevoeging dat een oplossing in een getagde release een CVE eraan zou laten koppelen. De repository van de leverancier vertelt een iets ander verhaal, en het verschil is van belang voor iedereen die beslist wat te draaien.

In de MaxKB-repository zijn de functies die het dispatchpad sluiten — validate_bound_tool_permissions en get_authorized_tool_ids in apps/application/serializers/application.py — afwezig in de tag v2.9.2 en in v2.10.2-lts, v2.10.3-lts en v2.10.4-lts, en aanwezig vanaf v2.10.5-lts. Die release is gepubliceerd op 6 augustus 2026, vier weken vóór het beveiligingsadvies. Dezelfde tag voegt een toolcontrole per gebruiker toe aan base_tool_lib_node.py, op basis van WorkspaceUserResourcePermission, en voegt een gebruikersbewuste filter toe aan shared_resource_auth.py — wat wil zeggen dat deze in grote lijnen de drie herstelstappen implementeert die het beveiligingsadvies later aanbeveelt.

Niemand heeft dat verband publiekelijk genoemd. De releaseopmerkingen van v2.10.5-lts noemen geen oplossing voor toolmachtigingen; ze vermelden vier losstaande beveiligingsitems en een reeks werkzaamheden aan functies en bugs. Het beveiligingsadvies noemt 2.10.5 niet, en het getroffen bereik eindigt simpelweg bij 2.9.2, de laatste release van de 2.9-lijn. De releasegeschiedenis toont na het advies geen 2.9.x-patch, dus een implementatie op 2.9.2 heeft geen gepatchte build binnen zijn eigen lijn. De huidige release is v2.10.8-lts, gepubliceerd op 22 oktober 2026, waarvan de opmerkingen X-Pack-oplossingen voor de autorisatie van gedeelde tools beschrijven in plaats van iets in het dispatchpad van de community-editie.

Wat is niet vastgesteld

Drie dingen moeten van de demonstratie worden onderscheiden. Ten eerste is er geen openbaar rapport dat de bypass tegen iemand is gebruikt. Het dossier betreft een kwetsbaarheid die is gevonden, niet een inbraak die is onderzocht; er is geen slachtoffer, geen toegeschreven actor en geen schade, en de proof of concept uit de advisory is door de onderzoeker in een gecontroleerde werkruimte uitgevoerd. Ten tweede lijkt geen enkele nieuwsorganisatie, toezichthouder of tweede onderzoeksteam de fout te hebben geanalyseerd: de beschikbare berichtgeving beperkt zich tot kwetsbaarheidsdatabases en aggregators — waaronder VulDB, Rapid7's database, Armis, SOCRadar en openCVE — die de CVE vermelden en de beschrijving uit de advisory overnemen, en geen daarvan biedt een onafhankelijke beoordeling van de code. Het hier beschreven mechanisme berust dus op één advisory en op de eigen broncode van de leverancier. Ten derde bestaat er geen cijfer over hoeveel MaxKB-implementaties binnen het getroffen bereik vallen, en noch de leverancier noch de onderzoeker heeft er een gepubliceerd.

De risicogroep is beperkt maar niet triviaal om te tellen: zelfgehoste MaxKB-installaties van de community-editie op 2.0.0 tot en met 2.9.2 met meer dan één werkruimtelid, waarbij een beheerder machtigingen per tool heeft gebruikt om een tool die inloggegevens bevat achter te houden. De kwetsbaarheid is geen remote code execution en vereist een geldig account met lage rechten, waardoor niet het aanvalspad maar de impact op vertrouwelijkheid de score bepaalt. Wat een aanvaller verkrijgt, is begrensd door wat de geweigerde tools bevatten — API-sleutels, tokens en alles wat die ontgrendelen — en dat is ook waarom de auteurs van het advies stellen dat de impact groter is dan een lage beoordeling voor vertrouwelijkheid suggereert.

Wat een operator kan doen

De herstelmaatregelen uit het advies zijn gericht aan de maintainers en niet aan operators, en de drie stappen ervan komen overeen met de code die in v2.10.5-lts verscheen: pas de per-tool-grant toe voordat een tool wordt uitgevoerd in de implementaties van de toolbibliotheek en de toolnode, valideer alle gebonden tool_ids, skill_tool_ids en mcp_tool_ids op het moment van binding zoals knowledge_id_list al wordt gevalideerd, en laat filter_authorized_ids de per-tool-grant raadplegen in plaats van alleen lidmaatschap van de werkruimte.

Voor een team dat een getroffen build draait, zijn dit de praktische stappen die voortvloeien uit de eigen beschrijving van het advies.

• Behandel elk geheim dat is opgeslagen in de init_params van een tool op een getroffen deployment als bereikbaar voor elk lid van de workspace, inclusief de laagste rol, en roteer die inloggegevens in plaats van ervan uit te gaan dat de per-tool-weigering ze heeft beschermd.

• Controleer het lidmaatschap van de workspace. De bypass vereist een geauthenticeerd account in de workspace, dus het verwijderen van inactieve of niet-vertrouwde leden verkleint de blootstelling, zelfs waar de code niet kan worden gepatcht.

• Controleer welke workflows en agents tools koppelen die inloggegevens bevatten, aangezien die koppeling de stap is waarvan het advies zegt dat deze wordt geaccepteerd zonder een controle per tool.

• Als u een upgrade uitvoert, houd er dan rekening mee dat de controle per gebruiker vanaf v2.10.5-lts in de repository staat en dat het advies geen enkele release als de oplossing aanwijst — een beheerder die op de upgrade vertrouwt, vertrouwt op de getagde bron, niet op een patchverklaring van de leverancier.

Niets hiervan maakt de fout dramatisch. Het maakt hem gewoon op een specifieke en leerzame manier: het autorisatiemodel was correct ontworpen, correct gedocumenteerd en afgedwongen op de routes waar iemand eraan dacht een controle te koppelen. Het dispatchpad was geschreven door mensen die nadachten over wat een workflow zou moeten kunnen doen, niet over wie erom vroeg — en in een agentplatform is dat het pad dat de meeste verzoeken daadwerkelijk volgen.

De les uit dit dossier is structureel in plaats van numeriek. Een machtiging per resource is slechts zo sterk als het minst beveiligde toegangspunt, en een agentplatform verzamelt snel toegangspunten: een debugroute, een exportroute, een workflowknooppunt, een chattrigger. MaxKB had de machtigingenlijst en de controle; wat het voor de 2.0- tot en met 2.9-lijn ontbrak, was de gewoonte om bij elke deur dezelfde vraag te stellen.