Waydeshi

Existe um problema onde `JSONTokener.nextSimpleValue` pode acumular tokens numéricos ilimitados antes que `JSONObject.stringToNumber` os passe para a conversão BigInteger ou BigDecimal sem um limite de comprimento. Aplicações que processam JSON ou XML controlados por atacantes através de `JSONObject`, `JSONArray` ou `XML.toJSONObject` podem consumir tempo de CPU superlinear ao converter literais numéricos excessivamente longos. Isso pode bloquear as threads de processamento de requisições e causar a negação de serviço. Este comportamento persiste independentemente das configurações de modo estrito e keep-strings no `JSONParserConfiguration`.

Um vazamento de referência ocorre na extensão C da estrutura de dados multidict. O problema acontece durante a operação de união refletida de items-view, `operand | d.items()`, na função `multidict itemsview or2 impl`, e na operação de subtração, `d.items() - operand`, na função `multidict itemsview sub1 impl`. Essas operações falham ao liberar novas referências de identidade de chave e valor para cada elemento do operando. Se uma aplicação realizar essas operações usando sequências influenciadas por um invasor, isso pode levar ao vazamento de duas referências fortes por elemento. Como a coleta de lixo (garbage collection) não consegue recuperar essas referências, operações repetidas podem resultar no crescimento ilimitado da memória do processo, levando a uma negação de serviço. Builds puramente em Python, união direta, interseção e elementos de operando que não sejam tuplas não são afetados.

As funções `isInSubnet()` e `isHostInSubnet()` em `src/common.ts` comparam strings binárias mascaradas sem verificar se ambos os operandos pertencem à mesma família de IP. Isso permite que uma verificação de contenção entre famílias diferentes retorne uma correspondência se os bits iniciais do endereço forem idênticos, apesar de IPv4 e IPv6 ocuparem espaços de endereçamento distintos. Consequentemente, uma lista de permissões (allowlist) ou de bloqueio (denylist) pode classificar incorretamente um endereço como estando dentro da faixa pretendida.

O construtor `Address6`, a função `Address6.isValid` e o código `parse` em `src/ipv6.ts` aceitam strings sem limite de tamanho. Quando caracteres inválidos são processados através de `RE BAD CHARACTERS`, eles são expandidos em diagnósticos extensos. Isso pode resultar em uma interrupção síncrona e alto uso transitório de memória ao processar campos em escala de megabytes. Especificamente, campos de aproximadamente 16 MiB podem disparar uma exceção de comprimento de string inválido, e campos de aproximadamente 32 MiB podem causar a terminação do processo. Isso ocorre quando uma aplicação passa um campo controlado por um invasor, com tamanho excessivo, para a lógica de parsing sem um limite de comprimento prévio.

Um problema ocorre ao vincular uma string JSON a um campo `javax.xml.datatype.Duration` ou `javax.xml.datatype.XMLGregorianCalendar` através da função `CoreXMLDeserializers.Std. deserialize`. O software passa a string bruta diretamente para `DatatypeFactory.newDuration(value)` ou `newXMLGregorianCalendar(value)`. Como a gramática lexical do XML Schema permite componentes numéricos de comprimento arbitrário, o JDK utiliza os construtores `BigInteger(String)` e `BigDecimal(String)`, que possuem complexidade quadrática em relação à contagem de dígitos. Como a entrada é tratada como uma string JSON em vez de um número JSON, a proteção `StreamReadConstraints.maxNumberLength` é ignorada e o desserializador de tipo de dado XML não realiza a validação de comprimento. Um invasor não autenticado pode enviar uma requisição contendo uma string com vários milhões de dígitos, causando consumo excessivo de CPU e potencialmente saturando as threads de processamento do servidor.

Os controladores de prompt e recurso integrados não realizam a verificação de funções. Os endpoints 'POST /api/prompts*' e 'PUT /api/prompts*', bem como 'POST /api/resources*' e 'PUT /api/resources*', estão acessíveis a usuários autenticados sem privilégios administrativos, pois os manipuladores não verificam a variável `req.user`. Como os singletons DAO têm prioridade sobre os servidores MCP conectados nas funções `handleGetPromptRequest()` e `handleReadResourceRequest()`, um usuário não administrador pode criar, sobrescrever ou mascarar modelos de prompt e recursos globais. Isso acarreta uma violação de integridade não autorizada e pode resultar em injeção de prompt armazenada nas sessões de LLM de outros usuários.

O endpoint PUT '/api/system-config' (handler `updateSystemConfig`) não realiza verificação de autorização. Embora o endpoint seja protegido por um middleware de autenticação e um limitador de taxa, ele falha ao verificar se o usuário possui privilégios administrativos, pois não inspeciona a variável `req.user.isAdmin`.

A função `qs.stringify` pode lançar um `TypeError` ao serializar um objeto que contenha uma propriedade `constructor` com um membro `isBuffer` verdadeiro, porém não chamável. Isso ocorre porque a função `utils.isBuffer()` realiza duck-typing ao invocar `obj.constructor.isBuffer(obj)` sem verificar previamente se `isBuffer` é realmente uma função. Um invasor pode disparar isso fornecendo entradas especialmente manipuladas via `qs.parse` (usando `plainObjects: true` ou `allowPrototypes: true`) ou através de `JSON.parse`. Em ambientes como Express 4 ou body-parser com `extended: true`, tais entradas podem ser passadas diretamente via `req.query` ou `req.body`. Isso pode levar a uma negação de serviço onde a requisição afetada retorna um erro 500 ou, em casos onde a chamada ocorre fora de um limite de erro (como em um manipulador `async`), pode causar a interrupção de todo o processo.

O desserializador para java.nio.file.Path resolve um URI fornecido por um invasor sem restringir o esquema do URI. Na função `JDKFromStringDeserializer.NioPathHelper.deserialize`, uma string proveniente de um JSON não confiável é passada para `new URI(value)` e depois para `Path.of(uri)`. Quando ocorre uma `FileSystemNotFoundException`, o código enumera `ServiceLoader<FileSystemProvider>` e chama `provider.getPath(uri)` no primeiro provedor cujo esquema corresponda ao escolhido pelo invasor. Isso permite que um JSON não confiável selecione e controle um `FileSystemProvider` registrado arbitrário durante o `readValue` sob um `JsonMapper` padrão, forçando o carregamento da classe do provedor. Embora o caminho resolvido seja inerte apenas com os provedores integrados do JDK (file, jar/zipfs), impactos adicionais são possíveis se um `FileSystemProvider` de terceiros com efeitos colaterais estiver presente no classpath.