camel-jms Reprodutor de Bypass de Filtro do DefaultExchangeHolder Forjado (CVE-2026-43866)

Este projeto demonstra CVE-2026-43866, um bypass da correção do CVE-2026-40860 nos componentes camel-jms (e camel-sjms / família JMS) do Apache Camel. CVE-2026-40860 adicionou uma lista de permissão de classes pós-desserialização (java.**;javax.**;org.apache.camel.**;!*) a payloads JMS ObjectMessage recebidos. Mas org.apache.camel.support.DefaultExchangeHolder reside no namespace org.apache.camel.** incluído na lista de permissão, portanto um ObjectMessage cujo objeto de nível superior é um DefaultExchangeHolder passa na verificação. O lado receptor então chama DefaultExchangeHolder.unmarshal() nele sem exigir transferExchange — escrevendo todos os campos não nulos do holder no Exchange roteado (corpo, cabeçalhos IN/OUT, propriedades do exchange, variáveis, id do exchange, exceção). Um atacante que pode publicar um ObjectMessage pode, portanto, injetar estado arbitrário do Exchange usando apenas tipos java.* universalmente confiáveis — nenhuma cadeia de gadgets de desserialização necessária — para manipular roteamento, cabeçalhos, propriedades e tratamento de erros.

Advisory: https://camel.apache.org/security/CVE-2026-43866.html

Resumo da Vulnerabilidade

Detalhes Técnicos

// JmsBinding.extractBodyFromJms(...) - affected 4.18.2
if (message instanceof ObjectMessage objectMessage) {
    Object payload = objectMessage.getObject();
    checkDeserializedClass(payload);                        // CVE-2026-40860 allow-list: java.**;javax.**;org.apache.camel.**;!*
    if (payload instanceof DefaultExchangeHolder holder) {  // <-- DefaultExchangeHolder is org.apache.camel.** -> passes
        DefaultExchangeHolder.unmarshal(exchange, holder);  // <-- writes forged state into the Exchange; NO transferExchange gate
        Map<String, Object> jmsHeaders = extractHeadersFromJms(message, exchange);
        exchange.getIn().getHeaders().putAll(jmsHeaders);
        return exchange.getIn().getBody();
    } else {
        return payload;
    }
}

A assimetria: o lado remetente controla a criação de ObjectMessage/transferExchange, mas o lado receptor desserializa qualquer DefaultExchangeHolder que desserializar. A correção (4.14.8 / 4.18.3 / 4.21.0) adiciona uma nova opção objectMessageEnabled (security = "insecure:serialization", padrão false) — um ObjectMessage recebido não é mais desserializado a menos que explicitamente ativado, então um holder forjado nunca pode alcançar unmarshal(). (Esta é uma mudança que quebra a compatibilidade para rotas que dependem de ObjectMessage / transferExchange.)

Uma lista de permissão do provedor JMS não ajuda. Este PoC configura o cliente ActiveMQ com um trustedPackages realista e restrito trustedPackages = [java, javax, org.apache.camel] — a entrada org.apache.camel é exatamente o que uma implantação usando transferExchange legítimo deve confiar. O holder forjado ainda passa, porque ele próprio é um DefaultExchangeHolder cujos campos são todos tipos java.* confiáveis, indistinguível de um legítimo.

A rota da vítima

from("jms:queue:cve")                 // mapJmsMessage defaults to true; transferExchange NOT set
    .process(exchange -> { /* observes the injected body / headers / properties */ });

Layout do repositório — atacante vs. vítima

A vítima é o consumidor Camel JMS. O atacante é qualquer produtor que possa publicar na fila. Ambos se comunicam com um broker real Apache ActiveMQ Artemis no Docker.

CVE-2026-43866/
├── pom.xml                 # camel-jms 4.18.2 + activemq-client 6.2.4  (NO gadget library)
├── Dockerfile              # runs the app (no --add-opens; no gadget)
├── docker-compose.yml      # Artemis broker (quay.io) + the reproducer app
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── JmsConfig.java            # OpenWire ConnectionFactory (trustedPackages incl. org.apache.camel) + jms component
    │   ├── VictimRoute.java          # victim: from("jms:queue:cve"); records what the route observed
    │   ├── CapturedState.java
    │   ├── ForgedHolderFactory.java  # builds a DefaultExchangeHolder via the public marshal() API
    │   └── ExploitController.java    # attacker: publishes the forged holder as an ObjectMessage
    └── resources/
        └── application.properties

Pré-requisitos

• Java 17+ e Maven 3.8+
• Docker (executa o broker e o aplicativo)

Passos para Reprodução

Passo 1: Compilar e iniciar tudo

mvn clean package -DskipTests
docker compose up -d --build

Passo 2: Acionar o bypass

curl -s http://localhost:8080/exploit/attack
# -> Published a forged DefaultExchangeHolder as a JMS ObjectMessage to queue 'cve'.
#    ...
#      body      = INJECTED-BODY-...      (injected: true)
#      header    = pwned-header-...       (injected: true)
#      property  = pwned-property-...     (injected: true)
#
#    >>> Exchange-state injection proof — attacker controlled body+header+property: true

A rota foi executada com um corpo, cabeçalho e propriedade que nunca foram definidos — todos fornecidos pelo holder forjado do atacante.

Limpeza

docker compose down

Vetores de Ataque

Qualquer consumidor Camel JMS (camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, camel-activemq6) com mapJmsMessage=true (o padrão), lendo de um destino no qual um atacante pode publicar. transferExchange não precisa estar habilitado no consumidor.

Condições para Exploração

1. Um consumidor Camel JMS com mapJmsMessage=true (padrão), em uma versão afetada.
2. O atacante pode enfileirar um ObjectMessage cujo payload é um DefaultExchangeHolder.
3. O provedor JMS desserializa o payload — o que, para qualquer implantação que use transferExchange, significa que o provedor já confia em org.apache.camel. Nenhuma biblioteca de gadgets é necessária.

Correção Recomendada

Atualize para 4.14.8 / 4.18.3 / 4.21.0 (CAMEL-23373 / CAMEL-23409). O tratamento de ObjectMessage JMS está desabilitado por padrão através da nova opção objectMessageEnabled; ative-a apenas para destinos alimentados exclusivamente por produtores confiáveis.

Mitigação

Até a atualização:

1. Restrinja o acesso de publicação a filas/tópicos consumidos pelo Camel a produtores confiáveis via autorização do broker JMS.
2. Não exponha consumidores JMS que mapeiam corpos de ObjectMessage para redes não confiáveis.
3. Nota: uma lista de permissão de desserialização do provedor JMS não mitiga este bypass específico (o payload usa apenas classes universalmente confiáveis mais DefaultExchangeHolder).

Aviso Legal

Este reprodutor é fornecido apenas para pesquisa de segurança e testes autorizados, para uma vulnerabilidade divulgada publicamente e corrigida. Não o utilize contra sistemas sem permissão explícita.