MaxKB: agentens dispatch-väg gör att en användare som nekats ett verktyg fortfarande kan anropa det och läsa dess autentiseringsuppgifter.

MaxKB, den öppna företags-AI-assistenten som underhålls av 1Panel-dev, levereras med en behörighetslista per användare och per verktyg så att en administratör kan bevilja en arbetsytemedlem ett verktyg och neka ett annat. Enligt säkerhetsrådgivningen som publicerades den 2 september 2026 gällde den nekelsen för verktygets egna rutter men inte för den sökväg som en agent eller ett arbetsflöde använder för att anropa samma verktyg. En arbetsytemedlem med den lägsta rollen kunde ange identifieraren för ett nekat verktyg när den byggde ett arbetsflöde, köra arbetsflödet och få inte bara verktygets utdata utan även de autentiseringsuppgifter som MaxKB dekrypterar på serversidan för att kunna köra det. Versionerna 2.0.0 till och med 2.9.2 påverkas, och rådgivningen angav ingen patchad version. Den här posten – auktoriseringsbypassen för MaxKB:s verktygsutskick – är en post i OrcaRouter AI Incident Archive, som innehåller hela postuppsättningen och den här incidentens närliggande poster.

Det som gör att fallet är värt att läsa noggrant är inte poängen. Det är att produkten redan hade rätt kontroll, tillämpade den på den uppenbara dörren och lämnade en andra dörr till samma funktion utan övervakning. Säkerhetsrådgivningen GHSA-383v-fx78-pphm skrevs av forskaren som hittade den och publicerades via GitHubs rådgivningssystem kl. 07:43 UTC den 2 september 2026, med Matteo Panzeri (@matte1782) angiven som upptäckare. CVE-posten CVE-2026-77516 följde den 21 september 2026.

Vad rådgivningen fastställer

MaxKB:s modell per verktyg är WorkspaceUserResourcePermission, som i säkerhetsrådgivningen beskrivs som en tillåtelselista med standardnekande som fastställs vid begäran. De dedikerade verktygsrutterna tillämpar den. Säkerhetsrådgivningen listar tillämpningen i apps/tools/views/tool.py, där Operate.put, Operate.get, Debug.post, Export.get och Delete var och en har en kontroll av visningsbehörighet mot anroparens verktygsbehörighet i arbetsytan. Debug.post är den rutt som ligger närmast att helt enkelt köra ett verktyg, och den är åtkomstbegränsad.

Agent- och arbetsflödesdispatchvägen tillämpar inte den kontrollen igen. Säkerhetsrådgivningen spårar tre separata ställen där den saknas. I apps/application/serializers/application.py binder applikationsserialiseraren tool_ids, skill_tool_ids och mcp_tool_ids direkt från förfrågningsindata utan auktorisering per verktyg – och rådgivningen påpekar att asymmetrin är synlig i samma fil, eftersom knowledge_id_list valideras mot användarens åtkomliga kunskapsbaser några rader längre ner medan verktyg inte gör det. I apps/common/utils/shared_resource_auth.py släpper filter_authorized_ids igenom alla verktyg i anroparens egen arbetsyta ovillkorligt; grinden för korsarbetsyta som den förlitar sig på är en hook som endast finns i företagsversionen och som saknas i community-utgåvan, och den konsulterar aldrig WorkspaceUserResourcePermission. Och vid mottagaren kör apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py verktygets lagrade kod med dess init_params dekrypterade med rsa_long_decrypt under applikationens identitet, utan behörighetskontroll per verktyg.

Säkerhetsrådgivningen kallar resultatet för en confused deputy-körning: arbetsflödesutskicket kör ett verktyg, och dess lagrade hemligheter, som samma anropare nekas tillgång till på verktygets egna rutter. Exponeringen av autentiseringsuppgifter är den del som överskrider vanlig obehörig verktygsanvändning. Ett verktygs init_params krypteras i vila med RSA och dekrypteras på serversidan endast vid körningstillfället, så en anropare som utlöser den körningen får värden som denne aldrig har haft och inte kunde ha angett.

Demonstrationen, i forskarens egna siffror

Säkerhetsmeddelandet rapporterar dynamisk bekräftelse på v2.9.2, körd från den officiella allt-i-ett-avbilden, 1panel/maxkb:v2.9.2. Uppsättningen var en arbetsyta, en administratör och en andra medlem med rollen USER. Administratören skapade Verktyg A och Verktyg B, lade en ny slumpmässig hemlighet i Verktyg B:s init_params, och skrev Verktyg B:s innehåll så att det returnerar den hemligheten när det körs. Medlemmen beviljades sedan en verktygsspecifik behörighet endast för Verktyg A, och säkerhetsmeddelandet anger att tillståndet med noll beviljade behörigheter för Verktyg B kontrollerades på nytt i databasen efter körningen.

