CVE-2026-91085
NieznaneStreszczenie
Apache Karaf posiada lukę w kontroli dostępu do polecenia config:install, które nie zostało objęte regułą ACL i jest dostępne dla każdego uwierzytelnionego użytkownika, nawet z rolą viewer. Polecenie pobiera plik z dowolnego URL i zapisuje go do katalogu karaf.etc, gdzie znajdują się pliki bezpieczeństwa (users.properties, keys.properties, host.key, pliki ACL). Z opcją --override można nadpisać istniejące pliki, a Felix FileInstall automatycznie przeładuje zmienione pliki .cfg bez restartu.
Ocena ryzyka
Uwierzytelniony użytkownik o niskich uprawnieniach może nadpisać krytyczne pliki konfiguracyjne Karaf, w tym pliki ACL i dane uwierzytelniające, co prowadzi do eskalacji uprawnień i pełnego przejęcia kontroli nad instancją. Ponieważ zmiany są automatycznie przeładowywane, atak nie wymaga restartu usługi.
Rekomendacja
Dodaj wpis install = admin w pliku etc/org.apache.karaf.command.acl.config.cfg (utwórz plik, jeśli nie istnieje) oraz ustaw karaf.secured.command.compulsory.roles=admin w etc/system.properties, a następnie zrestartuj Karaf, aby niezgodne polecenia były domyślnie blokowane.
Inne podatności w Apache Karaf
Zobacz wszystkie- CVE-2026-92142Nieznane
Apache Karaf posiada podatność w zabezpieczeniach JMX MBeanServer, gdzie operacje createMBean, registerMBean i unregisterMBean nie są objęte kontrolą RBAC. Pozwala to użytkownikowi z rolą 'viewer' na zdalne wykonanie kodu w JVM Karaf, wykorzystując MLet jako zdalny classloader.
- CVE-2026-91048Nieznane
Podatność w Apache Karaf dotyczy braku pliku konfiguracyjnego ACL dla komend jdbc i jms, co powoduje, że każda uwierzytelniona sesja powłoki (nawet z rolą viewer) może wykonywać wszystkie komendy jdbc:* i jms:*. Komenda jdbc:ds-create pozwala na zapisanie dowolnego adresu URL JDBC, co może prowadzić do wykonania kodu na poziomie połączenia, omijając bramę roli admina.
- CVE-2026-91012Nieznane
Podatność w Apache Karaf pozwala użytkownikowi z rolą "manager" na zapis dowolnej treści do dowolnego pliku, do którego proces Karaf ma prawa zapisu. Dzieje się tak przez ominięcie kontroli ścieżek w ConfigRepositoryImpl.update() i createFactoryConfiguration(), gdzie wartość felix.fileinstall.filename lub PID z segmentami ".." może wskazywać poza katalog ${karaf.etc}.
- CVE-2026-91006Nieznane
Usługa zarządzania instancjami Apache Karaf (InstanceServiceImpl) tworzy polecenie uruchamiające podrzędną maszynę JVM przez konkatenację ciągów, a następnie wykonuje je przez /bin/sh lub cscript. Wartość javaOpts dostarczona przez wywołującego jest wstawiana do tego ciągu bez cudzysłowów, co pozwala na interpretację znaków specjalnych powłoki (;, |, `, $(...)) i wykonanie dowolnych poleceń systemu operacyjnego z uprawnieniami użytkownika procesu Karaf.
- CVE-2026-92230Wysokie
Apache Karaf przechowuje w statycznych polach ThreadLocal fabryki parserów i transformerów XML na długo żyjących wątkach kontenera. Ponieważ wartość ThreadLocal żyje dłużej niż tworzący ją bundle OSGi, powtarzane operacje instalacji, aktualizacji lub odświeżania bundle'a mogą powodować przypięcie kolejnych ClassLoaderów bundle'a w pamięci i uniemożliwienie ich usunięcia przez garbage collector, prowadząc do nieograniczonego wzrostu Metaspace i ostatecznie do odmowy usługi (DoS) instancji Karaf.
Oryginalny opis (angielski, źródło NVD)
Apache Karaf's shell/SSH command security is enforced by per-scope ACL configuration files (etc/org.apache.karaf.command.acl.<scope>.cfg). SecuredSessionFactoryImpl.checkSecurity() resolves the roles required for an invocation and, when no ACL rule matches the command, fails open: ACLConfigurationParser.Specificity.NO_MATCH sets passCheck = true. The safety valve for this, karaf.secured.command.compulsory.roles, ships commented out in etc/system.properties, so an unmatched command is allowed for any authenticated user. The shipped org.apache.karaf.command.acl.config ACL (assemblies/features/standard/src/main/feature/feature.xml, mirrored into instance/.../etc/org.apache.karaf.command.acl.config.cfg) has no install entry. It restricts delete to admin, restricts edit/property-*/update on the jmx.acl.*, org.apache.karaf.command.acl.* and org.apache.karaf.service.acl.* PIDs to admin, and allows manager for everything else, but config:install was simply unmatched, and therefore allowed for any authenticated user, including one holding only the viewer role. config:install <url> <finalname> fetches url and writes it into ${karaf.etc} as finalname. It calls PathUtils.checkWithin() to block .. traversal outside karaf.etc, but that folder holds every security-relevant file Karaf ships: users.properties, keys.properties, host.key, and all org.apache.karaf.*.acl.* files, including the very ACL file that (mis)governs this command. With -o/--override, an existing file is overwritten with attacker-controlled bytes fetched from an arbitrary URL. Because felix.fileinstall.dir = ${karaf.etc} (etc/config.properties), Felix FileInstall also watches and reloads any .cfg file dropped there, closing the loop without requiring a restart. By contrast, bundle:install, feature:install and kar:install are all admin-only in their own ACLs, and config:delete is admin in this same ACL, config:install was the outlier. MitigationAdd install = admin in etc/org.apache.karaf.command.acl.config.cfg (create the file is absent), and/or set karaf.secured.command.compulsory.roles=admin in etc/system.properties (and restart) to make unmatched commands fail closed by default.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS