Threats Tagged 'cve-2026-91012'
View all threats tagged with 'cve-2026-91012'. Filter and sort to focus on specific types of threats.
Stop chasing alerts. Route them.
Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.
Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)
API access activates after upgrading in Console -> Billing.
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.
Filter Threats
Narrow down the results by type, severity, or affected countries
Threats Tagged 'cve-2026-91012'
Click on any threat for detailed analysis and mitigation recommendations
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. Join the discussion | CVE Database V5 | 09/29/2026, 08:34:11 UTC Added: 09/29/2026, 08:48:16 UTC |
Showing 1 to 1 of 1 result