Den nekade hälften av testet gav det som produkten utlovar. Som medlem svarade felsökningsrutten för Tool B med 403, uppdateringsrutten svarade 403, exportrutten svarade 403 och den beviljade Tool A returnerade 200 som en rimlighetskontroll. Den kringgående hälften band sedan Tool B till en arbetsflödesapplikation via en nod i verktygsbiblioteket – bindningen accepterades med HTTP 200 och utan kontroll per verktyg – och körningen av arbetsflödet returnerade HTTP 200 med en brödtext som innehöll verktygets namn, sentinel-hemligheten och nyckellistan ["api_key"].

Säkerhetsmeddelandet säger att hemligheten framkom på tre nivåer: i workflow-API-svaret, i en post för verktygskörning med statusen SUCCESS och i databasraden där Tool B:s init_params ligger som en 344-byte RSA-chiffertext — vilket är hur forskaren argumenterar för att värdet dekrypterades på serversidan under applikationsidentiteten i stället för att tillhandahållas av anroparen. Samma medlem som nekades på verktygets körrutt erhöll verktygets dekrypterade hemlighet genom att binda in den i ett workflow.

Ett publicerat resultat, ett högre hävdat

Poängen som är kopplad till CVE-2026-77516 är CVSS 3.1 5.4, Medium, med vektorn AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. NVD:s post visar att poängen kommer från GitHubs rådgivningsflöde snarare än från NVD:s egen analys, och posten har statusen Deferred, vilket innebär att NVD inte har berikat den. Arkivets egen klassificering följer den publicerade poängen: medelsvår allvarlighetsgrad, ingen dokumenterad skada i verkligheten.

Rådgivningens eget avsnitt om påverkan argumenterar för mer. Det anger en allvarlighetsgrad på 7,1, Hög, på en vektor som höjer konfidentialitetspåverkan till hög, och säger att siffran stiger till 8,1 när det utskickade verktyget utför privilegierade skrivningar under applikationsidentiteten. Det är en oenighet om hur man ska räkna in exponeringen av autentiseringsuppgifter, inte om huruvida kringgåendet existerar – samma dokument både demonstrerar bristen och hävdar att den undervärderas. Inget i det offentliga materialet avgör vilken siffra som är rätt, och arkivets medelbetyg följer den publicerade CVE-poängen snarare än rådgivningens argument.

Ytterligare två bedömningar finns dokumenterade. CISA:s SSVC-beslutspunkter, som lades till i NVD-posten den 28 september 2026, registrerar utnyttjande som "poc", automatiserbarhet som "no" och teknisk påverkan som "partial" – värdet "poc" återspeglar att det finns ett proof of concept, vilket det gör, i själva rådgivningen; det utgör inte ett konstaterande av exploatering i det vilda. FIRST:s EPSS-modell uppskattade sannolikheten för exploatering under de kommande 30 dagarna till 0,242 %, vid 15,2:a percentilen, i uppskattningen daterad 27 oktober 2026.

En rättelse som föregår rådgivningen, och ingen inom det påverkade intervallet

Säkerhetsrådets versionstabell anger att 2.0.0 till och med 2.9.2 är påverkade, att inga patchade versioner finns, och i dess text står det att ingen åtgärdad version är tillgänglig vid granskningstillfället, med tillägget att en åtgärd i en taggad utgåva skulle göra det möjligt att förankra en CVE i den. Leverantörens kodförråd berättar en något annan historia, och skillnaden spelar roll för alla som ska avgöra vad de ska köra.

I MaxKB-repositoriet saknas de funktioner som stänger dispatch-vägen — validate_bound_tool_permissions och get_authorized_tool_ids i apps/application/serializers/application.py — i taggen v2.9.2 och i v2.10.2-lts, v2.10.3-lts och v2.10.4-lts, och finns från och med v2.10.5-lts. Den versionen publicerades den 6 augusti 2026, fyra veckor före säkerhetsrådgivningen. Samma tagg lägger till en verktygskontroll per användare i base_tool_lib_node.py, med hjälp av WorkspaceUserResourcePermission, och lägger till ett användarmedvetet filter i shared_resource_auth.py — vilket vill säga att den i stora drag implementerar de tre åtgärdssteg som säkerhetsrådgivningen senare rekommenderar.

Ingen har offentligt uttalat den kopplingen. Versionsinformationen för v2.10.5-lts nämner ingen åtgärd för verktygsbehörigheter; den listar fyra orelaterade säkerhetspunkter och en omgång funktions- och buggarbete. Säkerhetsmeddelandet namnger inte 2.10.5, och dess påverkade intervall slutar helt enkelt vid 2.9.2, den sista utgåvan i 2.9-serien. Utgivningshistoriken visar ingen 2.9.x-rättning efter säkerhetsmeddelandet, så en driftsättning på 2.9.2 har ingen åtgärdad build inom sin egen serie. Den aktuella utgåvan är v2.10.8-lts, publicerad den 22 oktober 2026, vars versionsinformation beskriver X-Pack-rättningar av auktorisering för delade verktyg snarare än något i communityutgåvans dispatch-väg.

