Eqstlab

A função `grep()` exportada por @augment-vir/node insere padrões de pesquisa controlados pelo usuário em uma string de comando de shell com aspas duplas sem sanitização. Quando esse comando é passado para a função `spawn()` com o shell definido como 'bash', o shell avalia expressões de substituição de comando incorporadas no padrão. Isso permite a execução arbitrária de comandos do sistema operacional com os privilégios do usuário do processo Node.js. Aplicações que passam entradas não confiáveis para os campos `pattern` ou `patterns` da função `grep()` estão suscetíveis à execução de código local ou remota não autenticada.

O endpoint não autenticado POST '/ nuxt content/:collection/query' aceita um campo `sql` controlado por um invasor em 'src/runtime/api/query.post.ts' que permite expressões SQLite onerosas. Embora algumas versões utilizem a função `assertSafeQuery()` em 'src/runtime/internal/security.ts' para rejeitar certas palavras-chave SQL em cláusulas WHERE, ela ainda permite chamadas de função como `randomblob()`, `zeroblob()`, `hex()` e `length()`. Essas consultas atingem o sumidouro síncrono better-sqlite3 em 'src/runtime/internal/database.server.ts', permitindo que uma única requisição remota consuma CPU e memória substanciais, bloqueando o loop de eventos do Node.js e todo o processamento de requisições simultâneas. Implantações totalmente estáticas e pré-renderizadas que não expõem o endpoint do servidor não são afetadas.

Quando o `KROKI SAFE MODE` está ativado, a proteção do backend TikZ bloqueia apenas o `verbatiminput`, mantendo ativos os primitivos nativos de leitura de arquivos TeX, como `openin`, `read`, `input` e `include`. Devido à configuração permissiva `openin any` no TeX Live, um agente não autenticado pode enviar LaTeX manipulado para o endpoint 'POST /tikz/svg' ou para a API genérica de diagramas. Isso permite que o renderizador leia qualquer arquivo acessível ao usuário do contêiner Kroki, incluindo segredos, dados de configuração, credenciais, chaves privadas ou dados de ambiente de processo, e renderize o conteúdo no SVG resultante. A opção `-no-shell-escape` não restringe essas operações de arquivo nativas.

A função `MCPToolsRegistry.read file()` em `codebase rag/mcp/tools.py` não resolve nem verifica adequadamente a contenção da variável `file path` quando os parâmetros `offset` ou `limit` acionam o ramo paginado. Isso permite que um invasor utilize caminhos absolutos ou travessia relativa para ignorar a validação `validate project path` e acessar arquivos fora da raiz do projeto pretendida. Um chamador não autenticado via servidor HTTP MCP exposto à rede ou um chamador local via transporte stdio pode ler arquivos arbitrários legíveis em UTF-8 acessíveis ao processo do servidor, como chaves privadas, credenciais e arquivos de configuração.

A função `readPsd()` aceita um `totalMemoryLimit` para a análise de arquivos, mas a função `decodeLayerImageData` espera uma propriedade chamada `memoryLimit`. Essa discrepância faz com que um limite indefinido seja passado para `createImageDataBitDepth()`, permitindo que um invasor utilize dimensões de camada controladas para disparar alocações de memória que excedem o limite configurado, resultando em exaustão de memória do processo e negação de serviço. Além disso, a função `inflateSync(compressed)` descompacta dados de canal codificados em ZIP sem um limite de tamanho de saída, o que também pode resultar em negação de serviço por meio de descompactação ilimitada.

Um invasor de rede não autenticado pode criar a primeira conta de administrador antes que o proprietário legítimo complete a configuração inicial. A função `initial setup()` verifica apenas a flag de conclusão `is setup` e não exige autenticação, token de bootstrap ou restrições de rede. O endpoint 'POST /api/auth/setup' em `src/api/routers/auth.py` invoca `create auth user()` com `UserRole.ADMIN` e `set auth cookie()`, emitindo um cookie JWT `fctr session` válido. Como a aplicação inicia o listener em 0.0.0.0 e publica a porta 8001 em todas as interfaces, clientes HTTP que não sejam navegadores podem ignorar as regras de CORS exclusivas para localhost. Um invasor que explore isso pode se tornar o único administrador, impedindo a configuração legítima e obtendo a capacidade de ler dados de usuários sincronizados com o Okta, tokens de API, histórico de chat e configuração do aplicativo, além de modificar usuários e credenciais de integração do Okta.

Usuários autenticados com um cookie `fctr session` válido podem executar código Python arbitrário sem privilégios de administrador. Ao enviar uma solicitação para o endpoint 'POST /api/react/execute-script' usando o parâmetro `script code`, um invasor pode ignorar a filtragem de conteúdo baseada em IA e a validação de segurança. O processo de validação em `validate generated code()` não lida adequadamente com alvos `ast.Call` e permite `getattr` via `ALLOWED BUILTINS`, permitindo que cadeias de chamadas dinâmicas através de ` builtins ` evitem a detecção. O código é gravado no disco por ` write temp script()` e executado como usuário root via `asyncio.create subprocess exec()`. Os resultados da execução são retornados através do endpoint 'GET /api/react/stream-react-updates?process id=<id>'. Isso pode levar ao comprometimento total do container, divulgação de tokens de API do Okta e chaves JWT, exposição do banco de dados SQLite e pivoteamento não autorizado em serviços de backend.

