CVE-2026-91012

org.apache.karaf.config.core.impl.ConfigRepositoryImpl#update(pid, właściwości),
który wspiera komponent MBean „config” i polecenia powłoki config:*, tworzy plik
zapisuje konfigurację z danych wejściowych dostarczonych przez rozmówcę bez sprawdzania tego
wynik pozostaje wewnątrz ${karaf.etc}:

* jeśli przesłana mapa właściwości zawiera wpis felix.fileinstall.filename , wartość ta jest zamieniana bezpośrednio na plik (getCfgFileFromProperty), dzięki czemu może wskazywać dowolną bezwzględną ścieżkę, do której może zapisywać proces Karafa;
* w przeciwnym razie identyfikator konfiguracji jest dosłownie łączony z nazwą pliku docelowego (generateConfigFilename(): nowy plik (karaf.etc, pid + „.cfg”)), więc identyfikator PID zawierający segmenty „..” jest rozpoznawany poza ${karaf.etc}. createFactoryConfiguration() ma ten sam problem za pośrednictwem fabrycznego PID/aliasu.


Obie ścieżki kodu są dostępne dla dowolnego obiektu wywołującego pełniącego rolę „menedżera” w ramach dostarczonej przez Karafa komendy/JMX ACL (org.apache.karaf.command.acl.conf.cfg: „update = manager”). Taki użytkownik może zatem zapisywać zawartość kontrolowaną przez osobę atakującą w dowolnym pliku, który może zapisać proces Karaf, w tym plikach, które ta sama lista ACL w przeciwnym razie rezerwuje dla „administratora” (etc/users.properties, etc/*.acl.*.cfg, etc/org.apache.karaf.management.cfg i podobne), umożliwiając użytkownikowi z rolą menedżera przyznanie sobie roli administratora lub przejęcie kontenera w inny sposób.






ConfigMBeanImpl.install() i polecenie config:install Shell zabezpieczyły już równoważne ryzyko na własnej ścieżce kodu za pomocą sprawdzania ciągu finalname.contains(".."), ale to sprawdzenie nie zatrzymuje ścieżek bezwzględnych ani ucieczek opartych na dowiązaniach symbolicznych i nigdy nie zostało w ogóle zastosowane do ConfigRepositoryImpl.update() / createFactoryConfiguration().