Spring Integration CVE-2026-59307

Exploitation requires three specific conditions to be simultaneously true: first, the JdbcMessageStore must be declared as a Spring-managed bean (e.g., via @Bean or XML application context - not instantiated manually outside Spring's lifecycle); second, the operator must have explicitly called addAllowedPatterns() on that bean with the intent of restricting deserialization (this is the configuration state where the bypass activates and protection silently fails); third, the attacker must hold authenticated access sufficient to write data to the JDBC message store, consistent with the CVSS PR:H metric. Applications using JdbcMessageStore without any allowlist configuration are in an equivalently unprotected state but are not the scenario described by this CVE's bypass. Unauthenticated or low-privilege remote exploitation is not supported by the available CVSS data. The limiting factors for defenders are the operator-level authentication bar and the specific Spring-managed bean deployment mode required - environments using manually instantiated JdbcMessageStore or not using addAllowedPatterns() are outside the precise scope of this bypass.

The vendor-assigned CVSS 3.1 base score of 8.0 (AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H) correctly reflects full CIA impact when exploited, but the High attack complexity and High privilege requirement are the critical moderating factors for real-world risk. The High privilege requirement (PR:H) implies the attacker must already hold operator-level or equivalent authenticated access to inject data into the JDBC message store - this substantially limits opportunistic or unauthenticated exploitation. The Scope Change (S:C) and full C:H/I:H/A:H capture the well-established risk that Java deserialization gadget chains can escape the JVM application boundary and achieve host-level code execution. No EPSS score was available in the provided intelligence; no CISA KEV listing exists and no public exploit code has been identified, meaning exploitation probability is currently inferred from vulnerability class rather than observed activity. The primary realistic threat model is insider threat, compromised service accounts, or post-initial-access lateral movement scenarios rather than mass exploitation. This is a genuine priority for organizations actively using Spring-managed JdbcMessageStore with deserialization allowlists, but not a mass-exploitation-risk item at the time of this analysis.

An authenticated operator or a compromised service account with write access to the Spring Integration JDBC message store submits a crafted serialized Java object built on a known deserialization gadget chain such as those targeting Apache Commons Collections. When the application subsequently retrieves and deserializes the stored message, the addAllowedPatterns() allowlist - which the operator configured to block malicious class instantiation - applies no filtering due to the bypass, allowing the gadget chain to execute arbitrary code on the host. No public proof-of-concept has been identified at time of analysis, so exploitation currently requires an attacker with both operator-level credentials and the capability to craft a deserialization payload.