MaxKB: o caminho de despacho do agente permite que um usuário a quem foi negada uma ferramenta ainda assim a chame e leia suas credenciais

O MaxKB, assistente de IA empresarial de código aberto mantido pela 1Panel-dev, oferece uma lista de permissões por usuário e por ferramenta, para que um administrador possa conceder uma ferramenta a um membro do espaço de trabalho e negar outra. De acordo com o aviso de segurança publicado em 2 de setembro de 2026, essa negação era aplicada nas rotas próprias da ferramenta, mas não no caminho que um agente ou fluxo de trabalho usa para chamar a mesma ferramenta. Um membro do espaço de trabalho com o papel mais baixo podia indicar o identificador de uma ferramenta negada ao criar um fluxo de trabalho, executar o fluxo e receber não apenas a saída da ferramenta, mas também as credenciais que o MaxKB descriptografa no servidor para executá-la. As versões 2.0.0 a 2.9.2 são afetadas, e o aviso não indicou nenhuma versão corrigida. Este registro — o desvio de autorização no despacho de ferramentas do MaxKB — é uma entrada no OrcaRouter AI Incident Archive, que contém o conjunto completo de registros e as entradas adjacentes deste incidente.

O que torna o caso digno de uma leitura atenta não é a pontuação. É que o produto já tinha a verificação correta, aplicou-a na porta óbvia e deixou sem monitoramento uma segunda porta para a mesma funcionalidade. O advisory, GHSA-383v-fx78-pphm, foi escrito pelo pesquisador que o encontrou e publicado por meio do sistema de advisories do GitHub às 07:43 UTC de 2 de setembro de 2026, creditando Matteo Panzeri (@matte1782). O registro CVE, CVE-2026-77516, veio em 21 de setembro de 2026.

O que o aviso estabelece

O modelo por ferramenta do MaxKB é WorkspaceUserResourcePermission, descrito no aviso como uma lista de permissões (allow-list) com negação por padrão, resolvida no momento da solicitação. As rotas dedicadas a ferramentas aplicam essa permissão. O aviso lista a aplicação em apps/tools/views/tool.py, onde Operate.put, Operate.get, Debug.post, Export.get e Delete carregam cada uma uma verificação de permissão de visualização em relação à permissão de ferramenta do workspace do chamador. Debug.post é a rota mais próxima de simplesmente executar uma ferramenta, e ela é protegida por verificação.

O caminho de despacho do agente e do fluxo de trabalho não reaplica essa verificação. O aviso rastreia três locais separados onde ela está ausente. Em apps/application/serializers/application.py, o serializador de aplicação vincula tool_ids, skill_tool_ids e mcp_tool_ids diretamente da entrada da requisição sem autorização por ferramenta — e o aviso aponta que a assimetria é visível no mesmo arquivo, porque knowledge_id_list é validado em relação às bases de conhecimento acessíveis do usuário algumas linhas abaixo, enquanto as ferramentas não são. Em apps/common/utils/shared_resource_auth.py, filter_authorized_ids passa cada ferramenta no próprio espaço de trabalho do chamador incondicionalmente; o portão entre espaços de trabalho no qual ele se baseia é um gancho exclusivo da edição enterprise que está ausente na edição comunitária, e ele nunca consulta WorkspaceUserResourcePermission. E no destino, apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py executa o código armazenado da ferramenta com seus init_params descriptografados por rsa_long_decrypt sob a identidade da aplicação, sem verificação de concessão por ferramenta.

O aviso classifica o resultado como uma execução de "confused deputy": o despacho de workflow executa uma ferramenta, e seus segredos armazenados, aos quais o mesmo chamador tem acesso negado nas rotas da própria ferramenta. A exposição de credenciais é a parte que excede o uso não autorizado comum de uma ferramenta. Os init_params de uma ferramenta são criptografados em repouso com RSA e descriptografados no lado do servidor apenas no momento da execução, de modo que um chamador que dispara essa execução recebe valores que nunca teve e não poderia ter fornecido.

A demonstração, nos próprios números do pesquisador

O aviso relata confirmação dinâmica na v2.9.2, executada a partir da imagem all-in-one oficial, 1panel/maxkb:v2.9.2. A configuração era um workspace, um administrador e um segundo membro com a função USER. O administrador criou a Ferramenta A e a Ferramenta B, colocou um novo segredo aleatório nos init_params da Ferramenta B e escreveu o corpo da Ferramenta B para retornar esse segredo quando executado. O membro recebeu então uma permissão por ferramenta apenas para a Ferramenta A, e o aviso diz que o estado de concessão zero para a Ferramenta B foi verificado novamente no banco de dados após a execução.

