Andrea Cosentino

Uma falha de Server-Side Request Forgery (SSRF) no componente A2A do Apache Camel ocorre porque o `WebhookUrlValidator` classificava hosts de webhook de notificação push de forma inconsistente. Hosts fornecidos como literais de IP eram verificados contra uma lista de prefixos para a faixa local única IPv6 fc00::/7, enquanto hosts fornecidos como nomes eram resolvidos e verificados usando predicados `InetAddress`. Como esses predicados não cobriam a faixa fc00::/7, uma URL de webhook que resolvesse para essa faixa poderia burlar as proteções. Isso permite que um invasor controle a variável `TaskPushNotificationConfig.url` para disparar requisições HTTPS externas cegas do processo Camel para endereços internos, potencialmente incluindo cabeçalhos de Autorização. Além disso, a pré-verificação bloqueava incorretamente qualquer nome de host começando com fc ou fd, como fcm.googleapis.com, independentemente de serem literais de IP.

O componente OAuth apresenta um problema onde o `OAuthClientCredentialsTokenResolver` armazena tokens portadores OAuth 2.0 em um cache estático compartilhado por todas as instâncias do resolver e `CamelContext` na JVM. O cache é indexado apenas pelo endpoint do token e pelo ID do cliente, ignorando o segredo do cliente e o escopo solicitado. Consequentemente, se vários perfis compartilharem o mesmo endpoint de token e ID de cliente, mas utilizarem escopos ou segredos diferentes, eles podem receber um token destinado a outro perfil. Isso pode resultar em solicitações externas transportando tokens com autoridade maior do que a pretendida ou tokens destinados a um serviço diferente. Um serviço comprometido ou hostil que receba tal token poderá, potencialmente, reproduzi-lo dentro de seu escopo.

A restrição inadequada de referências a Entidades Externas XML (XXE) no componente Saxon do Apache Camel ocorre porque o `XQueryBuilder` no `camel-saxon` utiliza uma Configuração Saxon padrão que aceita declarações DOCTYPE e resolve entidades externas. Embora os conversores de tipo XML do Camel protejam corpos do tipo String, byte[] ou InputStream, corpos que já são um `javax.xml.transform.Source` (como aqueles criados via `convertBodyTo(Source.class)`) são passados ao Saxon sem alterações. Isso permite que um remetente externo forneça um corpo XML manipulado que pode ser usado para ler arquivos locais acessíveis pelo processo Camel ou forçar o processo a fazer requisições a hosts externos.

O componente CoAP no Apache Camel possui um problema onde o `CamelCoapResource` captura exceções que ocorrem após a conclusão de uma rota e envia a mensagem de exceção de volta ao cliente CoAP como uma resposta 5.00 Internal Server Error. Isso geralmente acontece durante falhas de conversão de tipo quando o consumidor converte o corpo final da mensagem para um payload `byte[]` ou processa os cabeçalhos `CamelCoapMaxAge` e `CamelCoapETag`. Consequentemente, um cliente remoto pode obter detalhes internos sensíveis da implantação, incluindo nomes de classes e pacotes, caminhos de corpo de arquivo, nomes de host e detalhes de conexão de backend. Isso ocorre porque o consumidor não possui um mecanismo para suprimir essas exceções, ao contrário dos consumidores HTTP.

Problema de Path Traversal no componente Docling do Apache Camel. O `DoclingProducer` executa a ferramenta externa docling em modo CLI e utiliza a flag `--output` para especificar o diretório de saída. Quando o cabeçalho `CamelDoclingOutputFilePath` é definido, a função `addOutputDirectoryArguments` passa o valor para a flag sem normalização. Isso permite caminhos absolutos ou caminhos contendo segmentos `..`, permitindo que um invasor capaz de definir o cabeçalho crie arquivos de saída de conversão em qualquer diretório acessível ao processo Camel. O problema ocorre quando rotas encaminham valores influenciados externamente para o cabeçalho ou quando consumidores mapeiam cabeçalhos de entrada sem filtrar o namespace de cabeçalhos do Camel. O modo `docling-serve` não é afetado.