O pacote server-renderer do ServerRendererServer aceita requisições HTTP/2 não autenticadas e resolve valores `:path` controlados por atacantes em relação ao `server.targetOrigin` na função `onIncomingRequest()`. Como o sistema não confirma se a origem resolvida permanece confiável antes de chamar o fetch, um caminho relativo ao protocolo pode alterar o destino para qualquer endpoint HTTP ou HTTPS arbitrário acessível pelo servidor, incluindo serviços locais e internos. O proxy então retransmite os cabeçalhos e o corpo da resposta obtida para o requerente.

A função padrão `JWTBearerGrant.get audiences()` retorna uma lista vazia, o que faz com que a `JWTBearerGrant.verify claims()` exija apenas que uma reivindicação `aud` exista, sem verificar se ela corresponde ao servidor de autorização atual. Isso permite que um invasor com uma asserção legítima para outro serviço a apresente a um servidor que compartilhe a mesma chave de assinatura e use a concessão padrão, obtendo um token de acesso através de um limite de confiança.

A função `buildWSLegacyExecutor()` no módulo executor-legacy-ws desativa a rejeição de certificados TLS por padrão para conexões Node.js em endpoints wss://. Isso permite que aplicações que utilizam o executor diretamente, ou o url-loader com `SubscriptionProtocol.LEGACY WS`, aceitem certificados controlados por um invasor durante uma interceptação de rede. Isso pode resultar na exposição de materiais de autenticação em `connectionParams` ou cabeçalhos, além da modificação de dados de assinatura. Clientes WebSocket de navegadores não são afetados, pois os navegadores impõem a validação de certificados.

A biblioteca falha ao validar o campo `tokenUrl` em especificações OpenAPI remotas. Isso permite que um invasor redirecione o envio de credenciais para endpoints arbitrários. Se um usuário registrar uma especificação OpenAPI controlada por um invasor e invocar uma ferramenta protegida por OAuth2 gerada, a biblioteca envia o `client id` e o `client secret` via requisição POST para o endpoint de token fornecido pelo invasor.

O software não verifica se as URLs de ferramentas declaradas em um manual UTCP escrito à mão apontam para a interface de loopback do próprio agente quando esse manual é descoberto a partir de uma origem remota, que não seja de loopback. Isso ocorre porque a função `ensure secure url` permite HTTP de loopback para desenvolvimento local, e manuais nativos ignoravam a verificação de loopback realizada pelo conversor OpenAPI. Um invasor que forneça um manual UTCP malicioso pode causar a falsificação de solicitação do lado do servidor (SSRF), fazendo com que o cliente envie solicitações a serviços vinculados apenas ao 127.0.0.1 no host da vítima e retorne os corpos das respostas ao invasor. Este problema afeta os protocolos http, sse e streamable http. A exploração requer um serviço de loopback que responda a solicitações não autenticadas.

Um problema de exfiltração de arquivos do servidor não autenticado ocorre quando o servidor é implantado usando transporte HTTP (como `streamable-http` ou `sse`) e o `READ ONLY MODE` está definido como `false`. Um invasor remoto pode ignorar a autenticação fornecendo cabeçalhos de serviço específicos, como `X-Atlassian-Confluence-Url` e `X-Atlassian-Confluence-Personal-Token`, para redirecionar as solicitações para um nome de host controlado pelo invasor. Ao invocar a função `confluence upload attachment` ou sua variante do Jira em `src/mcp atlassian/jira/attachments.py` com uma variável `file path` local do servidor, o invasor pode forçar o processo MCP a ler e enviar qualquer arquivo acessível pelo processo do servidor para o endpoint externo. Isso ocorre porque a funcionalidade de upload carece de validação de caminho, não utilizando a função `validate safe path()` para restringir o acesso ao diretório.

Ao ser executado com `OBOT SERVER ENABLE AUTHENTICATION=true`, o software expõe o registro dinâmico de clientes OAuth sem autenticação e sem restrições nos URIs de redirecionamento. Isso permite que um invasor não autenticado registre um cliente apontando para um domínio externo. Como o fluxo de autorização é concluído automaticamente para usuários logados sem uma tela de consentimento, um invasor pode induzir uma vítima a visitar uma URL de autorização manipulada para receber um código de autorização no URI de redirecionamento controlado pelo invasor, que é então trocado por um token de acesso e um token de atualização. O token emitido pelo fluxo OAuth do MCP inclui o conjunto completo de grupos da vítima no JWT (JSON Web Token), um formato para transmissão segura de informações. Como o sistema valida o emissor, mas não a audiência, o token é aceito como um token portador em qualquer endpoint da API do Obot que a vítima possa acessar, em vez de ser limitado ao servidor MCP solicitado. Isso permite que o invasor leia ou modifique os recursos da vítima até que o token seja revogado.

