Apache Karaf's configuration repository writes config files from caller-supplied input without keeping the result inside ${karaf.etc}. A principal who already has the shipped manager role can reach ConfigRepositoryImpl.update or createFactoryConfiguration through the config MBean or config shell commands and cause the process to write attacker-controlled content to any path it can write, including files otherwise reserved for admin such as etc/users.properties, ACL configs, and management configuration. That write can be used to grant admin or otherwise take over the container. An older ".." check on the install path was incomplete and was never applied to these update and factory-create paths. No public proof of concept is known, the issue is not in CISA KEV, and CVSS has not yet been scored.
What to do: Limit who holds the Karaf manager role and who can invoke config update, factory-configuration create, and the config JMX MBean until Apache publishes and you install a fixed release. After patching, review ${karaf.etc} for unexpected writes, especially etc/users.properties, ACL files, and org.apache.karaf.management.cfg. Do not rely on the older config:install ".." string check; it does not cover these paths and does not stop absolute-path or symlink escapes.
Affected
Apache Software Foundation Apache Karaf
—
Estimated exposure
—No basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
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.
CVE-2026-91012 is a path traversal in Apache Karaf that lets managers escalate to administrator.
Apache disclosed CVE-2026-91012, rated important, in Apache Karaf org.apache.karaf.config.core.impl before 4.4.12. ConfigRepositoryImpl.update, which backs the config MBean and config:* shell commands, builds the configuration file path from caller-supplied input. The result is not checked to remain inside ${karaf.etc}, allowing a path traversal that escalates a manager to administrator. No in-the-wild exploitation is mentioned.