Venkatraman Kumar

O componente `UrlImageConverter` está suscetível a Server-Side Request Forgery (SSRF) através de um bypass de DNS rebinding. Isso ocorre quando uma aplicação aceita uma URL de imagem controlada por um atacante para a escrita de planilhas; o conversor valida os endereços IP resolvidos do hostname, mas subsequentemente abre uma conexão separada que pode resolver o hostname novamente. Um atacante que controle as respostas de DNS pode redirecionar a conexão para um endereço restrito após a validação inicial.

Um usuário comum pode gerar tokens de acesso de administrador através do endpoint '/access-tokens'.

Uma divulgação REST não autenticada permite a exposição de certos itens de conteúdo dentro da aplicação.

Um locatário autenticado pode realizar Server-Side Request Forgery (SSRF) ao registrar um template que aponta para um arquivo metalink malicioso contendo alvos internos, permitindo que a VM de Armazenamento Secundário recupere e persista esses dados. Além disso, um locatário com a função de Usuário padrão pode obter Execução Remota de Código (RCE) como root no host do hipervisor KVM. Isso ocorre quando um usuário registra um template de VM com a variável `directDownload` definida como true e uma URL apontando para um arquivo .metalink; o servidor de gerenciamento busca o XML e despacha o download para o agente KVM sem revalidar as URLs internas contra a lista de permissões de esquema.

☕ Apache Camel critical alert: CVE-2026-43867 hits the camel-pqc component. Post-quantum key metadata deserialized via ObjectInputStream with zero ObjectInputFilter — unauthenticated RCE risk at CVSS 9.8. Check your Camel builds now. #AppSec #Apache https://t.co/iaMBNrOfI0 https://t.co/mkIJ19Sd5Y

Existe um problema onde o padrão ObjectInputFilter padrão usado para filtragem de desserialização em vários componentes permite classes que realizam E/S de rede, como `java.net.URL` e `java.net.InetAddress`. Um invasor pode enviar um payload serializado Java contendo um `HashMap` com chaves `java.net.URL` para um consumidor afetado. Isso faz com que a JVM emita consultas DNS para um host controlado pelo invasor durante a desserialização, criando um canal lateral out-of-band. O risco é mais significativo na família `camel-jms` porque a função `extractBodyFromJms()` em `JmsBinding` invoca `getObject()` incondicionalmente quando a variável `mapJmsMessage` está definida como true. Os componentes afetados incluem `camel-jms`, `camel-sjms`, `camel-amqp`, `camel-mina`, `camel-netty`, `camel-netty-http`, `camel-vertx-http`, `camel-infinispan` e os componentes de repositório de agregação `camel-leveldb`, `camel-cassandraql`, `camel-consul` e `camel-sql`.

O componente `camel-vertx-http` desserializa corpos de resposta HTTP com o Content-Type `application/x-java-serialized-object` usando um `java.io.ObjectInputStream` bruto sem um `ObjectInputFilter` na função `deserializeJavaObjectFromStream()`. Isso ocorre quando o endpoint do produtor é configurado com `transferException=true` (ou `allowJavaSerializedObject=true`) e `throwExceptionOnFailure` está definido como true. Nessas condições, uma resposta HTTP de backend com status 5xx e o tipo de conteúdo especificado é desserializada sem restrições de classe. Um invasor que controle o backend ou realize um ataque de man-in-the-middle em uma conexão HTTP não criptografada pode enviar um objeto Java serializado manipulado para alcançar a execução remota de código no host, desde que uma cadeia de gadgets adequada esteja presente no classpath.

As classes `EndpointReferenceUtils` e `W3CMultiSchemaFactory` constroem um `SAXParserFactory` sem as configurações de endurecimento JAXP necessárias. Isso permite a resolução de entidades externas out-of-band (OOB), um processo no qual um analisador XML é enganado para acessar recursos externos por meio de entidades externas.

A desserialização de dados não confiáveis no caminho de substituição de resolução (replace-resolve) do Java em plataformas Java/JVM permite que um invasor remoto ignore as verificações de registro de classe, TypeChecker e DisallowedList. Ao utilizar dados serializados do Fory manipulados, um invasor pode invocar os hooks `readResolve()` e `readExternal()` presentes no classpath.

A classe `FileBasedKeyLifecycleManager` no Camel-PQC realiza a desserialização insegura de dados não confiáveis. Ela desserializa o conteúdo de arquivos `<keyId>.key` no diretório de chaves configurado usando `java.io.ObjectInputStream` sem aplicar um `ObjectInputFilter` ou restrições de carregamento de classe. Como a conversão para `java.security.KeyPair` ocorre apenas após a função `readObject()` ter retornado, quaisquer efeitos colaterais no objeto desserializado são executados antes da verificação de tipo. Um invasor capaz de escrever no diretório de chaves—através de traversal de caminho, permissões de sistema de arquivos mal configuradas, um pipeline de provisionamento de chaves comprometido ou um ataque de symlink—pode inserir um objeto Java serializado especialmente criado para alcançar a execução de código arbitrário no contexto da aplicação.

A função `extractBodyFromJms()` no `camel-jms` e a classe `JmsBinding` no `camel-sjms` desserializam a carga útil de valores JMS ObjectMessage recebidos via `javax.jms.ObjectMessage.getObject()` sem aplicar qualquer ObjectInputFilter, lista de permissões (allowlist) ou lista de bloqueios (denylist) de classes. Isso ocorre sempre que a opção `mapJmsMessage` está habilitada e o Camel atua como um consumidor JMS. Um invasor capaz de publicar um ObjectMessage manipulado em uma fila ou tópico consumido por uma aplicação Camel pode alcançar a execução remota de código quando uma cadeia de gadgets de desserialização estiver presente no classpath. O mesmo problema afeta transitivamente o `camel-sjms2`, `camel-amqp`, `camel-activemq` e `camel-activemq6`.

Uma falha na função `resolveClass()` do `AbstractIoBuffer` permite ignorar a lista de permissões (allowlist) de nomes de classes para classes estáticas ou tipos primitivos. Isso ocorre porque um dos ramos de execução não valida a classe, permitindo a desserialização insegura quando as aplicações chamam `IoBuffer.getObject()`. Isso pode levar à execução remota de código.

Existe um problema na função `getObject()` da classe `AbstractIoBuffer` devido a um mecanismo de desserialização incompleto. A lista de permissões (allowlist) de nomes de classes, que restringe quais classes podem ser desserializadas, é aplicada tarde demais, permitindo potencialmente que um inicializador estático em uma classe seja executado antes que a verificação ocorra. Essa falha permite que um invasor remoto execute código arbitrário em aplicações que chamam a função `getObject()`.

Uma falha no componente camel-mina permite que um invasor remoto execute código arbitrário ao enviar um objeto Java serializado especialmente manipulado através da rede para a porta do consumidor MINA. O conversor de tipo `MinaConverter.toObjectInput()`, utilizado quando uma rota Camel processa a entrada de rede, não aplica os filtros de segurança ou restrições de carregamento de classe necessários durante a desserialização de objetos. Isso ocorre quando o conversor envolve um `IoBuffer` em um `java.io.ObjectInputStream` sem um `ObjectInputFilter`, permitindo a execução de código malicioso no contexto da aplicação durante o processo `readObject()`.