Overview 10 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
10matches
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
10
100.0%
Outside Waratek scope
0
0.0%
Not applicable
0
0.0%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
10
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
10
100.0%
split by
peak 9 / year
2020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-59324 | High | 2026-08-27 | No exploit published | No public exploit | When an IntegrationFlow uses .fluxTransform() with an asynchronous/reordering fluxFunction that emits raw payloads, concurrent requests on the same FluxMessageChannel subscription have their reply headers (replyChannel, errorChannel, correlationId, any propagated security/tenant headers) copied from whichever message was most recently consumed upstream. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 Spring Integration 5.5.21 and earlier |
| CVE-2026-59321 | Medium | 2026-08-27 | No exploit published | No public exploit | A single ScriptEngine instance is reused for every message on a script-backed channel. For JSR-223 engines that report THREADING=null (not thread-safe, e.g. the Kotlin kts engine), concurrent message processing can corrupt engine-internal state, potentially leaking one message's payload/headers bindings into another message's script evaluation or throwing spurious exceptions. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 Spring Integration 5.5.21 and earlier |
| CVE-2026-59311 | Medium | 2026-08-27 | No exploit published | No public exploit | A local unprivileged user on the same host can redirect all Zip/UnZip transformer output into a directory of their choosing by pre-creating /tmp/ziptransformer as a symlink before the application starts. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 |
| CVE-2026-59293 | Medium | 2026-08-27 | No exploit published | No public exploit | Unless the application explicitly raises smbMinVersion, the jCIFS client will negotiate down to SMB1/CIFS, which lacks mandatory signing/encryption and is vulnerable to NTLM relay and content-tampering MITM. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 |
| CVE-2026-59292 | Low | 2026-08-27 | No exploit published | No public exploit | PropertiesPersistingMetadataStore, the default file-based ConcurrentMetadataStore, persists its state to ${java.io.tmpdir}/spring-integration/metadata-store.properties with world-readable permissions. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 Spring Integration 5.5.21 and earlier |
| CVE-2026-59274 | Medium | 2026-08-27 | No exploit published | No public exploit | The UnZipTransformer does not limit decompressed entry size or entry count when processing archives. Consequently, an attacker can send a zip archive that can exhaust JVM heap memory, causing a denial-of-service outage. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 |
| CVE-2026-47880 | Medium | 2026-08-27 | No exploit published | No public exploit | A producer who can publish to a JMS destination consumed by any Spring Integration JMS inbound component can set String JMS properties named replyChannel, errorChannel, or json__TypeId__ which are copied verbatim into the Spring Integration MessageHeaders. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 Spring Integration 5.5.21 and earlier |
| CVE-2026-47862 | Medium | 2026-08-27 | No exploit published | No public exploit | An attacker who can set the file_name header on a message reaching a ZipTransformer with ZipResultType.FILE (the default) can cause the resulting .zip archive to be written to an arbitrary filesystem path outside the configured workDirectory. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 |
| CVE-2026-47861 | Medium | 2026-08-27 | No exploit published | No public exploit | An unauthenticated remote attacker who can send a single UDP packet to a Spring Integration UDP inbound adapter can cause the server to emit an outbound UDP datagram to an arbitrary internal or external host and port of the attacker's choosing. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 Spring Integration 5.5.21 and earlier |
| CVE-2020-5413 | Critical | 2020-07-31 | No exploit published | No public exploit | Spring Integration framework provides Kryo Codec implementations as an alternative for Java (de)serialization. When Kryo is configured with default options, all unregistered classes are resolved on demand. This leads to the "deserialization gadgets" exploit when provided data contains malicious code for execution during deserialization. In order to protect against this type of attack, Kryo can be configured to require a set of trusted classes for (de)serialization. Spring Integration should be proactive against blocking unknown "deserialization gadgets" when configuring Kryo in code. |