MaxKB koppelde een shell-tool aan elke assistent met toolondersteuning en heeft dit nooit achter een toegangsbeperking geplaatst

MaxKB, een open-sourceplatform voor bedrijfsassistenten dat onder de GitHub-organisatie 1Panel-dev is gepubliceerd, bouwde zijn chatagents op een framework dat stilzwijgend een shell-tool toevoegt telkens wanneer een shell-capabele backend wordt meegegeven — en MaxKB heeft de tool nooit verwijderd of iemand om goedkeuring voor het gebruik ervan gevraagd. De kwetsbaarheid is CVE-2026-77521, gepubliceerd als GitHub-advisory GHSA-f36j-f34j-h3rx op 2 september 2026 en kreeg een score van 10,0 op 10 onder CVSS 3.1 voor het geval van een openbare of ingebedde assistent. Lasso Security, dat de kwetsbaarheid vond en meldde, toonde aan dat een chatbericht — of tekst die de assistent louter via retrieval of een geüpload document binnenkrijgt — het model ertoe kon brengen commando's uit te voeren: bij een bare-metal-implementatie rechtstreeks op de host, en bij de officiële container via een wrapper waarvan de onderzoekers zeggen dat die met een puntkomma te omzeilen is. Geen enkele geciteerde bron vermeldt dat de kwetsbaarheid in het wild is uitgebuit. De eigen ernstgraad, betrouwbaarheidsbeoordeling en bronnenlijst van het record staan in het AI-incidentenarchief, naast de naburige MaxKB- en agent-tooling-vermeldingen uit dezelfde openbaarmakingsbatch.

MaxKB is een zelfgehost product voor het bouwen van retrieval-augmented assistenten: een beheerder maakt een assistent, koppelt er mogelijkheden aan — tools, Model Context Protocol-servers, vaardigheden, subapplicaties — verbindt een kennisbank die is opgebouwd uit geüploade documenten of gecrawlde websites, en stelt de assistent vervolgens beschikbaar via een geauthenticeerde console of als een openbare, insluitbare chatwidget. Die veelzijdigheid is de blootstelling. De activeringsvoorwaarde van het advies is geen ongebruikelijke configuratie maar de gewone: elke assistent met ten minste één gekoppelde mogelijkheid leidt zijn chat via het getroffen agentpad, terwijl een chat zonder gekoppelde mogelijkheden dat niet doet. Lasso's artikel beschrijft het project als een van de breder omarmde in zijn categorie, en merkt op dat MaxKB normaal wordt ingezet als een multitenantdienst — waardoor een commando dat draait als de applicatiegebruiker onder het tenantmodel valt in plaats van binnen het deel van één tenant daarin.

De shell-tool kwam met het framework, niet met het product.

MaxKB bouwt deze agents met LangChain's deepagents-bibliotheek, vastgezet op versie 0.6.11 in de pyproject.toml van het project, zowel bij de kwetsbare tag als bij de huidige. In apps/application/flow/tools.py, op regel 467 van de tag v2.10.3-lts, roept het project create_deep_agent aan met backend ingesteld op SandboxShellBackend, een MaxKB-subklasse die opdrachten op de host uitvoert. Volgens het beveiligingsadvies injecteert deepagents automatisch een set tools wanneer op die manier een shell-backend wordt doorgegeven: execute, ls, read_file, write_file, edit_file, glob en grep. Ze maken geen deel uit van het argument tools=list, dat alleen de eigen tools van de operator, MCP-tools en skill-tools bevat. Ze kunnen niet uit de interface of via configuratie worden verwijderd.

MaxKB geeft ook `excluded_tools` niet door, het bibliotheekargument dat ze zou verwijderen. Het advies is zorgvuldig over waarom dat ertoe doet, zelfs als remedie: `excluded_tools` "haalt de tool weg uit wat het model wordt verteld, niet uit de executor". Het onderscheid tussen een tool waarvan het model niet op de hoogte is en een tool die niet kan draaien, is deze bug in het klein.

Een poort die drie hulpmiddelen opsomt en de vierde weglaat

De human-in-the-loop-besturing in diezelfde aanroep is één regel, en die somt drie bewerkingen op: interrupt_on={"write_file": False, "read_file": False, "edit_file": False}. Een bestand schrijven, een bestand lezen en een bestand bewerken worden genoemd. Commando-uitvoering is helemaal geen sleutel in het woordenboek. In de interpretatie van het advies betekent dat dat er voor execute geen goedkeuring wordt gevraagd — de drie bestandssysteembewerkingen worden genoemd en expliciet ingesteld om niet te onderbreken, en de shell-tool wordt helemaal niet genoemd.

