{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageName": "org.apache.karaf.config.core.impl",
          "product": "Apache Karaf",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.4.12",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "n0mi1k <nomilksec@gmail.com>"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "<div><span>org.apache.karaf.config.core.impl.ConfigRepositoryImpl#update(pid, properties)</span>,\nwhich backs the \"config\" MBean and the config:* shell commands, derives the file\nit writes a configuration to from caller-supplied input without checking that\nthe result stays inside&nbsp;<code>${karaf.etc}</code>:</div><div><ul><li>if the submitted property map contains a&nbsp;<code>felix.fileinstall.filename</code>&nbsp;entry, that value is turned directly into a&nbsp;<code>File</code>&nbsp;(<code>getCfgFileFromProperty</code>), so it can point to any absolute path the Karaf process can write to;</li><li>otherwise the configuration PID is concatenated verbatim into the target file name (<code>generateConfigFilename(): new File(karaf.etc, pid + \".cfg\")</code>), so a PID containing \"..\" segments resolves outside&nbsp;<code>${karaf.etc}</code>.&nbsp;<code>createFactoryConfiguration()</code>&nbsp;has the same issue via the factory PID/alias.</li></ul><div>Both code paths are reachable by any caller holding the \"manager\" role under Karaf's shipped command/JMX ACL (<code>org.apache.karaf.command.acl.conf.cfg:</code>&nbsp;\"<code>update = manager</code>\"). 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 \"<code>admin</code>\" (<code>etc/users.properties</code>,&nbsp;<code>etc/*.acl.*.cfg</code>,&nbsp;<code>etc/org.apache.karaf.management.cfg</code>, and similar), allowing a manager-role user to grant themselves the admin role or otherwise take over the container.</div></div><div><br></div><div><span>ConfigMBeanImpl.install()</span>&nbsp;and the&nbsp;<code>config:install</code>&nbsp;shell command already guarded the equivalent risk on their own code path with a&nbsp;<code>finalname.contains(\"..\")</code>&nbsp;string check, but that check does not stop absolute paths or symlink-based escapes, and it was never applied to&nbsp;<code>ConfigRepositoryImpl.update()</code>&nbsp;/&nbsp;<code>createFactoryConfiguration()</code>&nbsp;at all.</div>"
            }
          ],
          "value": "org.apache.karaf.config.core.impl.ConfigRepositoryImpl#update(pid, properties),\nwhich backs the \"config\" MBean and the config:* shell commands, derives the file\nit writes a configuration to from caller-supplied input without checking that\nthe result stays inside\u00a0${karaf.etc}:\n\n  *  if the submitted property map contains a\u00a0felix.fileinstall.filename\u00a0entry, that value is turned directly into a\u00a0File\u00a0(getCfgFileFromProperty), so it can point to any absolute path the Karaf process can write to;\n  *  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\u00a0${karaf.etc}.\u00a0createFactoryConfiguration()\u00a0has the same issue via the factory PID/alias.\n\n\nBoth 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:\u00a0\"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,\u00a0etc/*.acl.*.cfg,\u00a0etc/org.apache.karaf.management.cfg, and similar), allowing a manager-role user to grant themselves the admin role or otherwise take over the container.\n\n\n\n\n\n\nConfigMBeanImpl.install()\u00a0and the\u00a0config:install\u00a0shell command already guarded the equivalent risk on their own code path with a\u00a0finalname.contains(\"..\")\u00a0string check, but that check does not stop absolute paths or symlink-based escapes, and it was never applied to\u00a0ConfigRepositoryImpl.update()\u00a0/\u00a0createFactoryConfiguration()\u00a0at all."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/op8trtz1qxkdwj2rjozhd9yt2yd6nhw4"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Path Traversal in Config Service Allows Manager-to-Admin Privilege Escalation",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "cveId": "CVE-2026-91012",
    "serial": 1,
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.0"
}