Overview 7 matches · 0 protected · 1 exploited · 0 CISA KEV · 2 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
2
28.6%
No exploit published
5
71.4%
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
7
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
1
14.3%
Working exploit published
0
0.0%
Proof of concept only
3
42.9%
Forecast only
0
0.0%
No public exploit
3
42.9%
split by
peak 4 / year
20204
Mitigation candidate2
No exploit published2
Critical4
not blocked4
Exploited1
Proof of concept only1
No public exploit2
20210
20220
20230
20240
20251
No exploit published1
Medium1
not blocked1
Proof of concept only1
20262
No exploit published2
High1
Medium1
not blocked2
Proof of concept only1
No public exploit1
2020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-54514 | Medium | 2026-06-23 | No exploit published | No public exploit | jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.0.0 until 2.18.8, 2.21.4, and 3.1.4, JDKFromStringDeserializer constructed InetSocketAddress with new InetSocketAddress(host, port), which performs eager DNS name resolution for hostname inputs at deserialization time. An application that binds untrusted JSON into a type containing an InetSocketAddress field issues an attacker-chosen DNS query during readValue, before any application-level validation or connect logic. The fix uses InetSocketAddress.createUnresolved(host, port), deferring DNS to an explicit connect. This vulnerability is fixed in 2.18.8, 2.21.4, and 3.1.4. |
| CVE-2026-54512 | High | 2026-06-23 | No exploit published | Proof of concept only | jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.10.0 until 2.18.8, 2.21.4, and 3.1.4, jackson-databind's PolymorphicTypeValidator (PTV) is the primary safety mechanism guarding polymorphic deserialization. When polymorphic typing is enabled and a type identifier contains generic parameters (i.e. the type ID string contains <), DatabindContext._resolveAndValidateGeneric() validates only the raw container class name (the substring before <) against the configured PTV. If the container type is approved, the method parses the full canonical type string via TypeFactory.constructFromCanonical() and returns the fully parameterized type without ever validating the nested type arguments against the PTV. The nested type arguments are then resolved, instantiated, and populated as beans during deserialization. An attacker who controls the type ID can therefore place a denied class as a generic type parameter of an allowed container — for example java.util.ArrayList<com.evil.Gadget> when only java.util.ArrayList is allow-listed. The container passes the PTV check; com.evil.Gadget is loaded via Class.forName(name, true, loader), instantiated, and its properties are set from attacker-controlled JSON. This completely bypasses an explicitly configured PTV allow-list. This vulnerability is fixed in 2.18.8, 2.21.4, and 3.1.4. |
| CVE-2025-49128 | Medium | 2025-06-06 | No exploit published | Proof of concept only | Jackson-core contains core low-level incremental ("streaming") parser and generator abstractions used by Jackson Data Processor. Starting in version 2.0.0 and prior to version 2.13.0, a flaw in jackson-core's `JsonLocation._appendSourceDesc` method allows up to 500 bytes of unintended memory content to be included in exception messages. When parsing JSON from a byte array with an offset and length, the exception message incorrectly reads from the beginning of the array instead of the logical payload start. This results in possible information disclosure in systems using pooled or reused buffers, like Netty or Vert.x. This issue was silently fixed in jackson-core version 2.13.0, released on September 30, 2021, via PR #652. All users should upgrade to version 2.13.0 or later. If upgrading is not immediately possible, applications can mitigate the issue by disabling exception message exposure to clients to avoid returning parsing exception messages in HTTP responses and/or disabling source inclusion in exceptions to prevent Jackson from embedding any source content in exception messages, avoiding leakage. |
| CVE-2020-9547 | Critical | 2020-03-02 | Mitigation candidate | Exploited | FasterXML jackson-databind 2.x before 2.9.10.4 mishandles the interaction between serialization gadgets and typing, related to com.ibatis.sqlmap.engine.transaction.jta.JtaTransactionConfig (aka ibatis-sqlmap). |
| CVE-2019-14892 | Critical | 2020-03-02 | No exploit published | No public exploit | A flaw was discovered in jackson-databind in versions before 2.9.10, 2.8.11.5 and 2.6.7.3, where it would permit polymorphic deserialization of a malicious object using commons-configuration 1 and 2 JNDI classes. An attacker could use this flaw to execute arbitrary code. |
| CVE-2020-8840 | Critical | 2020-02-10 | Mitigation candidate | Proof of concept only | FasterXML jackson-databind 2.0.0 through 2.9.10.2 lacks certain xbean-reflect/JNDI blocking, as demonstrated by org.apache.xbean.propertyeditor.JndiConverter. |
| CVE-2019-20330 | Critical | 2020-01-03 | No exploit published | No public exploit | FasterXML jackson-databind 2.x before 2.9.10.2 lacks certain net.sf.ehcache blocking. |