Skip to main content
No exploitation reportedFix available

CVE-2026-91012

No exploitation reported by the sources we read.

  • Published2026-09-29
  • Fixed in4.4.12
  • WeaknessCWE-22

Am I affected?

With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.

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.

Timeline

dates in UTC
  1. 2026-09-2909:17CVE publishedNVD

Observed activity

isMalicious corpus · updated 2026-10-23 21:37 UTC
Indicators tagged with this CVE, per day0 indicators over 7 days
Block these indicators
  • Firewall list (EDL, text): https://api.ismalicious.com/edl/cve/CVE-2026-91012?format=txt
  • CSV export: https://api.ismalicious.com/edl/cve/CVE-2026-91012?format=csv
  • TAXII collection of exploited CVEs
  • The EDL and CSV take an API key on the Pro plan.

Versions per branch

NVD
Apache karaf
BranchAffectedFixed in
4.4< 4.4.124.4.12

as publishedRanges as NVD and OSV publish them; a distribution’s build can be fixed under an older number.

Distribution builds and vendor advisories

Packages from OSV.dev and products from the vendors' CSAF advisories.

version not verifiedVersions not verified: read as OSV.dev and the vendors publish them, not checked against each vendor's release list.

Vendor advisories

  • CVE-2026-91012 Red Hat Product Security

    org.apache.karaf.config/org.apache.karaf.config.core: Apache Karaf: Privilege escalation via path traversal in configuration service

Full record on NVD

Fix

  1. Update Apache karaf to 4.4.12

Advisories and patches

Detection

Nuclei template
none so far
ProjectDiscovery
Exploit-DB
no entry
Exploit-DB
Proof-of-concept repositories
none listed
PoC-in-GitHub

Sources

Technical details

CVSS v3 Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Published
2026-09-29
Last Modified
2026-10-07
NVD status
Analyzed

Frequently asked questions

What is 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.

Is CVE-2026-91012 actively exploited?

Active exploitation of CVE-2026-91012 has not been confirmed. Its EPSS score was 0.6% on 2026-10-23, the estimated probability of exploitation in the next 30 days.

What is the CVSS score for CVE-2026-91012?

CVE-2026-91012 has a CVSS v3 base score of 9.8 (CRITICAL severity), with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Running org.apache.karaf.config.core? Hear about its next vulnerability

Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».

No credit card required · No monthly cap on website lookups · 250 API requests/month