Spring's milestone week carries more than 90 CVE fixes into your patch plan

The failure in CVE-2026-59307 is a stale reference, which is exactly why a config review will not catch it. According to the InfoQ roundup, calling `addAllowedPatterns()` on `JdbcMessageStore` replaces the store's deserializing converter with a new permit-all instance, while the row mapper that reads rows keeps its original reference and goes on using it ^[5]. The call succeeds and the allow-list exists as an object; it is just not the object on the path that deserializes `INT_MESSAGE.MESSAGE_CONTENT`, and the reported outcome is Java deserialization remote code execution while the caller believes an allow-list is enforced ^[6]. A scanner that looks for the hardening API being called will mark that file clean.

The second one is a dependency question rather than a code question. Where Spring Integration processes messages concurrently through a JSR-223 scripting engine that reports `THREADING=null`, engine-internal state can corrupt, and the roundup says the consequence is one message's payload and header bindings leaking into another message's script evaluation, or spurious exceptions ^[7]. That property lives in the engine's own metadata, so whether you are exposed is decided by which script engine is on the classpath, not by anything in your flow definition.

Two CVEs get mechanisms. The count is over 90, and the roundup sends you to the Spring Security Advisories page for the rest ^[3][8]. Subtract and at least 88 arrive with no description in the write-up most teams will actually read ^[10]. Spread across the 10-week gap since the previous batch of releases, that is roughly nine advisories a week accumulating whether or not anyone was cutting releases ^[2][13].

For the two named ones to be your problem, a few things have to hold. You need Spring Integration with `JdbcMessageStore`, and you need to have called `addAllowedPatterns()` believing it constrained reads ^[5]. Something you do not control has to be able to put bytes in the `MESSAGE_CONTENT` column ^[6]. For the scripting flaw you need concurrent evaluation and an engine that declares no threading guarantee ^[7]. If none of that describes your deployment, these two are noise and the other 88 are the work.

The fixes named here are tied to the Spring Integration 7.2.0 first milestone ^[8], and a milestone is not a patch release. The Framework 7.1.0-M1 notes are documented as carrying breaking changes and deprecations ^[4]. Modulith 2.2.0-M1 removes the heritage `spring.factories` registration from its moments, events and observability modules ^[15]. Data 2026.1.0-M1 moves four sub-project artifacts at once, from Commons through Neo4j ^[14]. Ingesting a security fix on that line means accepting the churn that rode in with it.

The roundup's headline names six projects and its opening paragraph names ten, a four-project gap that is a decent argument for counting things yourself before you size a patch window ^[1][11][12]. In my context the milestone release notes are the least useful artifact of this week. The advisories page read against a dependency inventory is the whole job.