Natan Nehorai

Existe um problema onde um locatário com um token de espaço de trabalho pode anexar um volume ao implantar uma função, endpoint ou fila de tarefas. O gateway constrói o caminho do host juntando a raiz dos volumes compartilhados, o nome do espaço de trabalho e o identificador do volume da configuração do stub, sem verificar se o espaço de trabalho possui o volume especificado. Ao usar segmentos de diretório pai no identificador do volume, ocorre um traversal de caminho, colapsando o caminho unido para a raiz do sistema de arquivos do worker. Isso permite que o worker monte o caminho no sandbox com acesso de leitura e gravação, a menos que explicitamente marcado como somente leitura, permitindo que um locatário leia e grave arquivos do worker e acesse volumes de outros locatários armazenados na mesma máquina.

O worker Beta9 fornece a API de arquivos do sandbox de fora do contêiner. A função `getHostPathFromContainerPath` converte o caminho do contêiner do locatário em um caminho do worker. Se o caminho não resolvido começar com um destino de montagem, incluindo a montagem de upload padrão em `/tmp/.beta9`, o restante é unido usando `filepath.Join`, que limpa segmentos de diretório pai após a verificação do prefixo. Uma sequência longa o suficiente desses segmentos permite nomear qualquer caminho absoluto no worker. Além disso, um caminho que não corresponda a nenhuma montagem é unido à raiz do contêiner e aberto no sistema de arquivos do próprio worker, portanto, um link simbólico absoluto é seguido em relação à raiz do worker. As operações de upload, download, stat, list, find-in-files, replace-in-files e delete-file utilizam esse auxiliar. Um locatário com um token de espaço de trabalho e um sandbox em execução pode ler, gravar, listar e excluir arquivos no worker de hospedagem como root, incluindo arquivos de outros locatários na máquina. Uma prova de conceito demonstrou a recuperação do token de conta de serviço do Kubernetes do pod do worker, que nos manifestos de nó remoto fornecidos está vinculado ao cluster-admin.

Existe uma fuga de sandbox no processo de construção de imagens onde comandos de shell em uma definição de imagem de locatário são executados usando Buildah com `BUILDAH ISOLATION=chroot`. Como o processo retém os namespaces de PID, rede, IPC e usuário do pod do worker, enquanto executa como uid 0 com `CAP DAC OVERRIDE` (uma capacidade que permite ignorar verificações de permissão de leitura, gravação e execução de arquivos), um invasor pode acessar o sistema de arquivos do container do worker via `/proc/1/root`. Isso permite que um locatário com um token de espaço de trabalho assuma o controle do build worker e leia seu token de conta de serviço do Kubernetes, bem como acesse os binários `runc`, `buildah` e `runsc` e diretórios do host montados no pod.

O software implementa o endurecimento contra Server-Side Request Forgery (SSRF) utilizando uma lista de negação (denylist) estática de nomes de host e literais de IP na função `assertSafeFetchTarget()`. No entanto, ele não resolve o DNS nem revalida os hosts após redirecionamentos HTTP. Um invasor que consiga influenciar uma chamada FetchURL, por exemplo, via injeção de prompt, pode fornecer um nome de host público manipulado que resolve para um endereço de loopback ou outro endereço interno, ou uma URL pública que redireciona para tal alvo, alcançando assim serviços de rede interna que a lista de negação deveria bloquear. Como o FetchURL está incluído no conjunto de ferramentas de aprovação automática padrão, a chamada não requer confirmação interativa do usuário no modo manual.

A ferramenta Pydantic-AI MCP Run Python possui uma configuração de sandbox Deno excessivamente permissiva. Isso permite que o código Python executado dentro da sandbox acesse a interface localhost do sistema hospedeiro, potencialmente possibilitando ataques de Server-Side Request Forgery (SSRF). O projeto está arquivado e é improvável que receba uma correção. A ferramenta permite que o código Python subjacente acesse a interface localhost do host. Este acesso pode ser explorado para executar ataques SSRF.