Uma expiração de sessão insuficiente no componente Keycloak do Apache Camel ocorre quando a introspecção de token está habilitada via `useTokenIntrospection=true`. O `KeycloakSecurityProcessor` valida tokens de acesso consultando o endpoint de introspecção de token OAuth 2.0 do Keycloak. Por padrão, os resultados são armazenados em cache usando `ConcurrentMapTokenCache` ou `CaffeineTokenCache` com base na configuração `introspectionCacheTtl`. Esses caches expiram as entradas após um período fixo, sem considerar a reivindicação `exp` (expiração) do token. Consequentemente, um token que expira logo após ser armazenado em cache pode ainda ser aceito como ativo até que a entrada do cache expire, permitindo que requisições sejam admitidas com as funções e permissões do token expirado. Este comportamento viola a RFC 7662, que proíbe o cache de respostas de introspecção além do tempo `exp`. Este problema afeta apenas o caminho de introspecção e não impacta a verificação local de JWT.

Um problema de path traversal existe no componente Docling do Apache Camel. O `DoclingProducer` constrói uma linha de comando para uma ferramenta docling externa usando argumentos do cabeçalho `CamelDoclingCustomArguments`. Embora uma verificação de segurança `validatePathSafety()` tenha sido implementada para evitar a travessia de caminhos relativos (ex: usando `../`), ela falha ao não verificar caminhos absolutos. Consequentemente, um invasor que possa controlar os argumentos personalizados pode fornecer um caminho absoluto para direcionar o processo docling para qualquer diretório acessível pelo processo Camel, ignorando as restrições de diretório pretendidas. Isso ocorre no modo CLI padrão. O problema é explorável se uma rota encaminhar valores externos para o cabeçalho ou se um consumidor mapear cabeçalhos de entrada sem filtrar o namespace de cabeçalho do Camel.

A validação inadequada do valor de verificação de integridade no componente Crypto PGP ocorre porque a função `unmarshal()` verificava o código de detecção de modificação apenas quando a mensagem era um pacote de dados protegido por integridade criptografado simetricamente OpenPGP. Pacotes de dados criptografados simetricamente mais antigos não possuem esse código e, como o modo CFB do OpenPGP é maleável sem ele, as mensagens que utilizavam esse pacote ignoravam a verificação completamente. Como o remetente escolhe o tipo de pacote, um invasor poderia reescrever a mensagem durante o trânsito para evitar a verificação. Anteriormente, a opção de integridade regia apenas a marshaling e não possuía um equivalente no lado da descriptografia, impedindo que as implantações exigissem a proteção de integridade nas mensagens aceitas.

Existe um problema de validação inadequada de certificado no componente Knative. Quando o SSL é ativado no cliente HTTP do Knative sem um truststore configurado, o cliente passa a confiar em todos os certificados apresentados em vez de usar as âncoras de confiança padrão da JVM. Isso resulta em uma conexão criptografada sem autenticação de pares, permitindo que um invasor posicionado na rede intercepte e leia o tráfego. Esse estado ocorre por omissão, significando que a ativação do TLS desativa inadvertidamente a validação do certificado.

Existe uma condição de corrida (race condition) no componente PQC onde o produtor utiliza uma única instância de `java.security.Signature` para cada troca sem a sincronização adequada. Como a classe `Signature` mantém estado e não é segura para threads, a função `update()` (que acumula dados) e a função `verify()` (que consome o estado) podem se intercalar quando ocorrem trocas simultâneas. Este comportamento não determinístico pode resultar em uma verificação relatando sucesso para uma mensagem cuja assinatura não foi efetivamente verificada, comprometendo as garantias de segurança do componente. Este problema é desencadeado por tráfego concorrente através do mesmo endpoint.

