Kexinoh

Uma falha no `PdfParser` permite que um invasor forneça um PDF malicioso que faz com que o processo trave indefinidamente, consumindo 100% da CPU e tornando a aplicação responsiva. Isso ocorre porque o analisador segue ponteiros Prev em trailers de PDF para ler seções de referência cruzada; se um ponteiro referenciar um deslocamento já processado, seja apontando para si mesmo ou formando um ciclo, o analisador entra em um loop infinito.

Name of the Vulnerable Software and Affected Versions vLLM versões 0.5.5 até 0.17.999 Description vLLM, um motor de inferência e serviço para grandes modelos de linguagem (LLMs), apresenta uma inconsistência no processamento de áudio. As versões 0.5.5 até 0.17.999 utilizam numpy.mean para downmixing mono via Librosa, desviando-se do padrão de downmixing ponderado ITU-R BS.775-4. Essa discrepância causa diferenças na percepção de áudio entre ouvintes humanos e modelos de IA que processam áudio usando Librosa. Recommendations Atualize para a versão 0.18.0 ou posterior.

Langflow's Agentic Assistant feature, prior to version 1.9.0, executes LLM-generated Python code during validation. This implementation allows for arbitrary server-side Python execution if an attacker can access the Agentic Assistant feature and influence the model output. The vulnerable code path involves processing model output through a chain that ultimately invokes `create class()`, which dynamically executes Python code using `exec()`. The affected endpoints include `/api/v1/login` and the assistant feature relies on user authentication via bearer token, cookie, or API key. Default deployment settings, such as `AUTO LOGIN=true` and the `/api/v1/auto login` endpoint, may widen exposure. The issue is an authenticated code execution vulnerability, with severity depending on the deployment model.

The software contains a race condition in concurrent `updateRegistry` and `removeRegistryEntry` operations for sandbox containers and browsers. This occurs due to unsynchronized read-modify-write operations without locking, potentially leading to data loss, resurrection of removed entries, or corruption of sandbox state. This can affect `sandbox list`, `sandbox prune`, and `sandbox recreate --all` operations. The registry writes were read-modify-write in a window with no locking and permissive fallback parsing, allowing concurrent registry updates to produce stale snapshots and overwrite each other, desynchronizing sandbox state.

O OpenClaw é um assistente de IA pessoal. Antes da versão 2026.2.15, a função `normalizeForHash` em `src/agents/sandbox/config-hash.ts` ordenava recursivamente arrays contendo apenas valores primitivos. Isso fazia com que arrays de configuração do sandbox sensíveis à ordem gerassem o mesmo valor de hash mesmo quando a ordem era alterada. Nos fluxos de sandbox do OpenClaw, esse hash determinava se os contêineres de sandbox existentes eram recriados. Consequentemente, alterações na ordem dos arrays na configuração (por exemplo, a ordem dos arrays `dns` e `binds` do Docker) poderiam ser consideradas inalteradas, levando à reutilização de contêineres potencialmente obsoletos. Isso representa uma questão de integridade da configuração que afeta o comportamento de recriação do sandbox. A partir da versão 2026.2.15, a ordem dos arrays é preservada durante a normalização do hash, sendo apenas a ordem das chaves de objetos normalizada para garantir hashing determinístico.

O software utiliza SHA-1 para gerar hashes de chaves de cache de identificadores de sandbox para configurações de sandbox do Docker e do navegador. O SHA-1 é uma função de hash criptográfica obsoleta com fraquezas de colisão conhecidas. Uma colisão nesse hash poderia permitir que um atacante cause envenenamento de cache, possivelmente levando à reutilização insegura do estado do sandbox. O software utiliza IDs determinísticos para determinar se um container de sandbox existente pode ser reutilizado com segurança. Explorar essa vulnerabilidade poderia permitir que uma configuração fosse interpretada erroneamente como outra sob a mesma identidade de cache do sandbox. A implementação foi atualizada para usar SHA-256 para esses hashes, restaurando a resistência a colisões.

O LLaMA-Factory, uma biblioteca de ajuste para grandes modelos de linguagem, contém uma vulnerabilidade de Falsificação de Solicitação no Lado do Servidor (SSRF) na API de chat. Usuários autenticados podem fazer o servidor enviar solicitações HTTP arbitrárias para redes internas e externas, potencialmente expondo serviços internos sensíveis, permitindo reconhecimento de rede ou interagindo com serviços de terceiros. Também existe uma vulnerabilidade de Inclusão de Arquivo Local (LFI), permitindo que usuários leiam arquivos arbitrários do sistema de arquivos do servidor. A falha reside na função ` process request` dentro de `src/llamafactory/api/chat.py`. Esta função processa conteúdo multimodal de URLs e, se a URL não for um URI de dados base64 ou um caminho de arquivo local, ela faz uma solicitação HTTP GET usando `requests.get(url, stream=True).raw` sem validar ou sanitizar a URL.

Existe uma vulnerabilidade no huggingface LeRobot até a versão 0.3.3 relacionada à ausência de autenticação na funcionalidade ZeroMQ Socket Handler do arquivo `lerobot/common/robot devices/robots/lekiwi remote.py`. O ataque só pode ser iniciado na rede local. O fornecedor foi contatado, mas não respondeu.

Existe uma vulnerabilidade devido ao uso de chaves criptográficas hard-coded. O problema está localizado em uma função desconhecida dentro do arquivo `backend/domain/plugin/encrypt/aes.go`. A manipulação dos argumentos `AuthSecretKey`, `StateSecretKey` e `OAuthTokenSecretKey` pode desencadear este problema. O ataque pode ser iniciado remotamente e é considerado difícil de explorar.

