Karaf
Monthly
Authorization bypass in Apache Karaf before 4.4.12 allows an authenticated JMX client holding any role - including the least-privileged 'viewer' - to evade RBAC and achieve remote code execution inside the Karaf JVM. Karaf's MBeanServer guard never checks the lifecycle operations createMBean, registerMBean and unregisterMBean, so a caller can instantiate and register the standard javax.management.loading.MLet class and then invoke its getMBeansFromURL operation, which the shipped default 'get* = viewer' ACL wildcard inadvertently authorizes, causing attacker-hosted classes to be fetched and loaded as new MBeans. Exploitation requires network reachability to the default-enabled remote JMX RMI connector on ports 1099/44444, a valid JMX credential of any role, and outbound network access to the attacker's .mlet host; no public exploit code and no active exploitation were identified at time of analysis, and the issue is rated important by the vendor while the independent assessment places it at high impact across confidentiality, integrity and availability.
Privilege escalation to remote code execution in Apache Karaf before 4.4.12 lets any authenticated shell session - including one holding only the viewer role - execute every jdbc:* and jms:* command, because the command guard (SecuredSessionFactoryImpl) treats commands with no matching ACL rule as permitted and the jdbc/jms ACL configuration files are never shipped. An attacker can use jdbc:ds-create to store a fully controlled JDBC URL into a pax-jdbc-config factory Configuration that is reactively turned into a live DataSource; drivers that act on URL parameters at connect time (for example H2 with INIT=RUNSCRIPT) then execute attacker code, bypassing the admin-role gate that protects shell:exec. No public exploit code identified at time of analysis, EPSS is low at 0.19% (8th percentile), and no CISA KEV listing applies; vendor-released patch: 4.4.12.
Authenticated path traversal in Apache Karaf before 4.4.12 allows a principal holding the shipped 'manager' role to write attacker-controlled content to arbitrary files writable by the Karaf process, because ConfigRepositoryImpl.update() and createFactoryConfiguration() build the target configuration filename from caller-supplied input without confining the result to ${karaf.etc}. Under Karaf's default command/JMX ACL (org.apache.karaf.command.acl.conf.cfg maps 'update = manager'), this lets a manager-role user overwrite files the same ACL reserves to 'admin' - such as etc/users.properties, etc/*.acl.*.cfg, and etc/org.apache.karaf.management.cfg - and thereby grant themselves the admin role or take over the container. The advisory does not indicate active exploitation, and no public exploit code has been identified at time of analysis; EPSS is 0.17% (6th percentile), indicating low predicted exploitation, while published scoring (CVSS 9.8, PR:N) is more severe than this assessment, which requires an authenticated manager-role principal (PR:L) on a deployment that exposes Karaf management and grants manager to non-admins.
Metaspace exhaustion in Apache Karaf before 4.4.11 allows an operator with access to Karaf's bundle- and feature-management surface (SSH console, JMX, or feature deployment) to crash the container by repeatedly installing, updating, or refreshing bundles and features. Each lifecycle cycle leaves the previous bundle ClassLoader pinned in memory via static ThreadLocal caches in XmlUtils, so Metaspace grows without bound until the JVM or the Karaf instance fails - a pure availability impact (CWE-401, missing release of memory). Our independent assessment rates this CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H (local privileged access, high attack complexity, not the vendor-published AV:N/AC:L/PR:N 7.5), because exploitation requires trusted bundle-management privileges and enough cumulative lifecycle churn to exhaust Metaspace; the condition can also occur organically in high-churn continuous-deployment environments. No public exploit code or in-the-wild exploitation was identified at time of analysis, and the issue is not listed in CISA KEV.
Privilege escalation in Apache Karaf versions before 4.4.12 allows any authenticated user of the shell or SSH console - including one holding only the low-privilege 'viewer' role - to abuse the config:install command and write attacker-controlled content into the sensitive ${karaf.etc} directory, escalating to full administrative control of the runtime. The flaw exists because config:install has no entry in the shipped etc/org.apache.karaf.command.acl.config.cfg ACL while unmatched commands fail open, and because karaf.secured.command.compulsory.roles ships commented out in etc/system.properties; with the -o/--override flag an existing file such as users.properties, keys.properties or host.key can be overwritten, and Felix FileInstall (felix.fileinstall.dir=${karaf.etc}) hot-reloads any dropped .cfg file without a restart. The vendor rates this 'moderate'; no EPSS score, no CISA KEV entry and no public POC were provided, and no public exploit has been identified at time of analysis. Authentication is required and the vendor-fixed version is Apache Karaf 4.4.12.
This vulnerable is about a potential code injection when an attacker has control of the target LDAP server using in the JDBC JNDI URL. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An issue was discovered in Legion of the Bouncy Castle BC Java 1.65 and 1.66. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
In Karaf, JMX authentication takes place using JAAS and authorization takes place using ACL files. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Apache Karaf Config service provides a install method (via service or MBean) that could be used to travel in any directory and overwrite existing file. Rated medium severity (CVSS 4.9), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Apache Karaf kar deployer reads .kar archives and extracts the paths from the "repository/" and "resources/" entries in the zip file. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In Apache Karaf version prior to 3.0.9, 4.0.9, 4.1.1, when the webconsole feature is installed in Karaf, it is available at .../system/console and requires authentication to access it. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. This Improper Authentication vulnerability could allow attackers to bypass authentication mechanisms to gain unauthorized access.
In Apache Karaf prior to 4.2.0 release, if the sshd service in Karaf is left on so an administrator can manage the running instance, any user with rights to the Karaf console can pivot and read/write. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. This Improper Privilege Management vulnerability could allow attackers to escalate privileges to gain unauthorized elevated access.
OpenDaylight Karaf 0.6.1-Carbon fails to clear the cache after a password change, allowing the old password to be used until the Karaf cache is manually cleared (e.g. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Apache Karaf before 4.0.10 enables a shutdown port on the loopback interface, which allows local users to cause a denial of service (shutdown) by sending a shutdown command to all listening high. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity.
Authorization bypass in Apache Karaf before 4.4.12 allows an authenticated JMX client holding any role - including the least-privileged 'viewer' - to evade RBAC and achieve remote code execution inside the Karaf JVM. Karaf's MBeanServer guard never checks the lifecycle operations createMBean, registerMBean and unregisterMBean, so a caller can instantiate and register the standard javax.management.loading.MLet class and then invoke its getMBeansFromURL operation, which the shipped default 'get* = viewer' ACL wildcard inadvertently authorizes, causing attacker-hosted classes to be fetched and loaded as new MBeans. Exploitation requires network reachability to the default-enabled remote JMX RMI connector on ports 1099/44444, a valid JMX credential of any role, and outbound network access to the attacker's .mlet host; no public exploit code and no active exploitation were identified at time of analysis, and the issue is rated important by the vendor while the independent assessment places it at high impact across confidentiality, integrity and availability.
Privilege escalation to remote code execution in Apache Karaf before 4.4.12 lets any authenticated shell session - including one holding only the viewer role - execute every jdbc:* and jms:* command, because the command guard (SecuredSessionFactoryImpl) treats commands with no matching ACL rule as permitted and the jdbc/jms ACL configuration files are never shipped. An attacker can use jdbc:ds-create to store a fully controlled JDBC URL into a pax-jdbc-config factory Configuration that is reactively turned into a live DataSource; drivers that act on URL parameters at connect time (for example H2 with INIT=RUNSCRIPT) then execute attacker code, bypassing the admin-role gate that protects shell:exec. No public exploit code identified at time of analysis, EPSS is low at 0.19% (8th percentile), and no CISA KEV listing applies; vendor-released patch: 4.4.12.
Authenticated path traversal in Apache Karaf before 4.4.12 allows a principal holding the shipped 'manager' role to write attacker-controlled content to arbitrary files writable by the Karaf process, because ConfigRepositoryImpl.update() and createFactoryConfiguration() build the target configuration filename from caller-supplied input without confining the result to ${karaf.etc}. Under Karaf's default command/JMX ACL (org.apache.karaf.command.acl.conf.cfg maps 'update = manager'), this lets a manager-role user overwrite files the same ACL reserves to 'admin' - such as etc/users.properties, etc/*.acl.*.cfg, and etc/org.apache.karaf.management.cfg - and thereby grant themselves the admin role or take over the container. The advisory does not indicate active exploitation, and no public exploit code has been identified at time of analysis; EPSS is 0.17% (6th percentile), indicating low predicted exploitation, while published scoring (CVSS 9.8, PR:N) is more severe than this assessment, which requires an authenticated manager-role principal (PR:L) on a deployment that exposes Karaf management and grants manager to non-admins.
Metaspace exhaustion in Apache Karaf before 4.4.11 allows an operator with access to Karaf's bundle- and feature-management surface (SSH console, JMX, or feature deployment) to crash the container by repeatedly installing, updating, or refreshing bundles and features. Each lifecycle cycle leaves the previous bundle ClassLoader pinned in memory via static ThreadLocal caches in XmlUtils, so Metaspace grows without bound until the JVM or the Karaf instance fails - a pure availability impact (CWE-401, missing release of memory). Our independent assessment rates this CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H (local privileged access, high attack complexity, not the vendor-published AV:N/AC:L/PR:N 7.5), because exploitation requires trusted bundle-management privileges and enough cumulative lifecycle churn to exhaust Metaspace; the condition can also occur organically in high-churn continuous-deployment environments. No public exploit code or in-the-wild exploitation was identified at time of analysis, and the issue is not listed in CISA KEV.
Privilege escalation in Apache Karaf versions before 4.4.12 allows any authenticated user of the shell or SSH console - including one holding only the low-privilege 'viewer' role - to abuse the config:install command and write attacker-controlled content into the sensitive ${karaf.etc} directory, escalating to full administrative control of the runtime. The flaw exists because config:install has no entry in the shipped etc/org.apache.karaf.command.acl.config.cfg ACL while unmatched commands fail open, and because karaf.secured.command.compulsory.roles ships commented out in etc/system.properties; with the -o/--override flag an existing file such as users.properties, keys.properties or host.key can be overwritten, and Felix FileInstall (felix.fileinstall.dir=${karaf.etc}) hot-reloads any dropped .cfg file without a restart. The vendor rates this 'moderate'; no EPSS score, no CISA KEV entry and no public POC were provided, and no public exploit has been identified at time of analysis. Authentication is required and the vendor-fixed version is Apache Karaf 4.4.12.
This vulnerable is about a potential code injection when an attacker has control of the target LDAP server using in the JDBC JNDI URL. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An issue was discovered in Legion of the Bouncy Castle BC Java 1.65 and 1.66. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
In Karaf, JMX authentication takes place using JAAS and authorization takes place using ACL files. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Apache Karaf Config service provides a install method (via service or MBean) that could be used to travel in any directory and overwrite existing file. Rated medium severity (CVSS 4.9), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Apache Karaf kar deployer reads .kar archives and extracts the paths from the "repository/" and "resources/" entries in the zip file. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In Apache Karaf version prior to 3.0.9, 4.0.9, 4.1.1, when the webconsole feature is installed in Karaf, it is available at .../system/console and requires authentication to access it. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. This Improper Authentication vulnerability could allow attackers to bypass authentication mechanisms to gain unauthorized access.
In Apache Karaf prior to 4.2.0 release, if the sshd service in Karaf is left on so an administrator can manage the running instance, any user with rights to the Karaf console can pivot and read/write. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. This Improper Privilege Management vulnerability could allow attackers to escalate privileges to gain unauthorized elevated access.
OpenDaylight Karaf 0.6.1-Carbon fails to clear the cache after a password change, allowing the old password to be used until the Karaf cache is manually cleared (e.g. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Apache Karaf before 4.0.10 enables a shutdown port on the loopback interface, which allows local users to cause a denial of service (shutdown) by sending a shutdown command to all listening high. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity.