Apache 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.
Authenticated command injection in Apache Karaf's instance-management service lets a principal who can reach the instance:* shell commands (instance:create, instance:start, instance:restart, instance:change-opts) or the equivalent InstancesMBean JMX operations execute arbitrary OS commands as the Karaf process user, because the caller-supplied javaOpts value is concatenated into a launch string that is then handed to /bin/sh or cscript. Affected deployments are Apache Karaf instances before 4.4.12, and exploitation requires an authenticated principal (CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 8.8) with the ability to supply javaOpts; the risk is amplified by a fail-open default in which unconfigured command scopes are not role-restricted. EPSS is low (0.40%, ~32nd percentile), CISA SSVC records no known exploitation, and no public exploit code was identified at time of analysis, so this is a high-priority but not an emergency issue.
LDAP filter injection in Apache Karaf before 4.4.12 allows a crafted login name to alter the structure of LDAP search filters built by LDAPCache and LDAPBackingEngine, potentially matching an unintended directory entry, over-granting roles, or changing which account a login resolves to. The unescaped value only reaches the filter through two call paths - the GSSAPILdapLoginModule (Kerberos/SPNEGO), which passes the NameCallback name through unescaped, and the LDAPBackingEngine.listRoles path, which passes principal.getName() unescaped - because the default LDAPLoginModule and LDAPPubkeyLoginModule both pre-escape the login name via Util.doRFC2254Encoding(). The issue is remote and unauthenticated per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L, score 7.3), but real-world impact is bounded by the administrator-configured userFilter/roleFilter templates; there is no confirmed active exploitation (not in CISA KEV), no public exploit code identified at time of analysis, and EPSS is low at 0.25% (14th percentile). A vendor patch is available in Apache Karaf 4.4.12.
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.
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.
Authenticated command injection in Apache Karaf's instance-management service lets a principal who can reach the instance:* shell commands (instance:create, instance:start, instance:restart, instance:change-opts) or the equivalent InstancesMBean JMX operations execute arbitrary OS commands as the Karaf process user, because the caller-supplied javaOpts value is concatenated into a launch string that is then handed to /bin/sh or cscript. Affected deployments are Apache Karaf instances before 4.4.12, and exploitation requires an authenticated principal (CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 8.8) with the ability to supply javaOpts; the risk is amplified by a fail-open default in which unconfigured command scopes are not role-restricted. EPSS is low (0.40%, ~32nd percentile), CISA SSVC records no known exploitation, and no public exploit code was identified at time of analysis, so this is a high-priority but not an emergency issue.
LDAP filter injection in Apache Karaf before 4.4.12 allows a crafted login name to alter the structure of LDAP search filters built by LDAPCache and LDAPBackingEngine, potentially matching an unintended directory entry, over-granting roles, or changing which account a login resolves to. The unescaped value only reaches the filter through two call paths - the GSSAPILdapLoginModule (Kerberos/SPNEGO), which passes the NameCallback name through unescaped, and the LDAPBackingEngine.listRoles path, which passes principal.getName() unescaped - because the default LDAPLoginModule and LDAPPubkeyLoginModule both pre-escape the login name via Util.doRFC2254Encoding(). The issue is remote and unauthenticated per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L, score 7.3), but real-world impact is bounded by the administrator-configured userFilter/roleFilter templates; there is no confirmed active exploitation (not in CISA KEV), no public exploit code identified at time of analysis, and EPSS is low at 0.25% (14th percentile). A vendor patch is available in Apache Karaf 4.4.12.
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.