O n8n é afetado por uma vulnerabilidade crítica de Execução Remota de Código (RCE) em seu sistema de avaliação de Expressões do fluxo de trabalho. Um atacante autenticado pode explorar isso para executar código arbitrário com os privilégios do processo n8n. Isso é possível porque as expressões fornecidas por usuários autenticados durante a configuração do fluxo de trabalho são avaliadas em um contexto de execução que não possui isolamento suficiente em relação ao runtime subjacente. A exploração bem-sucedida pode levar ao comprometimento total da instância afetada, potencialmente concedendo acesso não autorizado a dados sensíveis, modificação de fluxos de trabalho e execução de operações em nível de sistema. Aproximadamente 981.000 serviços são estimados como expostos anualmente. A questão envolve contornar o sandbox de Expressão, permitindo a execução de código JavaScript arbitrário.

Existe uma vulnerabilidade no n8n que permite a um invasor contornar as restrições da sandbox do python-task-executor. Este contorno é alcançado através do uso de formatação de strings e tratamento de exceções, permitindo a execução de código Python arbitrário e sem restrições no sistema operacional subjacente. A vulnerabilidade pode ser explorada por um usuário autenticado com permissões básicas via bloco de Código. Em instâncias operando sob o modo de execução "Internal", é possível assumir o controle total da instância do n8n. Se a instância operar sob o modo de execução "External", a execução de código arbitrário ocorre dentro de um contêiner Sidecar, reduzindo o impacto. A vulnerabilidade está relacionada a um recurso de tratamento de erros do Python 3.10 que contorna a análise estática. A vulnerabilidade é explorável através do uso de f-strings e do objeto ` traceback `.

A mutação `cleanIptables` é suscetível a injeção de comandos do sistema operacional. Isso permite que atacantes não autenticados dentro do cluster potencialmente executem código remoto em todo o cluster. Os atacantes podem obter acesso root nos nós do Kubernetes através da exploração desta vulnerabilidade.

O Chaos Controller Manager no Chaos Mesh expõe um servidor de depuração GraphQL sem autenticação para todo o cluster Kubernetes. Este servidor fornece uma API que permite aos atacantes encerrar processos arbitrários em qualquer pod do Kubernetes, potencialmente levando a uma negação de serviço em todo o cluster. A vulnerabilidade decorre da ausência de uma verificação de autenticação para uma função crítica dentro do Chaos Controller Manager.

Existe uma falha de injeção de comando na mutação `cleanTcs` do Chaos Mesh. Essa falha permite que atacantes não autenticados dentro do cluster realizem execução remota de código em todo o cluster. A vulnerabilidade está relacionada à injeção de comando do sistema operacional.

A API do servidor Weave permite que usuários remotos busquem arquivos de um diretório específico, mas, devido à falta de validação de entrada, é possível percorrer e vazar arquivos arbitrários remotamente. Em vários cenários comuns, isso permite que um usuário com privilégios limitados assuma o papel de administrador do servidor. A vulnerabilidade está sendo ativamente explorada.

O problema diz respeito aos documentos RAIL, um formato baseado em XML utilizado pelo Guardrails AI para aplicar verificações de formatação nas saídas de modelos de linguagem de grande escala (LLM). Usuários que utilizam documentos RAIL provenientes de fontes externas correm o risco de sofrer ataques de Entidade Externa XML (XXE), o que poderia levar ao vazamento de dados de arquivos internos por meio da entidade SYSTEM.

O problema está relacionado à injeção de comando ao importar um conjunto de dados remoto do Kaggle, devido à falta de sanitização de entradas na API `ingest kaggle()`. Isso permite possíveis ataques de injeção de comando. O endpoint da API `ingest kaggle()` está vulnerável devido à validação insuficiente das entradas.

A biblioteca Vanna está sujeita a uma vulnerabilidade de execução remota de código devido à injeção de prompt. Isso permite que um invasor altere a função de prompt usada para resultados visualizados e execute código Python arbitrário. A vulnerabilidade surge quando é permitida a entrada externa no método `ask` da biblioteca com `visualize` definido como True, que é o comportamento padrão. Esta vulnerabilidade já teria sido explorada na prática.

A vulnerabilidade permite que um usuário se registre em um servidor vector-admin enquanto a “restrição de domínio” estiver ativa, mesmo que não possua um endereço de e-mail autorizado. Trata-se de uma falha de autenticação no vector-admin.

Design document functions that receive a user HTTP request object may expose authorization or session cookie headers of the user who accesses the document. These design document functions include `list`, `show`, `rewrite`, and `update`. An attacker can leak the session component using an HTML-like output, insert the session as an external resource, or store the credential in a local document with an `update` function. For the attack to succeed, the attacker must be able to insert the design documents into the database and then manipulate a user to access a function from that design document.