Medium Org.springframework.kafka CVEs
2 CVEs, 1 protected by Waratek
Overview 2 matches · 1 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
1
50.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
1
50.0%
blocked by ARMR today
1
50.0%
partly blocked
0
0.0%
not blocked
1
50.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
2
100.0%
split by
peak 2 / month
Jun 26
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-41727 | Medium | 2026-06-10 | No exploit published | No public exploit | Spring Kafka's retry topic infrastructure did not sufficiently validate user-controlled header values before acting on them. A producer could send a record with a crafted retry_topic-attempts header to supply an out-of-range attempt count and cause the retry topic router to misidentify where the message was in the retry sequence. Affected versions: Spring for Apache Kafka 4.0.0 through 4.0.5; 3.3.0 through 3.3.15; 3.2.0 through 3.2.13; 2.9.0 through 2.9.13; 2.8.0 through 2.8.11. |
| CVE-2026-41726 | Medium | 2026-06-10 | Protected by Waratek | No public exploit | When an application opts into DelegatingDeserializer, a producer can grow the consumer's heap without bound by sending records with unique random spring.kafka.serialization.selector header values, eventually causing GC thrash and OutOfMemoryError. Affected versions: Spring for Apache Kafka 4.0.0 through 4.0.5; 3.3.0 through 3.3.15; 3.2.0 through 3.2.13; 2.9.0 through 2.9.13; 2.8.0 through 2.8.11. |