Alles bij elkaar is het pad: niet-vertrouwde tekst bereikt het model, het model roept execute aan en de opdracht wordt uitgevoerd. Het advies noemt twee manieren waarop niet-vertrouwde tekst kan binnenkomen. De directe manier is chat — een openbare of ingebedde widget, of het gesprek van een andere tenant. De indirecte manier is content die de assistent opneemt: een RAG-document, een geüpload bestand of een webpagina die het platform in een kennisbank crawlt. Lasso's bericht maakt de tweede route concreet en merkt op dat "de groep mensen die tekst vóór het model kan plaatsen groter is dan de groep mensen die ermee kan chatten".

Bij een bare-metalinstallatie is het commando gewoon een commando.

Wat MaxKB ook doet aan containment, het gebeurt in apps/application/flow/backend/sandbox_shell.py, en in v2.10.3-lts begint het met een standaardwaarde. Regel 9 luidt _enable_sandbox = bool(int(CONFIG.get("SANDBOX", 0))), en SANDBOX komt niet voor in Config.defaults in apps/maxkb/conf.py. Zonder een expliciete MAXKB_SANDBOX-instelling is de waarde nul, wordt de wrapper-tak op regel 65 overgeslagen, en bereikt execute subprocess.run met shell=True rechtstreeks op de host, als de gebruiker die de service draait — root, in de bewoording van het advies, als de service als root draait.

Dat is de configuratie die de onderzoekers gebruikten voor hun proof of concept op de host. Ze voerden MaxKB's echte code uit vanaf de bron, met MAXKB_SANDBOX niet ingesteld, maakten een assistent met één gekoppelde tool en vroegen die in één chatbericht om commando's voor systeeminformatie uit te voeren. De execute-tool werd geactiveerd en schreef een bestand waarvan de inhoud de eigen uname-, id- en sw_vers-uitvoer van de host was — uitvoer waarvan volgens de advisory is bevestigd dat die in geen enkele container aanwezig was. Lasso noteert ook de grens van wat het tegenhield: een overduidelijk genoemd proofbestand werd door het model geweigerd, terwijl een onschuldige operationele formulering niet werd geweigerd. Modelalignment is in hun woorden "een gedeeltelijke drempel, geen controle".

Op de officiële image draaide de sandbox en lekte alsnog.

De officiële container zet MAXKB_SANDBOX=1 in de basisimage, op installer/Dockerfile-base regel 48, dus daar is de wrapper actief — en de wrapper is de tweede fout. Hij bouwde één string: env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so gevolgd door gosu sandbox en vervolgens het door het model geleverde commando, overhandigd aan een shell die als root draaide. Omdat het commando als tekst werd geïnterpoleerd, stond alleen het eerste token ervan onder gosu. Elke puntkomma, pipe, redirect of commandosubstitutie in de uitvoer van het model werd door de buitenste root-shell geëvalueerd voordat de sandbox er ooit iets van zag.

Lasso's uiteenzetting laat de werkende vorm ervan zien: een payload van env -i LD_PRELOAD=... PATH="$PATH" gosu sandbox ls; whoami; id, waarbij ls is ingeperkt, whoami niet, en alles wat erop volgt vrij draait. Tijdens tests schreven de onderzoekers met een redirect een bestand dat eigendom van root was, terwijl het binnen de sandbox uitgevoerde innerlijke commando werd geblokkeerd. Daar komt bij dat noch installer/Dockerfile noch installer/Dockerfile-base een USER-richtlijn bevat, waardoor de applicatie-image als UID 0 draait — het advies meldt dat root tijdens runtime wordt bevestigd. De container voerde de commando's daarom toch uit, en de sandbox bepaalde alleen welke daarvan cosmetisch aan de laaggeprivilegieerde gebruiker werden toegeschreven.

De volledige aanvalsmethode die Lasso beschrijft, vereist helemaal geen toegang tot het doelwit. De aanvaller plaatst opdrachten op een webpagina, wacht tot de agent van een slachtoffer die in een kennisbank crawlt, en vervolgens stelt het slachtoffer een gewone vraag. Het antwoord komt correct en legitiem terug; de geïnjecteerde curl is al afgevuurd op de server van de aanvaller. De waarschuwing merkt op dat de onderzoekers alleen hun eigen implementaties hebben getest, niet een externe of gehoste MaxKB-instantie.

Wat de bronnen vaststellen, en wat simpelweg niet wordt gemeten

Het mechanisme, de twee implementatiemodi, de creditering en de gepatchte release komen overeen in vier documenten: het GitHub-advies, het NVD-record gepubliceerd op 21 september 2026, Lasso's eigen technische uiteenzetting van 10 september 2026, en het rapport van GBHackers van 22 september 2026, de enige onafhankelijke berichtgeving die voor deze CVE is gevonden. Geen enkele bron betwist enig deel van de bevinding, en het archief registreert de vermelding als onbetwist met de hoogste betrouwbaarheidsgraad.

