CVE-2026-91085
UnknownSummary
Apache Karaf's config:install command is not covered by any ACL rule and is therefore allowed for any authenticated user, including one with only the viewer role. The command fetches a file from an arbitrary URL and writes it into karaf.etc, which contains security-relevant files such as users.properties, keys.properties, host.key, and all ACL configuration files. With the --override flag, existing files can be overwritten, and Felix FileInstall automatically reloads changed .cfg files without requiring a restart.
Risk Assessment
A low-privileged authenticated user can overwrite critical Karaf configuration files, including ACL files and credential stores, leading to privilege escalation and full compromise of the instance. Because changes are auto-reloaded, the attack does not require a service restart.
Recommendation
Add install = admin to etc/org.apache.karaf.command.acl.config.cfg (create the file if absent) and/or set karaf.secured.command.compulsory.roles=admin in etc/system.properties, then restart Karaf so unmatched commands fail closed by default.
Other vulnerabilities in Apache Karaf
See all- CVE-2026-92142Unknown
Apache Karaf has a vulnerability in JMX MBeanServer security, where createMBean, registerMBean, and unregisterMBean operations are not subject to RBAC. This allows a user with the 'viewer' role to achieve remote code execution in the Karaf JVM by using MLet as a remote classloader.
- CVE-2026-91048Unknown
A vulnerability in Apache Karaf is due to the lack of an ACL configuration file for jdbc and jms commands, allowing any authenticated shell session (even with the viewer role) to execute all jdbc:* and jms:* commands. The jdbc:ds-create command allows storing an arbitrary JDBC URL, which can lead to code execution at the connection level, bypassing the admin role gate.
- CVE-2026-91012Unknown
A vulnerability in Apache Karaf allows a user with the "manager" role to write arbitrary content to any file the Karaf process can write to. This is achieved by bypassing path checks in ConfigRepositoryImpl.update() and createFactoryConfiguration(), where the felix.fileinstall.filename value or a PID with ".." segments can point outside the ${karaf.etc} directory.
- CVE-2026-91006Unknown
Apache Karaf's instance-management service (InstanceServiceImpl) builds the command line used to launch a child Karaf JVM by string concatenation, then executes it through /bin/sh (Unix) or cscript (Windows). The caller-supplied javaOpts value is spliced into that string unquoted, allowing shell metacharacters (;, |, `, $(...)) to be interpreted by the shell, leading to arbitrary OS command execution as the Karaf process user.
- CVE-2026-92230High
Apache Karaf's XmlUtils cached XML parser/transformer factories in static ThreadLocal fields on long-lived container threads. Because a ThreadLocal value outlives the OSGi bundle that created it, repeated bundle or feature install, update, or refresh operations can leave successive bundle ClassLoader's pinned in memory and unreachable for garbage collection, leading to unbounded Metaspace growth and eventual denial of service of the Karaf instance.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS