CVE-2026-59324

Spring Integration contains a race condition (CWE-362) in its reactive messaging support: when an IntegrationFlow uses .fluxTransform() with an asynchronous or reordering fluxFunction that emits raw payloads, per-message reply headers (replyChannel, errorChannel, correlationId, and propagated security/tenant headers) are not kept isolated. Under concurrent requests sharing the same FluxMessageChannel subscription, headers are copied from whichever message was most recently consumed upstream, so replies and security context can be attached to the wrong request. An attacker can therefore receive another user's response or have another session's or tenant's security headers applied to their exchange, producing cross-request and potentially cross-tenant information disclosure (high confidentiality, low integrity impact per the 8.2 CVSS score). Any application built on the affected Spring Integration versions (7.1.0, 7.0.0-7.0.5, 6.5.0-6.5.10, 6.4.0-6.4.12, or 5.5.21 and earlier) that uses this reactive pattern under concurrent load is affected. No public proof-of-concept is known, the flaw is not in CISA's KEV, and EPSS estimates only a 0.2% probability of exploitation in the next 30 days.

What to do: Upgrade each deployed branch to a release beyond the affected ranges (later than 7.1.0, 7.0.5, 6.5.10, and 6.4.12; 5.5.x users should apply the latest 5.5 patch or migrate to a supported branch). Until patched, audit IntegrationFlows for .fluxTransform() with asynchronous or reordering fluxFunctions that emit raw payloads, and either avoid that pattern, prevent concurrent requests from sharing a single FluxMessageChannel subscription, or explicitly re-stamp replyChannel/errorChannel/correlationId and security/tenant headers per message. Also review whether cross-tenant or cross-session header leakage could have exposed sensitive data in past traffic.