A metade negada do teste retornou o que o produto promete. Como membro, a rota de depuração da Ferramenta B respondeu 403, a rota de atualização respondeu 403, a rota de exportação respondeu 403, e a Ferramenta A concedida retornou 200 como verificação de sanidade. A metade de contorno então vinculou a Ferramenta B a uma aplicação de fluxo de trabalho por meio de um nó de biblioteca de ferramentas — o vínculo foi aceito com HTTP 200 e sem verificação por ferramenta — e a execução do fluxo de trabalho retornou HTTP 200 com um corpo contendo o nome da ferramenta, o segredo sentinela e a lista de chaves ["api_key"].

O comunicado diz que o segredo surgiu em três camadas: na resposta da API de workflow, em um registro de execução de ferramenta com estado SUCCESS e na linha do banco de dados em que o init_params da Ferramenta B está como um texto cifrado RSA de 344 bytes — que é como o pesquisador argumenta que o valor foi descriptografado no lado do servidor sob a identidade da aplicação, em vez de ter sido fornecido pelo chamador. O mesmo membro que foi recusado na rota de execução da ferramenta obteve o segredo descriptografado da ferramenta ao vinculá-lo a um workflow.

Uma pontuação publicada, uma mais alta defendida.

A pontuação associada ao CVE-2026-77516 é CVSS 3.1 5.4, Média, com o vetor AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. O registro do NVD mostra que essa pontuação veio do feed de avisos do GitHub, e não da própria análise do NVD, e a entrada tem o status Deferred, o que significa que o NVD não a enriqueceu. A classificação do próprio arquivo segue essa pontuação publicada: severidade média, sem dano real registrado.

A própria seção de impacto do aviso defende mais. Ele indica uma gravidade de 7,1, Alta, em um vetor que eleva o impacto à confidencialidade para alto, e afirma que o valor sobe para 8,1 quando a ferramenta acionada executa gravações privilegiadas sob a identidade da aplicação. Trata-se de uma divergência sobre como contabilizar a exposição das credenciais, não sobre se o contorno existe — o mesmo documento demonstra a falha e argumenta que ela está sendo subestimada. Nada no registro público resolve qual valor está correto, e a classificação média do arquivo acompanha a pontuação CVE publicada, e não o argumento do aviso.

Há mais duas avaliações registradas. Os pontos de decisão do SSVC da CISA, acrescentados à entrada do NVD em 28 de setembro de 2026, registram a exploração como "poc", automatizável como "não" e impacto técnico como "parcial" — o valor "poc" reflete que existe uma prova de conceito, o que de fato ocorre, no próprio aviso; não se trata de uma constatação de exploração em ambiente real. O modelo EPSS da FIRST estimou a probabilidade de exploração nos próximos 30 dias em 0,242%, no 15,2º percentil, na estimativa datada de 27 de outubro de 2026.

Uma correção que antecede o aviso, e nenhuma dentro do intervalo afetado

A tabela de versões do aviso diz que as versões afetadas são da 2.0.0 à 2.9.2, que não há versões corrigidas e que, segundo o texto, nenhuma versão corrigida está disponível até o momento da revisão, acrescentando que uma correção em uma versão com tag permitiria vincular um CVE a ela. O repositório do fornecedor conta uma história ligeiramente diferente, e a diferença importa para qualquer pessoa que esteja decidindo o que executar.

No repositório MaxKB, as funções que fecham o caminho de despacho — validate_bound_tool_permissions e get_authorized_tool_ids em apps/application/serializers/application.py — estão ausentes da tag v2.9.2 e das tags v2.10.2-lts, v2.10.3-lts e v2.10.4-lts, e presentes a partir da v2.10.5-lts. Essa versão foi publicada em 6 de agosto de 2026, quatro semanas antes do aviso de segurança. A mesma tag adiciona uma verificação de ferramenta por usuário ao base_tool_lib_node.py, com base em WorkspaceUserResourcePermission, e adiciona um filtro que considera o usuário ao shared_resource_auth.py — ou seja, implementa, em linhas gerais, as três etapas de remediação que o aviso recomenda posteriormente.

Ninguém declarou publicamente essa conexão. As notas de lançamento da v2.10.5-lts não mencionam uma correção de permissão de ferramenta; elas listam quatro itens de segurança não relacionados e um lote de trabalho de recursos e correções de bugs. O comunicado de segurança não nomeia a 2.10.5, e seu intervalo afetado simplesmente termina na 2.9.2, a última versão da linha 2.9. O histórico de lançamentos não mostra nenhum patch 2.9.x após o comunicado, então uma implantação na 2.9.2 não tem build corrigido dentro da própria linha. O lançamento atual é a v2.10.8-lts, publicada em 22 de outubro de 2026, cujas notas descrevem correções do X-Pack para autorização de ferramentas compartilhadas, e não algo no caminho de despacho da edição comunitária.