Existem múltiplos problemas de negação de serviço por expressão regular (ReDoS) onde vários padrões de regex estão suscetíveis ao backtracking catastrófico—uma condição em que uma regex complexa leva um tempo exponencial para processar certas entradas. Isso pode ser desencadeado por um invasor que envie entradas manipuladas com estruturas aninhadas ou repetidas, resultando em consumo severo de CPU e degradação de desempenho. Os componentes afetados incluem o endpoint de chat de serviço compatível com OpenAI, o parser de ferramentas phi4mini e o arquivo `vllm/lora/utils.py`.

Uma vulnerabilidade de Negação de Serviço por Expressão Regular (ReDoS) existe no projeto vLLM, especificamente no arquivo `vllm/entrypoints/openai/tool parsers/pythonic tool parser.py`. A causa raiz é o uso de uma expressão regular altamente complexa e aninhada para detecção de chamada de ferramenta, que pode ser explorada por um atacante para causar degradação severa de desempenho ou tornar o serviço indisponível. O padrão contém múltiplos quantificadores aninhados, grupos opcionais e repetições internas, tornando-o vulnerável a backtracking catastrófico. Isso pode levar à Negação de Serviço (DoS), esgotamento de recursos e potencial instabilidade mais ampla do sistema.

O problema refere-se a uma vulnerabilidade crítica de desempenho na lógica de pré-processamento de entrada do tokenizador multimodal. Ela é causada por operações ineficientes de concatenação de listas, resultando em complexidade de tempo quadrática (O(n²)), o que permite a agentes maliciosos provocar exaustão de recursos por meio de entradas especialmente elaboradas.

O problema afeta o vLLM, um mecanismo de inferência e serving para LLMs de alta vazão e eficiente em memória. Em uma implantação do vLLM em múltiplos nós, o vLLM utiliza ZeroMQ para alguns fins de comunicação entre nós, abrindo um socket XPUB ZeroMQ e vinculando-o a todas as interfaces. Isso permite que qualquer cliente com acesso à rede se conecte ao socket, a menos que sua porta seja bloqueada por um firewall, e receba informações internas do estado do vLLM. Embora esses dados não sejam úteis para um atacante, conectar-se ao socket várias vezes sem ler os dados publicados pode causar uma negação de serviço, desacelerando ou potencialmente bloqueando o publicador.

O problema envolve uma questão de segurança e integridade de dados no método de hash de imagens da classe MultiModalHasher. Especificamente, o método serializa objetos PIL.Image.Image usando apenas obj.tobytes(), o que retorna os dados brutos de pixel sem incluir metadados como as dimensões da imagem. Isso pode levar a colisões de hash, acertos de cache incorretos e potencial vazamento de dados ou riscos de segurança. O problema surge porque duas imagens com a mesma sequência de bytes de pixel, mas tamanhos diferentes, podem gerar o mesmo valor de hash.

O vLLM é um mecanismo de inferência e serving para LLMs de alta vazão e eficiente em memória. A questão envolve o uso de serialização baseada em pickle sobre sockets ZeroMQ não seguros quando o vLLM está integrado com o mooncake, resultando em execução remota de código. Os sockets vulneráveis foram configurados para escutar em todas as interfaces de rede, aumentando a probabilidade de um ataque. Instâncias do vLLM sem integração com o mooncake não são vulneráveis. Esta questão foi corrigida na versão 0.8.5.

Uma vulnerabilidade foi identificada no componente Prefix Caching, especificamente no arquivo `pkg/plugins/gateway/prefixcacheindexer/hash.go`. Este problema resulta em valores insuficientemente aleatórios. A complexidade de um ataque é bastante alta e a exploração parece ser difícil.

Instruções construídas maliciosamente podem levar a colisões de hash, resultando em reutilização de cache, o que pode interferir nas respostas subsequentes e causar comportamento não intencional. O problema surge do uso da função `hash()` integrada do Python, que, a partir do Python 3.12, retorna um valor constante previsível para `hash(None)`. Isso torna mais viável para alguém explorar colisões de hash. Dado o conhecimento dos prompts em uso e do comportamento de hash previsível, alguém poderia intencionalmente popular o cache usando um prompt conhecido por colidir com outro prompt em uso. O impacto de uma colisão seria o uso de cache que foi gerado usando conteúdo diferente.

O problema diz respeito ao uso do MD5, um algoritmo de hash criptograficamente comprometido, para hashar senhas antes de enviá-las ao backend. Isso torna o sistema vulnerável a ataques de colisão e pode ser facilmente quebrado usando hardware moderno, expondo as credenciais do usuário a um potencial comprometimento. O free-one-api permite que os usuários acessem bibliotecas de engenharia reversa de modelos de linguagem de grande porte por meio do formato padrão da API da OpenAI.

O problema diz respeito ao uso do MD5 como algoritmo de hash no beego, o qual não é mais considerado seguro devido à sua vulnerabilidade a ataques de colisão. Essa vulnerabilidade pode levar a riscos à integridade dos dados, vulnerabilidades de segurança e comportamento imprevisível em sistemas de cache. Uma colisão no hash ocorre quando duas entradas diferentes produzem o mesmo resultado de hash, permitindo que invasores possam explorar colisões e manipular dados do cache.

O algoritmo utilizado para analisar cookies HTTP no Tornado apresenta, em alguns casos, complexidade quadrática, levando a um consumo excessivo de CPU ao analisar cabeçalhos de cookies criados com intenção maliciosa. Essa análise ocorre na thread do loop de eventos e pode bloquear o processamento de outras solicitações, permitindo potencialmente que um invasor remoto provoque uma negação de serviço.