Attack Chain

1. The target deploys a multi-partner AS2 interface using the affected camel-as2 component.
2. The application registers a single shared ResponseMDN instance on the HttpProcessor to handle incoming AS2 requests.
3. Partner A initiates an AS2 request, and the system resolves Partner A's signing material into the ResponseMDN instance.
4. The camel-as2 component writes this per-request private key into an instance field of the shared ResponseMDN object.
5. Partner B initiates a concurrent or subsequent AS2 request before the previous operation concludes or cleans up.
6. The ResponseMDN instance processes the request for Partner B, potentially reading the signing key stored in the instance field that still holds Partner A's material.
7. The application generates an MDN for Partner B that is cryptographically signed using the private key belonging to Partner A.

Impact

Successful exploitation results in the signing of MDN responses with the incorrect trading partner's private key. This compromise of cryptographic integrity impacts non-repudiation and authentication within AS2 communication, potentially allowing misrouting of signed receipts or business logic disruption between trading partners. The vulnerability affects multi-partner AS2 environments, including those utilizing Camel Spring Boot and Camel Quarkus implementations.

Recommendation

1. Upgrade to Apache Camel 4.18.5, 4.22.1, or 4.23.0 to resolve the state management flaw in ResponseMDN.
2. If an immediate upgrade is not feasible, re-architect the Camel deployment to utilize a separate Camel context for each trading partner to ensure isolation of signing material.
3. Verify the fix by monitoring application logs for signing key resolution behavior; the fixed version resolves material into local variables rather than shared instance fields.