CVE-2026-85296 — camel-as2: cross-partner MDN signing key confusion

Runnable proof-of-concept reproducer for the Apache Camel vulnerability where per-request signing material was held in state shared across requests rather than confined to the request being processed. A single ResponseMDN is registered on the shared HttpProcessor and serves every AS2 request; in the dynamic-keys configuration (one trading partner per path, each with its own keys resolved per request from the HttpContext) the affected build wrote the resolved per-request signing key back onto an instance field. Where a deployment serves more than one partner, concurrent or successive requests could therefore observe each other's material, and a Message Disposition Notification could be signed with the key of a different trading partner. AS2 deployments are typically multi-partner by design, so the condition is reached by ordinary concurrent traffic.

Runtime	Directory	Stack
Camel Spring Boot	camel-spring-boot/	Spring Boot 3.5.13 + camel-as2 4.22.0 (affected; fixed 4.22.1)
Camel Quarkus	camel-quarkus/	Quarkus 3.39.0 + camel-quarkus-as2 (Camel 4.22.0, affected; fixed control CQ 3.40.0 / Camel 4.22.1)

Both modules demonstrate the affected and the fixed behaviour.

What it demonstrates

The driver uses the real ResponseMDN (the AS2 response interceptor) in its dynamic-keys form. It resolves two partners' signing material in turn — Partner A, then Partner B — through ResponseMDN.process(...) (each with that partner's RSA key in the HttpContext), and reads the instance's signingPrivateKey field after each.

• Affected: after handling Partner A's request the shared instance holds Partner A's private key; after Partner B's it holds Partner B's. The per-request key is stored on the shared instance, so a concurrent request for one partner can read — and sign its MDN with — another partner's key.
• Fixed: the field is final and never written; the per-request key stays confined to the request, so the shared instance's signingPrivateKey stays null.

# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack     # affected: per-request key on the shared instance; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85296-as2-signing-key-confusion-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack     # fixed: field stays null; >>> Not exploited

# Camel Quarkus
cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack     # affected (Camel 4.22.0): per-request key on the shared instance
docker compose down
# Patched control: CQ 3.40.0 ships Camel 4.22.1
mvn clean package -Dcamel-quarkus.version=3.40.0 -Dquarkus.platform.version=3.40.0
java -jar target/quarkus-app/quarkus-run.jar &
curl -s http://localhost:8080/exploit/attack     # fixed: field stays null

Vulnerability Summary

Property	Value
Component	camel-as2 (ResponseMDN dynamic-keys handling)
CWE	CWE-488 (Exposure of Data Element to Wrong Session)
Severity	MEDIUM
Attack vector	Ordinary concurrent AS2 traffic across a multi-partner deployment sharing one ResponseMDN instance
Impact	A Message Disposition Notification signed with another trading partner's private key; cross-partner signing-material reuse
Affected Versions	From 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1
Fixed Versions	4.18.5, 4.22.1, 4.23.0
JIRA	CAMEL-24429
Credit	Claude Security Scan Tool

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

The Quarkus affected module is built on CQ 3.39.0 (Camel 4.22.0): the dynamic per-request AS2 signing-key mechanism this PoC exercises postdates CQ 3.29.0 (Camel 4.15.0), so CQ 3.39.0 ships the same Camel 4.22.0 as the Spring Boot module.

The fix

ResponseMDN makes the configured security fields final and resolves the dynamic per-request material into locals inside process(), never writing it back to instance fields. A single shared instance can therefore no longer leak one request's signing key to another request.

Mitigation if you cannot upgrade

Run a separate Camel context per trading partner so that no signing material is shared between them.

Disclaimer

This repository is published for educational and defensive purposes: to help Apache Camel users understand the vulnerability, verify whether they are affected, and confirm that upgrading resolves it. The RSA key pairs are generated in-process for the demonstration and are inert. Do not use this material against systems you do not own or operate.