Vad som inte är fastställt

Tre saker är värda att skilja från demonstrationen. För det första finns det ingen offentlig rapport om att kringgåendet har använts mot någon. Det som finns dokumenterat är en sårbarhet som hittades, inte ett intrång som utreddes; den har inget offer, ingen tillskriven aktör och ingen skada, och rådgivningens proof of concept kördes av forskaren i en kontrollerad arbetsyta. För det andra verkar ingen nyhetsorganisation, tillsynsmyndighet eller annat forskarlag ha analyserat bristen: den bevakning som finns är begränsad till sårbarhetsdatabaser och aggregatorer – {{1}}VulDB{{/1}}, {{2}}Rapid7s databas{{/2}}, {{3}}Armis{{/3}}, {{4}}SOCRadar{{/4}} och {{5}}openCVE{{/5}} bland dem – som listar CVE:n och återger rådgivningens beskrivning, och ingen av dem erbjuder en oberoende bedömning av koden. Mekanismen som beskrivs här vilar därför på en enda rådgivning och på leverantörens egen källkod. För det tredje finns det ingen siffra för hur många {{6}}MaxKB{{/6}}-distributioner som ligger i det drabbade intervallet, och varken leverantören eller forskaren har publicerat någon.

Den utsatta gruppen är smal men inte trivial att räkna: egenhostade MaxKB-installationer av community edition från 2.0.0 till och med 2.9.2 som har fler än en arbetsytemedlem, där en administratör har använt verktygsspecifika behörigheter för att undanhålla ett verktyg som innehåller autentiseringsuppgifter. Sårbarheten är inte fjärrkodkörning och kräver ett giltigt konto med låga privilegier, vilket är anledningen till att det är konfidentialitetspåverkan som driver poängen snarare än attackvägen. Det en angripare kan vinna är begränsat till vad de nekade verktygen innehåller – API-nycklar, tokens och vad dessa ger åtkomst till – vilket också är anledningen till att säkerhetsmeddelandets författare hävdar att påverkan är större än en låg konfidentialitetsklassning antyder.

Vad en operatör kan göra

Rådgivningens åtgärdsförslag riktar sig till underhållarna snarare än till operatörerna, och dess tre steg motsvarar koden som dök upp i v2.10.5-lts: tillämpa den verktygsspecifika behörigheten innan ett verktyg körs i implementationerna för verktygsbiblioteket och verktygsnoden, validera alla bundna tool_ids, skill_tool_ids och mcp_tool_ids vid bindningstillfället på samma sätt som knowledge_id_list redan gör, och låt filter_authorized_ids använda den verktygsspecifika behörigheten i stället för enbart arbetsytans medlemskap.

För ett team som kör en påverkad version är de praktiska stegen som följer av rådgivningens egen beskrivning följande.

• Behandla varje hemlighet som lagras i ett verktygs init_params på en drabbad distribution som nåbar av alla arbetsytemedlemmar, inklusive den lägsta rollen, och rotera dessa autentiseringsuppgifter i stället för att anta att den verktygsspecifika nekningen skyddade dem.

• Granska medlemskapet i arbetsytan. Kringgåendet kräver ett autentiserat konto i arbetsytan, så att ta bort inaktiva eller obetrodda medlemmar minskar exponeringen även där koden inte kan patchas.

• Granska vilka arbetsflöden och agenter som binder verktyg som bär autentiseringsuppgifter, eftersom den bindningen är det steg som rådgivningen säger accepteras utan en kontroll per verktyg.

• Om du uppgraderar bör du notera att den användarspecifika kontrollen finns i repositoryt från och med v2.10.5-lts och att ingen version pekas ut som rättelsen i säkerhetsmeddelandet — en operatör som förlitar sig på uppgraderingen förlitar sig på den taggade källkoden, inte på ett patchuttalande från leverantören.

Inget av detta gör bristen dramatisk. Det gör den ordinär på ett specifikt och lärorikt sätt: auktoriseringsmodellen var korrekt utformad, korrekt dokumenterad och tillämpad på de rutter som någon kom ihåg att skydda. Dispatch-vägen skrevs av människor som tänkte på vad ett arbetsflöde borde kunna göra, inte på vem som frågade — och på en agentplattform är det den väg som de flesta förfrågningar faktiskt tar.

Lärdomen från posten är strukturell snarare än numerisk. En behörighet per resurs är bara så stark som sin minst skyddade ingångspunkt, och en agentplattform samlar snabbt på sig ingångspunkter: en felsökningsrutt, en exportrutt, en arbetsflödesnod, en chattutlösare. MaxKB hade behörighetslistan och kontrollen; det som saknades, för 2.0–2.9-serien, var vanan att ställa samma fråga vid varje dörr.