Vulnerability-Lookup

GHSA-Q6WQ-M79C-29MJ

Vulnerability from github – Published: 2026-09-29 09:31 – Updated: 2026-09-29 12:31

Details

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.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-91012"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-29T09:17:09Z",
    "severity": null
  },
  "details": "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\u0027s 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.",
  "id": "GHSA-q6wq-m79c-29mj",
  "modified": "2026-09-29T12:31:27Z",
  "published": "2026-09-29T09:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91012"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/op8trtz1qxkdwj2rjozhd9yt2yd6nhw4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/09/28/8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

CVE-2026-91012 (GCVE-0-2026-91012)

Vulnerability from cvelistv5 – Published: 2026-09-29 08:34 – Updated: 2026-09-29 09:15

Title

Apache Karaf: Path Traversal in Config Service Allows Manager-to-Admin Privilege Escalation

Summary

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.

Severity

No CVSS data available.

Assigner

apache mitre root Scorecard

References

2 references

URL	Tags
https://lists.apache.org/thread/op8trtz1qxkdwj2rj…	vendor-advisory
http://www.openwall.com/lists/oss-security/2026/09/28/8

Impacted products

1 product

Vendor	Product	Version
Apache Software Foundation	Apache Karaf	Affected: 0 , < 4.4.12 (semver)

Credits

n0mi1k <nomilksec@gmail.com>

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-09-29T09:15:41.656Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/09/28/8"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "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 \u003cnomilksec@gmail.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e\u003cspan\u003eorg.apache.karaf.config.core.impl.ConfigRepositoryImpl#update(pid, properties)\u003c/span\u003e,\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\u0026nbsp;\u003ccode\u003e${karaf.etc}\u003c/code\u003e:\u003c/div\u003e\u003cdiv\u003e\u003cul\u003e\u003cli\u003eif the submitted property map contains a\u0026nbsp;\u003ccode\u003efelix.fileinstall.filename\u003c/code\u003e\u0026nbsp;entry, that value is turned directly into a\u0026nbsp;\u003ccode\u003eFile\u003c/code\u003e\u0026nbsp;(\u003ccode\u003egetCfgFileFromProperty\u003c/code\u003e), so it can point to any absolute path the Karaf process can write to;\u003c/li\u003e\u003cli\u003eotherwise the configuration PID is concatenated verbatim into the target file name (\u003ccode\u003egenerateConfigFilename(): new File(karaf.etc, pid + \".cfg\")\u003c/code\u003e), so a PID containing \"..\" segments resolves outside\u0026nbsp;\u003ccode\u003e${karaf.etc}\u003c/code\u003e.\u0026nbsp;\u003ccode\u003ecreateFactoryConfiguration()\u003c/code\u003e\u0026nbsp;has the same issue via the factory PID/alias.\u003c/li\u003e\u003c/ul\u003e\u003cdiv\u003eBoth code paths are reachable by any caller holding the \"manager\" role under Karaf\u0027s shipped command/JMX ACL (\u003ccode\u003eorg.apache.karaf.command.acl.conf.cfg:\u003c/code\u003e\u0026nbsp;\"\u003ccode\u003eupdate = manager\u003c/code\u003e\"). 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 \"\u003ccode\u003eadmin\u003c/code\u003e\" (\u003ccode\u003eetc/users.properties\u003c/code\u003e,\u0026nbsp;\u003ccode\u003eetc/*.acl.*.cfg\u003c/code\u003e,\u0026nbsp;\u003ccode\u003eetc/org.apache.karaf.management.cfg\u003c/code\u003e, and similar), allowing a manager-role user to grant themselves the admin role or otherwise take over the container.\u003c/div\u003e\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003e\u003cspan\u003eConfigMBeanImpl.install()\u003c/span\u003e\u0026nbsp;and the\u0026nbsp;\u003ccode\u003econfig:install\u003c/code\u003e\u0026nbsp;shell command already guarded the equivalent risk on their own code path with a\u0026nbsp;\u003ccode\u003efinalname.contains(\"..\")\u003c/code\u003e\u0026nbsp;string check, but that check does not stop absolute paths or symlink-based escapes, and it was never applied to\u0026nbsp;\u003ccode\u003eConfigRepositoryImpl.update()\u003c/code\u003e\u0026nbsp;/\u0026nbsp;\u003ccode\u003ecreateFactoryConfiguration()\u003c/code\u003e\u0026nbsp;at all.\u003c/div\u003e"
            }
          ],
          "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\u0027s 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": {
        "dateUpdated": "2026-09-29T08:34:11.409Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/op8trtz1qxkdwj2rjozhd9yt2yd6nhw4"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Karaf: 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",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-91012",
    "datePublished": "2026-09-29T08:34:11.409Z",
    "dateReserved": "2026-09-14T16:27:00.736Z",
    "dateUpdated": "2026-09-29T09:15:41.656Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-Q6WQ-M79C-29MJ

CVE-2026-91012 (GCVE-0-2026-91012)

Tags

Sightings

Nomenclature

Related by attack behaviour