<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 04:41:52 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-92142</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-92142</link>
      <description>&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;private final List&amp;lt;String&amp;gt; guarded = Collections.unmodifiableList( Arrays.asList(&amp;#34;invoke&amp;#34;, &amp;#34;getAttribute&amp;#34;, &amp;#34;getAttributes&amp;#34;, &amp;#34;setAttribute&amp;#34;, &amp;#34;setAttributes&amp;#34;));&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;As a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged &amp;#34;viewer&amp;#34; 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).&lt;/p&gt;
&lt;p&gt;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 fil…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;private final List&amp;lt;String&amp;gt; guarded = Collections.unmodifiableList( Arrays.asList(&amp;#34;invoke&amp;#34;, &amp;#34;getAttribute&amp;#34;, &amp;#34;getAttributes&amp;#34;, &amp;#34;setAttribute&amp;#34;, &amp;#34;setAttributes&amp;#34;));&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;As a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged &amp;#34;viewer&amp;#34; 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).&lt;/p&gt;
&lt;p&gt;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 fil…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-92142</guid>
    </item>
    <item>
      <title>GHSA-5rr2-29jr-5v63</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-5rr2-29jr-5v63</link>
      <description>&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;private final List&amp;lt;String&amp;gt; guarded = Collections.unmodifiableList( Arrays.asList(&amp;#34;invoke&amp;#34;, &amp;#34;getAttribute&amp;#34;, &amp;#34;getAttributes&amp;#34;, &amp;#34;setAttribute&amp;#34;, &amp;#34;setAttributes&amp;#34;));&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;As a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged &amp;#34;viewer&amp;#34; 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).&lt;/p&gt;
&lt;p&gt;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 fil…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;private final List&amp;lt;String&amp;gt; guarded = Collections.unmodifiableList( Arrays.asList(&amp;#34;invoke&amp;#34;, &amp;#34;getAttribute&amp;#34;, &amp;#34;getAttributes&amp;#34;, &amp;#34;setAttribute&amp;#34;, &amp;#34;setAttributes&amp;#34;));&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;As a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged &amp;#34;viewer&amp;#34; 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).&lt;/p&gt;
&lt;p&gt;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 fil…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-5rr2-29jr-5v63</guid>
    </item>
  </channel>
</rss>
