Ehcache CVE-2025-2529
LOWAttack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify app using external input as Ehcache keys
-
ExploitSubmit crafted colliding key values
-
ExecutionTrigger worst-case cache-write path
-
ImpactDegrade cache-write performance (partial DoS)
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V1 - Encoding and Sanitization Parameter handling
|
| Exploitation Conditions | Exploitable only when an application built on Ehcache 3.x uses cache keys that are sourced from external/attacker-influenced parties AND passes them into the cache in an unfiltered and unsalted manner - this specific key-handling pattern IS the required condition. Applications that salt, hash, validate, or otherwise do not derive cache keys from untrusted external input are not exposed. Limiting factors: high attack complexity (AC:H), impact restricted to degraded cache-write performance (no data exposure or code execution), and dependence on non-default application design rather than an inherent default-configuration flaw. |
| Impact | This is a low-priority issue despite being network-reachable. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L, base 3.7) describes an unauthenticated, remotely-triggerable algorithmic-complexity/hash-collision condition that only degrades cache-write performance (A:L, with C:N/I:N - no confidentiality or integrity impact). High attack complexity (AC:H) reflects that exploitation is conditional on application design rather than a flaw triggerable against any default deployment. Corroborating signals all point to low real-world urgency: EPSS is 0.21% (10th percentile), there is no CISA KEV listing, and no public exploit code was identified in the provided data. CONFLICT/ERROR TO NOTE: the input Tag 'Information Disclosure' contradicts the CVSS vector, which sets C:N - this is an availability/performance issue (partial denial of service via degraded cache writes), not an information-disclosure flaw. Treat the 'Information Disclosure' categorization as mislabeled. |
| Exploit ScenarioDerived | An attacker who can influence values that an Ehcache-backed application uses as cache keys (e.g. HTTP parameters, usernames, identifiers echoed into the cache) submits many crafted keys engineered to collide, forcing worst-case cache-write behavior and degrading application performance. No public exploit code was identified at time of analysis, and success depends entirely on whether the target application feeds unfiltered/unsalted external input directly into cache keys. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 08, 2026
Applications running affected versions of Ehcache 3.x (shipped commercially as IBM Terracotta) can have their cache-write path slowed by remote attackers who can influence the cache keys the application supplies. The issue only materializes when an application derives cache keys from external, attacker-controlled input and passes them into Ehcache in an unfiltered or unsalted form, allowing crafted keys to degrade write throughput; applications that hash, salt, validate, or internally generate their keys are not exposed. The vendor-assessed CVSS of 3.7 (AV:N/AC:H/PR:N/UI:N, C:N/I:N/A:L) and an EPSS score of 0.21 percent (10th percentile) place this as a low-priority availability nuisance rather than a data-compromise or code-execution risk, and no public exploit identified at time of analysis.
RemediationAI
No vendor-released patch identified at time of analysis for CVE-2025-2529; IBM's advisory at https://www.ibm.com/support/pages/node/7247977 should be monitored for updated Ehcache 3.x/Terracotta builds and applied as soon as they are published. In the interim, the effective control is to break the required precondition: never pass untrusted external input directly into Ehcache as a cache key. Hashing or applying a keyed HMAC to externally sourced keys before use prevents attackers from crafting structurally pathological keys, at the cost of added CPU per cache operation and a change in key semantics that must be applied consistently across every cache instance. Salting or prefixing keys with a per-deployment namespace accomplishes the same goal with lower overhead but requires that clustered Terracotta nodes share the salt value, or cache lookups will diverge. Where keys legitimately must come from external parties, validate and normalize them (length limits, character-set restrictions, canonicalization) at the application boundary before they reach the cache, accepting that overly strict validation may reject legitimate business inputs. Additionally, monitor cache write latency and throughput for anomalous degradation as a detection signal, and rate-limit or throttle the upstream interface that supplies keys as a partial containment measure. These compensating controls reduce exposure but do not remove the underlying weakness, so patching remains the preferred resolution.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Ehcache 3.x is a Java caching library whose write path resolves incoming keys into internal storage structures (in-memory segments and, in clustered Terracotta deployments, off-heap or server-side stores). CWE-228 (Improper Handling of Syntactically Invalid Structure) describes the root cause class here: the library assumes keys are well-formed and internally consistent, so when an application forwards arbitrary externally sourced keys without filtering or salting, an attacker can deliberately produce pathological key distributions that slow insertion rather than fail cleanly. This is not a memory-safety or deserialization flaw; it is an algorithmic/data-structure degradation triggered purely by the shape of the supplied keys, which is why impact is confined to availability (A:L) with no confidentiality or integrity component. CPE data identifies cpe:2.3:a:ibm:terracotta as the affected commercial product, reflecting that Ehcache is distributed by IBM/Terracotta under that product identity. The CVSS vector's PR:N confirms the vulnerability is unauthenticated from the network perspective, but AC:H and the dependence on a non-default application design (untrusted, unsalted key sourcing) mean real-world exploitation requires a specific, and uncommon, integration pattern.
Know when Terracotta gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Remotely triggerable with no auth (AV:N/PR:N) but conditional on app using unfiltered external keys (AC:H); only cache-write performance degrades, so C:N/I:N/A:L.
Primary rating from NVD.
CVSS VectorNVD
DescriptionNVD
Applications using affected versions of Ehcache 3.x can experience degraded cache-write performance if the application using Ehcache utilizes keys sourced from (malicious) external parties in an unfiltered/unsalted way.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
GitHub PoC
Exploit-DB