Apache Camel AS2 EUVD-2026-104197

Exploitation requires an Apache Camel AS2 server deployment that serves more than one trading partner with dynamically fetched per-request security keys (the keysAreDynamic path that reads keys from the HttpContext), all handled through a single shared ResponseMDN instance on the shared HttpProcessor. The flaw is triggered by concurrent or successive requests from different partners, so no attacker-crafted payload is needed. Limiting factors: single-partner deployments and deployments running a separate Camel context per trading partner are not exposed; the leak is timing-dependent (High attack complexity); affected versions are Camel 4.0.0 before 4.18.5 and 4.19.0 before 4.22.1; and in practice only a configured trading partner is positioned to observe another partner's material.

This is a genuine but moderate-priority confidentiality flaw, not a high-urgency remote code execution issue. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N, base 6.5 Medium) tells a consistent story: network-reachable, no privileges or user interaction needed, but High attack complexity because the leak depends on a race between concurrent/successive requests on a shared ResponseMDN instance - timing the attacker cannot reliably force. No EPSS score, KEV listing, or public POC was provided, so there is no signal of active or widespread exploitation; exploitation status is 'no public exploit identified at time of analysis.' The confidentiality impact is rated High because private signing-key material can cross between trading partners, which is serious, but the condition arises from ordinary multi-partner traffic rather than a crafted attack, making this closer to an information-leak/integrity-of-attribution defect than a weaponizable intrusion vector. Note one tension to verify: the CVSS assigns PR:N, yet realistically only a provisioned AS2 trading partner is positioned to observe another partner's material, so effective exploitation presupposes being a configured partner on a multi-partner deployment - a meaningful real-world limiter not captured by PR:N.

An AS2 server built on Apache Camel serves several trading partners with dynamically resolved per-request keys. Under concurrent or back-to-back requests, the shared ResponseMDN instance leaks one partner's signing material into another partner's exchange, so a Message Disposition Notification is signed with the wrong partner's private key and a partner may observe signing material that is not theirs. No public exploit code is identified; the condition is reached by normal concurrent traffic rather than a deliberately engineered attack.