De bronnen bevatten geen enkele maatstaf voor blootstelling. Er is geen aantal MaxKB-implementaties, geen aantal vanaf het internet bereikbare of ingebedde assistenten, geen scanresultaat, geen telemetrie en geen met naam genoemd slachtoffer. Niets in het dossier toont aan dat de kwetsbaarheid tegen iemand is gebruikt, en de eigen exploitatiebeoordeling van CISA bevestigt dit: het SSVC-blok dat op 22 september 2026 aan het NVD-record is gekoppeld, beoordeelt exploitatie als "poc", automatiseerbaar als "yes" en technische impact als "total". Het EPSS-model van FIRST raamde op 27 oktober 2026 de kans op exploitatie in de komende 30 dagen op 1,05 procent, het 64e percentiel, en de CVE komt niet voor in de CISA Known Exploited Vulnerabilities-catalogus van 27 oktober 2026. De eigen beoordeling van het archief weerspiegelt hetzelfde bewijs: ernst hoog, werkelijke schade onwaar.

De 10.0 verdient het dat de scope ervan wordt vermeld, want dit is het getal dat het vaakst uit zijn context zal worden geciteerd. Het is de score voor het geval van een publieke of ingebedde assistent, waarbij de CVSS-vector luidt AV:N/AC:L/PR:N/UI:N/S:C — netwerkbereikbaar, geen privileges, geen gebruikersinteractie, met een scopewijziging omdat een commando binnen de assistent overschrijdt naar het hostbesturingssysteem. De score is van de CNA, en de CNA is hier het adviesprogramma van GitHub, waar ook de bronidentificatie van het CVE-record naar verwijst. NVD voert dezelfde vector als secundaire metriek en vermeldt de vermelding met ingang van 28 oktober 2026 in de status "Deferred", wat betekent dat NVD de analyse van de toewijzer heeft gepubliceerd in plaats van zijn eigen analyse.

De patch werd een maand vóór de advisory uitgebracht.

De chronologie loopt terug vanaf de publicatie, en het is het minst intuïtieve deel van het verslag. Lasso meldde de fout privé via GitHub's advieskanaal op 8 juli 2026. MaxKB antwoordde de volgende dag, beperkte het rapport tot de officiële image en vroeg om een container-proof-of-concept; de onderzoekers leverden dat en de sandbox-bypass op 10 juli. Een fixcommit, 594f50f2, belandde op 9 juli — een dag na het rapport — en herschreef sandbox_shell.py zodat de commandostring van het model eerst wordt geparseerd en het gosu-voorvoegsel op elk eenvoudig commando wordt toegepast in plaats van alleen op het eerste, waarbij elke argumentenlijst opnieuw wordt gequote zodat substitutie niet naar de bovenliggende shell kan ontsnappen. Lasso's uiteenzetting beschrijft de wijziging als het toepassen van het gosu-voorvoegsel "op elk eenvoudig commando, niet alleen op het eerste".

De release die het bevatte, v2.10.5-lts, werd gepubliceerd op 6 augustus 2026. De GitHub-advisory verscheen op 2 september, NVD publiceerde de CVE op 21 september, CISA's SSVC-blok werd toegevoegd en GBHackers berichtte op 22 september, en Lasso's eigen verslag verscheen op 10 september — midden in die reeks, niet aan het begin. Een operator die release-tags volgde in plaats van advisoryfeeds, had de patch ongeveer vier weken vóór de waarschuwing.

De versiegrens verdient meer aandacht dan het advies eraan besteedt, omdat de twee primaire bronnen elkaar tegenspreken en de repository de kwestie beslecht. Het formulierveld van het advies vermeldt de getroffen versies als "<= 2.10.3-lts", met de opmerking dat dit is geverifieerd op 2.10.3-lts en dat het kwetsbare pad "waarschijnlijk" alle versies treft die agents op deze manier bouwen. Lasso's eigen verslag noemt het getroffen bereik "<= 2.10.4-lts". De tags bevestigen het bredere bereik: v2.10.4-lts, uitgebracht op 16 juli 2026, bevat dezelfde 75-regelige sandbox_shell.py als v2.10.3-lts, en het herschreven bestand van 311 regels verschijnt voor het eerst in v2.10.5-lts. Een beheerder op 2.10.4-lts die alleen het bereik in het advies had gelezen, zou hebben geconcludeerd buiten het bereik te vallen. Dat was niet het geval.

Wat de oplossing niet deed

