Overview 7 matches · 0 exploited · 0 CISA KEV · 1 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
7
100.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
blocked by ARMR today
7
100.0%
partly blocked
0
0.0%
not blocked
0
0.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
20193
Protected by Waratek3
Critical1
Medium2
blocked by ARMR today3
Proof of concept only1
No public exploit2
20200
20210
20222
Protected by Waratek2
High1
Medium1
blocked by ARMR today2
No public exploit2
20230
20240
20250
20262
Protected by Waratek2
High1
Low1
blocked by ARMR today2
No public exploit2
20192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-91006 | High | 2026-09-28 | Protected by Waratek | No public exploit | Apache Karaf's instance-management service (InstanceServiceImpl) builds the command line used to launch a child Karaf JVM by string concatenation, then executes it through /bin/sh (Unix) or cscript (Windows). The caller-supplied javaOpts value is spliced into that string unquoted. A javaOpts value containing shell metacharacters (;, |, `, $(...)) is interpreted by the shell instead of being passed to the JVM as an option, giving arbitrary OS command execution as the Karaf process user. Reachable via the shell commands instance:create, instance:start, instance:restart, instance:change-opts, and the equivalent InstanceMBean JMX operations (createInstance, startInstance, changeJavaOpts, cloneInstance). Mitigation * Set karaf.secured.command.compulsory.roles=admin in etc/system.properties to close the fail-open gap for all unconfigured command scopes. * Restrict which principals can reach instance:* commands and InstancesMBean via etc/users.properties role assignments. * Treat javaOpts passed to instance:create/instance:start/instance:change-opts/InstancesMBean as untrusted input only from fully-trusted operators. |
| CVE-2026-24656 | Low | 2026-01-26 | Protected by Waratek | No public exploit | Deserialization of Untrusted Data vulnerability in Apache Karaf Decanter. The Decanter log socket collector exposes the port 4560, without authentication. If the collector exposes allowed classes property, this configuration can be bypassed. It means that the log socket collector is vulnerable to deserialization of untrusted data, eventually causing DoS. NB: Decanter log socket collector is not installed by default. Users who have not installed Decanter log socket are not impacted by this issue. This issue affects Apache Karaf Decanter before 2.12.0. Users are recommended to upgrade to version 2.12.0, which fixes the issue. |
| CVE-2022-22932 | Medium | 2022-01-26 | Protected by Waratek | No public exploit | Apache Karaf obr:* commands and run goal on the karaf-maven-plugin have partial path traversal which allows to break out of expected folder. The risk is low as obr:* commands are not very used and the entry is set by user. This has been fixed in revision: https://gitbox.apache.org/repos/asf?p=karaf.git;h=36a2bc4 https://gitbox.apache.org/repos/asf?p=karaf.git;h=52b70cf Mitigation: Apache Karaf users should upgrade to 4.2.15 or 4.3.6 or later as soon as possible, or use correct path. JIRA Tickets: https://issues.apache.org/jira/browse/KARAF-7326 |
| CVE-2021-41766 | High | 2022-01-26 | Protected by Waratek | No public exploit | Apache Karaf allows monitoring of applications and the Java runtime by using the Java Management Extensions (JMX). JMX is a Java RMI based technology that relies on Java serialized objects for client server communication. Whereas the default JMX implementation is hardened against unauthenticated deserialization attacks, the implementation used by Apache Karaf is not protected against this kind of attack. The impact of Java deserialization vulnerabilities strongly depends on the classes that are available within the targets class path. Generally speaking, deserialization of untrusted data does always represent a high security risk and should be prevented. The risk is low as, by default, Karaf uses a limited set of classes in the JMX server class path. It depends of system scoped classes (e.g. jar in the lib folder). |
| CVE-2019-0226 | Medium | 2019-05-09 | Protected by Waratek | No public exploit | Apache Karaf Config service provides a install method (via service or MBean) that could be used to travel in any directory and overwrite existing file. The vulnerability is low if the Karaf process user has limited permission on the filesystem. Any Apache Karaf version before 4.2.5 is impacted. User should upgrade to Apache Karaf 4.2.5 or later. |
| CVE-2019-0191 | Medium | 2019-03-21 | Protected by Waratek | No public exploit | Apache Karaf kar deployer reads .kar archives and extracts the paths from the "repository/" and "resources/" entries in the zip file. It then writes out the content of these paths to the Karaf repo and resources directories. However, it doesn't do any validation on the paths in the zip file. This means that a malicious user could craft a .kar file with ".." directory names and break out of the directories to write arbitrary content to the filesystem. This is the "Zip-slip" vulnerability - https://snyk.io/research/zip-slip-vulnerability. This vulnerability is low if the Karaf process user has limited permission on the filesystem. Any Apache Karaf releases prior 4.2.3 is impacted. |
| CVE-2018-11788 | Critical | 2019-01-07 | Protected by Waratek | Proof of concept only | Apache Karaf provides a features deployer, which allows users to "hot deploy" a features XML by dropping the file directly in the deploy folder. The features XML is parsed by XMLInputFactory class. Apache Karaf XMLInputFactory class doesn't contain any mitigation codes against XXE. This is a potential security risk as an user can inject external XML entities in Apache Karaf version prior to 4.1.7 or 4.2.2. It has been fixed in Apache Karaf 4.1.7 and 4.2.2 releases. |