Overview 7 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
7matches
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
7
100.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
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
1
14.3%
Forecast only
0
0.0%
No public exploit
6
85.7%
split by
peak 3 / year
20181
No exploit published1
Medium1
not blocked1
No public exploit1
20190
20200
20211
No exploit published1
Critical1
not blocked1
No public exploit1
20221
No exploit published1
Medium1
not blocked1
No public exploit1
20231
No exploit published1
Medium1
not blocked1
No public exploit1
20240
20250
20263
No exploit published3
High3
not blocked3
Proof of concept only1
No public exploit2
201820192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-84218 | High | 2026-09-01 | No exploit published | No public exploit | A flaw was found in Jolokia's JSR-160 proxy functionality where insufficient validation of client-controlled JMX service URLs allows a bypass of the denylist introduced to mitigate CVE-2018-1000130. The proxy accepts a `target.url` value from a Jolokia POST request and passes it to `JMXServiceURL` and `JMXConnectorFactory` for establishing the remote JMX connection. The existing denylist only rejects URLs matching `service:jmx:rmi:///jndi/ldap:.*`, which can be bypassed using alternative valid JMX service URL forms, including `ldaps://` schemes or LDAP URLs with a non-empty JMX host component. These URLs are accepted as valid `JMXServiceURL` objects and can cause the Jolokia agent JVM to perform a JNDI lookup against an attacker-controlled LDAP endpoint. This can result in server-side request forgery (SSRF), forwarding of supplied JMX credentials to the remote endpoint, and potentially remote code execution depending on the classes and configuration available in the target JVM. |
| CVE-2026-54513 | High | 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.10.0 until 2.18.8, 2.21.4, and 3.1.4, BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() allowlists any array type based only on clazz.isArray(), without validating the array's component (element) type against the configured allowlist. A PTV built with allowIfSubTypeIsArray() plus an explicit concrete-type allowlist therefore still permits EvilType[] even though EvilType is not allowlisted. When Jackson deserializes the elements and no per-element type IDs are present, it instantiates the component type directly with no further PTV check, bypassing the allowlist. 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-2023-40037 | Medium | 2023-08-18 | No exploit published | No public exploit | Apache NiFi 1.21.0 through 1.23.0 support JDBC and JNDI JMS access in several Processors and Controller Services with connection URL validation that does not provide sufficient protection against crafted inputs. An authenticated and authorized user can bypass connection URL validation using custom input formatting. The resolution enhances connection URL validation and introduces validation for additional related properties. Upgrading to Apache NiFi 1.23.1 is the recommended mitigation. |
| CVE-2022-38179 | Medium | 2022-08-12 | No exploit published | No public exploit | JetBrains Ktor before 2.1.0 was vulnerable to the Reflect File Download attack |
| CVE-2021-21697 | Critical | 2021-11-04 | No exploit published | No public exploit | Jenkins 2.318 and earlier, LTS 2.303.2 and earlier allows any agent to read and write the contents of any build directory stored in Jenkins with very few restrictions. |
| CVE-2017-2602 | Medium | 2018-05-15 | No exploit published | No public exploit | jenkins before versions 2.44, 2.32.2 is vulnerable to an improper blacklisting of the Pipeline metadata files in the agent-to-master security subsystem. This could allow metadata files to be written to by malicious agents (SECURITY-358). |