O consumidor HTTP Knative no componente Knative do Apache Camel não lida adequadamente com falhas no processamento de trocas no lado do consumidor. Nesses casos, o consumidor escreve a exceção resultante—incluindo o nome da classe, mensagem e rastreamento de pilha (stack trace)—diretamente para o chamador remoto como o corpo da resposta. Isso permite que um remetente externo provoque falhas e obtenha detalhes internos da implantação, como nomes de classes e pacotes, nomes de sistema de arquivos ou hosts e a estrutura da rota. Além disso, se as mensagens de exceção contiverem strings de configuração ou conexão, essas informações são expostas.

Os componentes Apache Camel HTTP, Netty HTTP, Undertow e Vert.x HTTP possuem um problema onde mensagens recebidas podem sobrescrever a URI do endpoint através dos cabeçalhos `CamelHttpUri` e `CamelRestHttpUri`. Esses cabeçalhos são processados pelo `CamelContext.resolvePropertyPlaceholders()`, que é uma facilidade de resolução de configuração. Isso permite que um invasor acesse variáveis de ambiente do sistema operacional, propriedades do sistema JVM, funções de segredo `PropertiesFunction` registradas (incluindo AWS, Azure, GCP, HashiCorp, IBM, CyberArk e Kubernetes) e invoque métodos sem argumentos em qualquer bean no registro via `camel-bean`. Sete locais de chamada são afetados: - `HttpHelper.createURL()` e `HttpHelper.createMethod()` em camel-http-common - `HttpMethodHelper.createMethod()` em camel-http - `VertxHttpHelper.resolveHttpURI()` em camel-vertx-http - `UndertowHelper.createURL()` e `UndertowHelper.createMethod()` em camel-undertow - `NettyHttpHelper.createURL()` em camel-netty-http Certos consumidores HTTP podem preencher automaticamente o `CamelHttpUri` a partir da linha de requisição. Além disso, placeholders não resolvíveis podem disparar uma `RuntimeExchangeException` que ecoa a URI, revelando potencialmente se uma chave de configuração está definida.

Um problema de Cross-Site Request Forgery (CSRF) existe no componente OAuth. O callback do código de autorização não possui um parâmetro de estado para vinculá-lo à solicitação de autorização inicial e não verifica um. Isso permite que um invasor associe um código de autorização à sessão de uma vítima, resultando em um CSRF de login, onde a vítima é conectada a uma conta controlada pelo invasor. Além disso, o tratamento de callback não validado permite um redirecionamento aberto a partir de uma origem confiável, permitindo que o destino do redirecionamento pós-autenticação seja influenciado. Esses caminhos são acessíveis sem interação com o provedor de identidade, pois a verificação de estado ocorre antes do resgate do código de autorização.

Um problema de path traversal existe no componente FTP do Apache Camel, afetando os esquemas ftp, ftps e sftp. Os consumidores de arquivos remotos constroem caminhos remotos absolutos concatenando o diretório configurado com nomes de arquivos da listagem de diretórios do servidor, sem normalização lexical ou verificações de contenção. Isso permite que um servidor remoto malicioso ou comprometido, ou um invasor no caminho manipulando a resposta LIST, force o Camel a ler, excluir ou renomear arquivos fora do diretório de sondagem pretendido usando as credenciais do endpoint. O problema ocorre em `FtpUtils.absoluteFilePath` e `GenericFileConsumer`, afetando operações como recuperação via `FtpOperations.retrieveFile` e `SftpOperations`, exclusão via `GenericFileDeleteProcessStrategy` e renomeação via `GenericFileProcessStrategySupport` e `GenericFileRenameExclusiveReadLockStrategy`. A opção `jailStartingDirectory` não restringiu esses operandos remotos.

O componente `camel-hazelcast` não aplica um `JavaSerializationFilterConfig` às instâncias do Hazelcast criadas através de caminhos de configuração específicos. Isso ocorre quando o `ReplicatedHazelcastAggregationRepository` sobrescreve a função `doStart()` sem chamar o método super, e quando o `HazelcastDefaultComponent#getOrCreateHzClientInstance()` constrói um `ClientConfig` enquanto o `hazelcastMode` está definido como `client` sem um `ClientConfig` referenciado ou `hazelcastConfigUri`. Consequentemente, a desserialização Java permanece irrestrita. Um invasor capaz de publicar dados no cluster Hazelcast conectado pode disparar a desserialização de um objeto Java manipulado na camada de serialização, resultando em execução remota de código. Este risco é ampliado pois os clusters Hazelcast não habilitam autenticação ou TLS por padrão.

O componente Thrift realizava o unmarshalling de dados recebidos em um `defaultInstance` compartilhado do tipo de destino em vez de uma cópia nova, retornando esse objeto compartilhado como o corpo da troca. Como a instância é compartilhada em todo o processo, o estado gravado durante o unmarshalling de uma mensagem permanecia no objeto e ficava visível para todas as mensagens posteriores que utilizassem o mesmo tipo. Isso permite que o conteúdo de um remetente seja lido durante o processamento da mensagem de outro remetente, ou que trocas simultâneas observem estados parcialmente gravados, resultando na divulgação de dados em implantações que atendem a mais de um locatário ou usuário.

O componente Mina não suprime informações sensíveis quando ocorre uma falha no processamento de um exchange. O consumidor Mina envia o resultado de `exchange.getException()` diretamente para o peer remoto via socket. Dependendo do codec utilizado, isso pode expor o nome da classe da exceção, a mensagem ou a exceção serializada completa e a cadeia de causas. Um invasor capaz de provocar uma falha pode obter detalhes internos da implantação, incluindo nomes de pacotes, caminhos de arquivos, nomes de host e detalhes de conexão.

Um problema de autenticação inadequada existe no componente OAuth do Apache Camel. Os processadores `camel-oauth` projetados para proteger rotas não interrompem a troca quando a autenticação não pode ser concluída. Em vez de encerrar o processo de roteamento e retornar um erro, os processadores permitem que a solicitação prossiga para o endpoint protegido como se a autenticação tivesse tido sucesso. Isso cria uma guarda de autenticação fail-open, permitindo que chamadores não autenticados acessem recursos protegidos através do caminho de solicitação comum de uma rota configurada para OAuth.

O componente HTTP Vertx contém uma política de domínio cruzado permissiva. A função `createCorsHandler()` define o cabeçalho Access-Control-Allow-Credentials como true, independentemente de a verificação de origem ter sido aprovada. Quando a variável `camel.server.cors.origins` não está definida, o manipulador permite qualquer origem e reflete a Origem do chamador no cabeçalho Access-Control-Allow-Origin. Essa configuração permite que páginas de qualquer origem façam requisições cross-origin com credenciais ao endpoint e leiam as respostas.

Uma limitação inadequada de um caminho a um diretório restrito, conhecida como Path Traversal, existe no componente Azure Files do Apache Camel. O problema ocorre porque os consumidores de arquivos remotos constroem caminhos remotos absolutos concatenando o diretório configurado com nomes de arquivos da listagem de diretórios do servidor, sem normalização lexical ou verificações de contenção. Isso permite que um servidor remoto malicioso ou comprometido, ou um invasor no caminho, forneça uma entrada de listagem que resolva para um caminho fora do diretório de monitoramento configurado. Consequentemente, a aplicação pode ler, excluir ou renomear arquivos fora do diretório pretendido usando as credenciais do endpoint. Essa falha afeta operações manipuladas por `FtpUtils.absoluteFilePath` e `GenericFileConsumer`, impactando funções como `FtpOperations.retrieveFile`, `GenericFileDeleteProcessStrategy` e `GenericFileProcessStrategySupport`. A opção `jailStartingDirectory` não restringiu esses operandos remotos.