O que não está estabelecido

Três coisas merecem ser separadas da demonstração. Primeiro, não há relato público de que o bypass tenha sido usado contra alguém. O registro é uma vulnerabilidade que foi encontrada, não uma intrusão que tenha sido investigada; não há vítima, ator atribuído nem dano, e a prova de conceito do aviso foi executada pelo pesquisador em um ambiente de trabalho controlado. Segundo, nenhuma organização de notícias, regulador ou segunda equipe de pesquisa parece ter analisado a falha: a cobertura existente limita-se a bancos de dados de vulnerabilidades e agregadores — entre eles VulDB, o banco de dados da Rapid7, Armis, SOCRadar e openCVE — que listam o CVE e trazem a descrição do aviso, e nenhum deles oferece uma avaliação independente do código. O mecanismo, tal como descrito aqui, portanto, baseia-se em um único aviso e no próprio código-fonte do fornecedor. Terceiro, não existe número sobre quantas implantações do MaxKB estão na faixa afetada, e nem o fornecedor nem o pesquisador publicaram um.

A população em risco é estreita, mas não trivial de contar: instalações self-hosted da edição comunitária do MaxKB, da 2.0.0 à 2.9.2, que têm mais de um membro no workspace, nas quais um administrador usou permissões por ferramenta para negar uma ferramenta que carrega credenciais. A falha não é execução remota de código e exige uma conta válida com privilégios baixos, e é por isso que o impacto na confidencialidade é o que impulsiona a pontuação, e não o caminho de ataque. O que um atacante obtém é limitado pelo que as ferramentas negadas contêm — chaves de API, tokens e tudo o que eles desbloqueiam —, o que também explica por que os autores do aviso argumentam que o impacto é maior do que uma classificação baixa de confidencialidade sugere.

O que um operador pode fazer

A remediação do aviso é destinada aos mantenedores, e não aos operadores, e suas três etapas correspondem ao código que surgiu na v2.10.5-lts: aplicar a concessão por ferramenta antes de executar uma ferramenta nas implementações da biblioteca de ferramentas e do nó de ferramenta, validar todos os tool_ids, skill_tool_ids e mcp_tool_ids vinculados no momento da vinculação, da mesma forma que knowledge_id_list já é validado, e fazer com que filter_authorized_ids consulte a concessão por ferramenta em vez de apenas a associação ao workspace.

Para uma equipe que esteja executando uma build afetada, as etapas práticas que decorrem da própria descrição do comunicado são as seguintes.

• Trate todo segredo armazenado no init_params de uma ferramenta em uma implantação afetada como acessível por qualquer membro do workspace, incluindo a função mais baixa, e faça a rotação dessas credenciais em vez de presumir que a negação por ferramenta as protegeu.

• Audite a associação ao workspace. O bypass exige uma conta autenticada no workspace, portanto remover membros inativos ou não confiáveis reduz a exposição mesmo onde o código não pode ser corrigido.

• Revise quais fluxos de trabalho e agentes associam ferramentas que contêm credenciais, uma vez que essa associação é a etapa que o aviso diz ser aceite sem uma verificação por ferramenta.

• Se estiver a atualizar, note que a verificação por utilizador aparece no repositório a partir da v2.10.5-lts e que nenhuma versão é designada como a correção pelo aviso — um operador que dependa da atualização está a confiar no código-fonte tagueado, não numa declaração de correção do fornecedor.

Nada disso torna a falha dramática. Torna-a comum de uma forma específica e instrutiva: o modelo de autorização foi projetado corretamente, documentado corretamente e aplicado nas rotas que alguém lembrou de proteger. O caminho de despacho foi escrito por pessoas pensando no que um fluxo de trabalho deveria poder fazer, não em quem estava pedindo — e, em uma plataforma de agentes, é esse o caminho que a maioria das solicitações realmente percorre.

A lição do registro é estrutural, não numérica. Uma permissão por recurso é tão forte quanto seu ponto de entrada menos protegido, e uma plataforma de agentes acumula pontos de entrada rapidamente: uma rota de depuração, uma rota de exportação, um nó de fluxo de trabalho, um gatilho de chat. O MaxKB tinha a lista de concessões e a verificação; o que lhe faltava, para a linha 2.0 a 2.9, era o hábito de fazer a mesma pergunta em todas as portas.