camel-netty-http / camel-vertx-http: Reprodutor de Desserialização Não Segura de Resposta HTTP (CVE-2026-40859)

Este projeto demonstra uma vulnerabilidade de desserialização Java nos componentes camel-netty-http e camel-vertx-http do Apache Camel, rastreada como CVE-2026-40859. Quando um endpoint produtor é configurado com transferException=true (ou com allowJavaSerializedObject=true no nível do componente), uma resposta HTTP do backend com status de falha e Content-Type: application/x-java-serialized-object tem seu corpo desserializado com um java.io.ObjectInputStream puro e sem ObjectInputFilter. Um atacante que controle o backend com o qual o produtor Camel se comunica — um serviço comprometido ou um homem-no-meio (man-in-the-middle) em uma conexão HTTP sem criptografia — pode retornar um objeto serializado especialmente criado e, se houver uma cadeia de gadgets no classpath, obter execução remota de código no host Camel.

Comunicado de segurança: https://camel.apache.org/security/CVE-2026-40859.html

Resumo da Vulnerabilidade

Não explorável na configuração padrão — transferException tem como padrão false. O PoC a habilita, como faria uma aplicação que deseja propagação remota de exceções.

Detalhes Técnicos

Em uma resposta não-2xx, o produtor netty-http (com throwExceptionOnFailure=true, o padrão) constrói uma exceção a partir da resposta por meio de populateNettyHttpOperationFailedException. Se transferException estiver ativado e a resposta trouxer o tipo de conteúdo de objeto serializado, ele desserializa o corpo:

// NettyHttpHelper.populateNettyHttpOperationFailedException(...) - affected version
if (transferException) {
    String contentType = response.headers().get(NettyHttpConstants.CONTENT_TYPE);
    if (NettyHttpConstants.CONTENT_TYPE_JAVA_SERIALIZED_OBJECT.equals(contentType)) {   // application/x-java-serialized-object
        InputStream is = exchange.getContext().getTypeConverter().convertTo(InputStream.class, response);
        if (is != null) {
            Object body = deserializeJavaObjectFromStream(is);   // <-- sink
            if (body instanceof Exception) {
                return (Exception) body;
            }
        }
    }
}

// NettyHttpHelper.deserializeJavaObjectFromStream(InputStream) - affected version
ObjectInputStream ois = new ObjectInputStream(is);   // NO ObjectInputFilter
answer = ois.readObject();                            // gadget fires here

O gadget é executado dentro de readObject(), antes da verificação instanceof Exception — portanto, o payload nem precisa ser uma exceção. camel-vertx-http tem o mesmo sink em VertxHttpHelper.deserializeJavaObjectFromStream.

A rota da vítima

from("direct:call")
    .to("netty-http://backend-host:PORT/path?transferException=true");
    // throwExceptionOnFailure defaults to true

Qualquer chamada de produtor cujo backend responda 5xx + application/x-java-serialized-object aciona o sink.

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

A vítima é o produtor Camel (é ele quem realiza a desserialização). O atacante controla o backend que ele chama. Neste PoC autocontido, ambos os papéis são executados na mesma JVM/container: um servidor HTTP embutido baseado em raw socket (MaliciousBackend) faz o papel do backend controlado pelo atacante, e a rota Camel (VictimRoute) é a vítima.

CVE-2026-40859/
├── pom.xml                 # camel-netty-http 4.18.2 + commons-collections 3.2.1 (gadget)
├── Dockerfile              # runs the app (with --add-opens, needed only to build the gadget)
├── docker-compose.yml
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── VictimRoute.java        # victim: netty-http producer, transferException=true
    │   ├── MaliciousBackend.java   # attacker backend: 500 + serialized-object body on :9999
    │   ├── Gadget.java             # CommonsCollections6 gadget, fires during readObject()
    │   └── ExploitController.java  # /exploit/attack drives the producer call
    └── resources/
        └── application.properties

Em um ataque real, os bytes serializados são produzidos offline pelo atacante (por exemplo, com ysoserial); apenas a vítima precisa da cadeia de gadgets em seu classpath. Este PoC constrói o gadget em processo por conveniência, razão pela qual a JVM é iniciada com --add-opens java.base/java.util=ALL-UNNAMED — essa flag é um detalhe de construção do gadget, não relacionado à vulnerabilidade.

Pré-requisitos

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

Passos para Reprodução

Passo 1: Compilar e iniciar o container

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

Passo 2: Acionar a desserialização (RCE)

curl -s http://localhost:8080/exploit/attack
# -> producer threw ...NettyHttpOperationFailedException  (expected)
#
#    >>> RCE proof — /tmp/pwned exists: true

Passo 3: Verificar

docker exec cve-2026-40859 ls -la /tmp/pwned

Limpeza

docker compose down

Vetores de Ataque

Qualquer produtor camel-netty-http / camel-vertx-http configurado com transferException=true (ou allowJavaSerializedObject=true) que se comunique com um backend que um atacante possa controlar ou interceptar:

• Um homem-no-meio em uma conexão de produtor não criptografada (http://) substitui a resposta.
• Um serviço de backend comprometido ou malicioso retorna a resposta especialmente criada diretamente.

Condições de Exploração

1. Produtor com transferException=true (ou allowJavaSerializedObject=true no componente).
2. throwExceptionOnFailure=true (o padrão).
3. Um backend controlado/interceptável pelo atacante que retorne 5xx + application/x-java-serialized-object.
4. Uma biblioteca de gadgets no classpath (aqui commons-collections:3.2.1).

Correção Recomendada

Atualize para 4.14.8 / 4.18.3 / 4.20.0. A correção restringe ambos os helpers com uma allow-list padrão do ObjectInputFilter (java.**;javax.**;org.apache.camel.**;!*), personalizável por meio da nova opção de endpoint deserializationFilter ou da propriedade de sistema da JVM -Djdk.serialFilter.

Mitigação

Até a atualização:

1. Não habilite transferException=true / allowJavaSerializedObject=true em produtores que se comuniquem com backends não confiáveis ou acessíveis pela rede.
2. Use TLS (https) para conexões de produtor, de modo que as respostas não possam ser substituídas em trânsito.
3. Quando a opção for necessária, defina uma allow-list explícita: -Djdk.serialFilter=java.**;org.apache.camel.**;!*.
4. Remova bibliotecas de gadgets do classpath (atualize/remova commons-collections 3.x e similares).

Aviso de Responsabilidade

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