Wat 2.10.5-lts oplost, is de wrapper: die bouwt niet langer één shell-string onder root. Wat het niet doet, is iets aan de tool veranderen. Directe lezing van de repository bij tag v2.10.8-lts, gepubliceerd op 22 oktober 2026, laat zien dat de agent nog steeds is geconstrueerd met backend=SandboxShellBackend en dat interrupt_on nog steeds precies drie sleutels bevat — write_file, read_file en edit_file — zonder execute. De eerste twee herstelaanbevelingen uit het advies, om standaard op een niet-uitvoerende backend te bouwen en om "execute": True aan de goedkeuringsmap toe te voegen, zijn niet aanwezig in die release.

De fail-closed-aanbeveling kwam later, in v2.10.7-lts, en is van belang voor de implementatiemodus die er het slechtst aan toe was. Gepubliceerd op 15 oktober 2026 verandert zij de regel in sandbox_shell.py van CONFIG.get("SANDBOX", 0) in CONFIG.get("SANDBOX", 1). Bij een source- of bare-metal-installatie die de variabele nooit heeft ingesteld, staat de wrapper nu standaard aan in plaats van uit, wat in engere zin de aanbeveling "fail closed on non-container deploys" is. De advisory vroeg onder dezelfde kop meer dan dat — dat de flow die kan uitvoeren weigert te starten wanneer de sandbox-runtime niet beschikbaar is — en vroeg afzonderlijk dat de wrapper nooit een commandostring voor een root-shell opbouwt. Aan de containerkant, een feit in plaats van een aanbeveling: noch installer/Dockerfile noch installer/Dockerfile-base bevat een USER-directive bij de tag v2.10.8-lts, dus de applicatie-image start nog steeds als root.

Samen gelezen is de stand van zaken per 28 oktober 2026 als volgt. Het tweede deel van de kwetsbaarheid — de sandbox waaruit een puntkomma wist te ontsnappen — is gedicht, en de fail-open-standaard bij hostimplementaties is gedicht. Het eerste deel, een execute-tool die met een backend-object meekomt en geen sleutel in de goedkeuringsmap is, is nog steeds hoe MaxKB een assistent met toolondersteuning bouwt. Het eigen remediatieadvies van de onderzoekers was het beperkte: upgrade naar 2.10.5-lts of later, en draai de Docker-versie met de sandbox ingeschakeld. GBHackers gaf dezelfde instructie door, plus een bredere lijst voor beheerders — schakel shell-capabele agent-backends uit tenzij code-uitvoering expliciet vereist is, vereis menselijke goedkeuring vóór elke execute-actie, draai containers als non-root, en behandel gecrawlde pagina's, RAG-documenten en uploads als niet-vertrouwde invoer.

Het andere MaxKB-record uit dezelfde septemberbatch

De tweede MaxKB-vermelding uit deze batch in het archief is een andere bug met een slechtere afloop. CVE-2026-77516, ook op 21 september 2026 bij NVD gepubliceerd, is een omzeiling van machtigingen en niet een commando-injectie: vanaf versie 2.0.0 tot en met 2.9.2 kon een werkruimtelid met de laagste rol, die expliciet via WorkspaceUserResourcePermission de toegang tot een tool was ontzegd, toch de identifier van die tool binden via tool_ids, skill_tool_ids of mcp_tool_ids en deze uitvoeren via het agent- of workflow-dispatchpad. Het dispatchpad past de per-tool-toekenning die de toegewijde toolroutes afdwingen niet opnieuw toe, en bij tooluitvoering worden server-side init_params ontsleuteld, zodat de aanroeper de inloggegevens ontvangt die worden meegedragen door de tool waarvoor hem de toegang was ontzegd. De score is 5.4, en de beschrijving van NVD eindigt met een zin die CVE-2026-77521 niet hoeft te bevatten: "Er is op het moment van deze beoordeling geen opgeloste versie beschikbaar."

Het contrast is het nuttige deel voor iedereen die het tweetal beoordeelt. De kwetsbaarheid met score 10,0 had binnen een dag een oplossing gecommit, die een maand vóór publicatie van de kwetsbaarheid werd uitgebracht. Voor de kwetsbaarheid met score 5,4 was op het moment van de CVE geen opgeloste versie gepubliceerd.

Wat echt nog open is, is kleiner dan de score suggereert en groter dan een patchnotitie impliceert. De bevinding wordt niet betwist en het mechanisme is van begin tot eind geverifieerd in beide implementatiemodi door het team dat het heeft gevonden. De blootstelling is volledig ongemeten — niemand heeft gepubliceerd hoeveel MaxKB-assistenten een tool hebben, hoeveel daarvan bereikbaar zijn voor een niet-vertrouwde partij, of hoeveel er op een host draaien zonder de sandbox — dus het reële gevolg van de fout is een functie van implementatiegewoonten die geen enkele geciteerde bron telt. En het deel van het ontwerp dat de score naar het maximum dreef, zit nog steeds in de huidige release: een mogelijkheid die commando's uitvoert, standaard gekoppeld, afwezig in het overzicht dat eerst een mens laat beslissen.