The vulnerability is caused by the .fluxTransform() operator in Spring Integration, where an asynchronous or reordering fluxFunction shares a single RequestMessageHolder for concurrent requests. Because this holder is reused, reply headers such as replyChannel, errorChannel, correlationId, and any headers conveying security or tenant context may be inadvertently copied from the most recently consumed upstream message. This race condition results in cross‑message header leakage, exposing routing and security information to unauthorized callers.

Spring Integration versions 7.1.0, 7.0.0 through 7.0.5, 6.5.0 through 6.5.10, 6.4.0 through 6.4.12, 5.5.21 and all earlier releases are vulnerable whenever an IntegrationFlow invokes .fluxTransform() with an asynchronous fluxFunction that emits raw payloads. The flaw is independent of other configuration settings; any use of this pattern in a multi‑tenant or high‑traffic environment demonstrates the attack surface.

The CVSS score of 8.2 indicates a high severity vulnerability, while the EPSS of less than 1% suggests the probability of being exploited in the wild is currently very low, and the issue is not listed in CISA's KEV catalog. An attacker would need to generate simultaneous requests on the same FluxMessageChannel subscription, leveraging timing in the asynchronous fluxFunction to cause the internal holder to value swap. Although this requires coordinated concurrent traffic, it is feasible in services that process many parallel messages, making the vulnerability a realistic risk in high‑volume or multi‑tenant systems.