CVE-2026-59307

In Spring Integration, calls to JdbcMessageStore.addAllowedPatterns() that are meant to restrict Java deserialization to trusted classes provide no protection when the store is configured as a Spring-managed bean, leaving deserialization of stored message data unrestricted (CWE-502). The flaw is triggered in applications that declare the JDBC message store as a Spring bean and rely on addAllowedPatterns() for safety, since the configured patterns are simply not enforced in that deployment. An attacker who can influence data placed into the message store could cause arbitrary classes to be deserialized, potentially reaching a gadget chain with high-impact confidentiality, integrity, and availability consequences (CVSS 3.1 score 8.0, though exploitation requires high privileges and favorable conditions). Affected users are deployments running Spring Integration 7.1.0, 7.0.0-7.0.5, 6.5.0-6.5.10, or 6.4.0-6.4.12 that use the JdbcMessageStore in this configuration. No public proof-of-concept, CISA KEV listing, or in-the-wild exploitation is known; EPSS currently estimates a 0.3% probability of exploitation within 30 days.

What to do: Upgrade Spring Integration to a patched release beyond the affected ranges listed above, per the VMware/Broadcom security advisory, since fixed version numbers are not specified in the available data. In the meantime, audit your application context to determine whether JdbcMessageStore is defined as a Spring-managed bean and whether you rely on addAllowedPatterns() for deserialization restrictions; if so, treat store contents as untrusted and review the classpath for known deserialization gadget libraries until patched.