Spring Integration CVE-2026-59321

Exploitation requires three specific conditions to hold simultaneously: (1) the target Spring Integration application must be configured with at least one channel that uses script-backed message processing via the JSR-223 ScriptEngine API; (2) the script engine in use must declare THREADING=null - the Kotlin KTS engine is the named example, but any JSR-223 engine without thread-safety guarantees qualifies; and (3) the channel must receive concurrent messages, meaning multiple threads must process messages simultaneously through the same channel instance. PR:L in the CVSS vector indicates that sending messages to the channel requires low-privilege authenticated access, not unauthenticated exploitation. AC:H reflects the timing-dependent nature of the race - the condition cannot be deterministically triggered and depends on concurrent scheduling. Deployments not using script-backed channels, using only THREADING=MULTITHREADED or STATELESS engines, or running integration channels on single-threaded executors are not exploitable.

The CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N scores 4.2 (Medium), and the signal breakdown is internally consistent. AV:N is warranted because Spring Integration channels are typically triggered by network-delivered messages (HTTP, JMS, AMQP, etc.). AC:H correctly reflects that exploiting this race condition requires precise concurrent timing - low-throughput or single-threaded deployments are practically unexploitable. PR:L is appropriate since sending messages to an integration channel generally requires at least application-level credentials or channel access. The C:L/I:L impact reflects partial cross-message data leakage rather than full data exfiltration or system compromise. No EPSS score was provided in the input, so exploitation probability cannot be quantified. No CISA KEV listing and no public exploit code exists, indicating this remains a theoretical but credible risk rather than an actively weaponized threat. Real-world priority is elevated for multi-tenant Spring Integration deployments processing sensitive data (PII, credentials, financial records) over script-backed channels under concurrent load - in those environments the confidentiality impact is more severe than the base score suggests. Deployments that do not use script-backed channels, or that use only thread-safe script engines, are entirely unaffected.

An attacker or malicious internal user with channel access sends a high volume of concurrent messages to a Spring Integration channel backed by the Kotlin KTS engine. Under concurrent load, a race between two threads causes Thread A's message payload bindings to overwrite Thread B's ScriptEngine context mid-evaluation, resulting in Thread B's script executing with Thread A's payload or header values - exposing potentially sensitive data from one user's message to another's processing context. No public exploit code exists, but the condition is reproducible through standard concurrent load generation against a vulnerable integration endpoint.