Base de CVEs

Insecure deserialization of untrusted input in StellarGroup HPX 1.11.0 under certain conditions may allow attackers to execute arbitrary code or other unspecified impacts.

A correção para CVE-2024-52046 em AbstractIoBuffer.getObject() do Apache MINA foi incompleta. A lista de permissões de nomes de classes permitidas para desserialização foi aplicada tarde demais, depois que um inicializador estático de uma classe a ser lida poderia já ter sido executado. As versões afetadas são Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10 e 2.2.0 <= 2.2.5. O problema é resolvido no Apache MINA 2.0.28, 2.1.11 e 2.2.6 ao aplicar a lista de permissões de nomes de classes mais cedo. São afetadas as aplicações que usam Apache MINA e chamam IoBuffer.getObject(). As aplicações que usam Apache MINA são aconselhadas a atualizar

O componente Camel-Mail é vulnerável a injeção de cabeçalhos de mensagens do Camel. A estratégia de filtro de cabeçalhos personalizada usada pelo componente (MailHeaderFilterStrategy) filtra apenas a direção 'out' por meio de setOutFilterStartsWith, mas não configura a direção 'in' por meio de setInFilterStartsWith. Como resultado, quando uma aplicação Camel consome e-mails por meio do camel-mail (por exemplo, via from("imap://...") ou from("pop3://...")), a verificação do filtro de entrada é ignorada e cabeçalhos MIME com prefixo Camel são mapeados sem filtro para o Exchange. Um invasor que consiga entregar um e-mail a uma caixa postal monitorada por esse consumidor pode injetar cabeçalhos específicos do Camel que, para alguns componentes do Camel posteriores ao consumidor de e-mail (como camel-bean, camel-exec ou camel-sql), podem alterar o comportamento da rota. Este é o mesmo padrão tratado anteriormente no camel-undertow (CVE-2025-30177) e no filtro mais amplo de cabeçalhos de entrada (CVE-2025-27636 e CVE-2025-29891). Este problema afeta o Apache Camel: a partir de 3.0.0 e antes de 4.14.6, a partir de 4.15.0 e antes de 4.18.1. Recomenda-se que os usuários atualizem para a versão 4.19.0, que corrige o problema. Se os usuários estiverem na linha de releases LTS 4.18.x, sugere-se atualizar para 4.18.1. Se estiverem na linha de releases LTS 4.14.x, sugere-se atualizar para 4.14.6.

A função resolveClass() de AbstractIoBuffer do Apache MINA contém dois ramos; um deles (para classes estáticas ou tipos primitivos) não verifica a classe, contornando a lista de permissão de nomes de classe e permitindo a execução de código arbitrário. A correção verifica se a classe está presente no filtro de classes aceitas antes de chamar Class.forName(). São afetadas as versões Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10 e 2.2.0 <= 2.2.5. O problema foi resolvido no Apache MINA 2.0.28, 2.1.11 e 2.2.6 ao aplicar a lista de permissão de nomes de classe mais cedo. São afetadas as aplicações que usam o Apache MINA e chamam IoBuffer.getObject(). Recomenda-se que as aplicações que usam o Apache MINA sejam atualizadas.

JmsBinding.extractBodyFromJms() no camel-jms, e a classe JmsBinding equivalente no camel-sjms, desserializavam o conteúdo de valores ObjectMessage JMS recebidos por meio de javax.jms.ObjectMessage.getObject() sem aplicar qualquer ObjectInputFilter, lista de classes permitidas ou lista de classes bloqueadas. Como esse caminho de código é alcançado sempre que a opção mapJmsMessage está habilitada (o padrão) e o Camel atua como consumidor JMS, um atacante capaz de publicar um ObjectMessage elaborado em uma fila ou tópico consumido por uma aplicação Camel poderia alcançar execução remota de código quando uma cadeia de gadgets de desserialização estivesse presente no classpath. O mesmo tratamento era alcançado de forma transitiva pelo camel-sjms2 (cujo Sjms2Endpoint estende SjmsEndpoint) e pelo camel-amqp (cujo AMQPJmsBinding estende JmsBinding), e por outros componentes da família JMS baseados em JmsComponent, como camel-activemq e camel-activemq6. Este problema afeta o Apache Camel: de 3.0.0 antes de 4.14.7, de 4.15.0 antes de 4.18.2, de 4.19.0 antes de 4.20.0. Recomenda-se que os usuários atualizem para a versão 4.20.0, que corrige o problema. Se os usuários estiverem na série de lançamentos LTS 4.14.x, sugere-se atualizar para 4.14.7. Se estiverem na série de lançamentos 4.18.x, sugere-se atualizar para 4.18.2.

Deserialization of untrusted data in Microsoft Bing allows an unauthorized attacker to execute code over a network.

KTransformers até 0.5.3 contém uma vulnerabilidade de desserialização insegura no modo de backend balance_serve, em que o servidor RPC do escalonador vincula um socket ZMQ ROUTER a todas as interfaces, sem autenticação, e desserializa mensagens recebidas usando pickle.loads() sem validação. Atacantes podem enviar um payload pickle criado para o socket ZMQ exposto e executar código arbitrário no servidor com os privilégios do processo ktransformers.

O LeRobot até 0.5.1 contém uma vulnerabilidade de desserialização insegura no pipeline de inferência assíncrona, em que pickle.loads() é usado para desserializar dados recebidos por canais gRPC não autenticados e sem TLS nos componentes do servidor de políticas e do cliente de robô. Um atacante não autenticado e com alcance pela rede pode obter execução arbitrária de código no servidor ou no cliente ao enviar uma carga útil pickle forjada pelas chamadas gRPC SendPolicyInstructions, SendObservations ou GetActions.

Pipecat is an open-source Python framework for building real-time voice and multimodal conversational agents. Versions 0.0.41 through 0.0.93 have a vulnerability in `LivekitFrameSerializer` – an optional, non-default, undocumented frame serializer class (now deprecated) intended for LiveKit integration. The class's `deserialize()` method uses Python's `pickle.loads()` on data received from WebSocket clients without any validation or sanitization. This means that a malicious WebSocket client can send a crafted pickle payload to execute arbitrary code on the Pipecat server. The vulnerable code resides in `src/pipecat/serializers/livekit.py` (around line 73), where untrusted WebSocket message data is passed directly into `pickle.loads()` for deserialization. If a Pipecat server is configured to use LivekitFrameSerializer and is listening on an external interface (e.g. 0.0.0.0), an attacker on the network (or the internet, if the service is exposed) could achieve remote code execution (RCE) on the server by sending a malicious pickle payload. Version 0.0.94 contains a fix. Users of Pipecat should avoid or replace unsafe deserialization and improve network security configuration. The best mitigation is to stop using the vulnerable LivekitFrameSerializer altogether. Those who require LiveKit functionality should upgrade to the latest Pipecat version and switch to the recommended `LiveKitTransport` or another secure method provided by the framework. Additionally, always follow secure coding practices: never trust client-supplied data, and avoid Python pickle (or similar unsafe deserialization) in network-facing components.

Nas versões 2024.4.1114 até 2026.1.421 do Progress® Telerik® UI for AJAX, o controle RadFilter é vulnerável a desserialização insegura ao restaurar o estado do filtro quando esse estado é exposto ao cliente. Se um atacante adulterar esse estado, é possível a execução remota de código no lado do servidor.

The .NET Remoting framework used by OpenText Fax (RightFax) includes known security vulnerabilities that could be exploited if the service is exposed in environments where the remoting ports are accessible.