A falta de autorização na API de Licença Local permite que usuários autenticados com baixos privilégios leiam, sobrescrevam e excluam chaves de licença de módulos premium. Isso é possível através dos seguintes endpoints de API: - 'GET /api/admin/licenses/show' - 'POST /api/admin/licenses/store' - 'POST /api/admin/licenses/remove'

Uma falha de design em `src/module.ts` faz com que o módulo mescle incondicionalmente todas as opções, incluindo a `api key`, na configuração de tempo de execução pública `runtimeConfig.public.ollama`. Como o Nuxt serializa esta configuração pública no payload HTML renderizado pelo servidor `window. NUXT `, a chave de API é exposta em texto simples para qualquer cliente não autenticado que acesse a página. Além disso, o composable do lado do navegador `src/runtime/composables/useOllama.ts` lê esta chave pública e a inclui como uma credencial `Authorization` `Bearer` em requisições do lado do cliente. Um invasor pode roubar esta chave com uma única requisição HTTP GET, podendo levar ao uso não autorizado da API na nuvem às custas do operador, exaustão de cotas ou acesso a modelos e conversas armazenadas.

A ferramenta MCP `set functype version` no `functype-mcp-server` permite a Execução Remota de Código (RCE) porque aceita uma string `version` sem restrições e a interpola em um comando `pnpm add`. Um invasor pode usar sintaxes de alias de pacote, como `file:`, `npm:`, URLs ou caminhos, para forçar a instalação de um pacote local ou remoto arbitrário. Após a instalação, a função `initDocsData()` resolve e importa dinamicamente o módulo `functype/cli`, executando JavaScript controlado pelo invasor com os privilégios do processo do servidor MCP. Isso pode ser explorado por qualquer cliente MCP capaz de enviar uma requisição `tools/call`, ou via injeção indireta de prompt, onde um assistente de IA é induzido a invocar a ferramenta a partir de um documento ou página web maliciosa. Em implantações usando `TRANSPORT TYPE=httpStream`, o problema é acessível a invasores de rede. A exploração bem-sucedida permite que o invasor leia segredos do processo, modifique arquivos ou encerre o servidor.

Um problema de traversal de caminho não autenticado existe no `@openhop/server`, onde parâmetros de rota não sanitizados são passados para a função `FlowStore.filePath()` em `packages/server/src/store.ts`. A aplicação utiliza `path.join()` para construir caminhos de sistema de arquivos para arquivos YAML de fluxo, permitindo que um invasor use sequências de traversal para acessar arquivos fora do diretório de fluxo configurado. Isso afeta os seguintes endpoints: - `GET /api/flows/:id` - `DELETE /api/flows/:id` Um invasor pode explorar isso para ler qualquer arquivo `.yaml` acessível ao processo como JSON analisado em YAML ou excluir permanentemente qualquer arquivo `.yaml` alcançável pelo processo, potencialmente expondo segredos ou interrompendo serviços. O risco é amplificado porque o CORS está configurado com `origin: true`, permitindo que páginas web maliciosas ataquem instâncias locais, e as implantações Docker definem por padrão `HOST=0.0.0.0`, permitindo acesso direto à rede. A variável vulnerável é `id`.

Um invasor de rede não autenticado pode explorar um problema de traversal de caminho onde os caminhos de requisições HTTP proxyadas não são validados para dot-segments baseados em barra invertida antes de serem encaminhados para o servidor upstream. O manipulador de requisições HTTP simples ignora a validação de destino realizada pelos caminhos WebSocket, e a biblioteca `reply-from` subjacente rejeita apenas o traversal de barra normal. Isso permite que requisições contendo dot-segments de barra invertida escapem dos limites definidos pelas opções `prefix` e `rewritePrefix`, permitindo o acesso a caminhos internos do upstream e a divulgação de endpoints ocultos.

A verificação inadequada de assinaturas criptográficas permite que um invasor não autenticado se passe por qualquer usuário. O problema ocorre quando o software aceita um JSON Web Encryption (JWE) envolvendo reivindicações não assinadas como totalmente validadas, falhando em exigir uma assinatura aninhada conforme exigido pelo OpenID Connect Core 1.0 e pelas regras de processamento JARM. Isso permite que um invasor com a chave de criptografia pública da parte confiante crie tokens com valores arbitrários de `sub`, `iss` e `aud` sem a chave de assinatura do provedor. A falha reside na função `verify decrypted token/4` dentro de `oidcc jwt util`, onde payloads descriptografados que não são JWS assinados são analisados como reivindicações de texto simples. Subsequentemente, a função `int validate jwt/4` em `oidcc token` retorna sucesso com base no tipo de estrutura JOSE em vez da verificação da assinatura. Além disso, a função `validate jarm/3` em `oidcc token` é acessível através do canal frontal do navegador. Isso só é explorável se o Provedor OpenID anunciar a criptografia de token de ID ou de resposta de autorização e a parte confiante tiver uma chave de criptografia configurada.