C•CURE 9000 i victor: CVE-2026-106019 ujawnia hasła w logach
Instalator C•CURE 9000 i victor zapisywał dane uwierzytelniające jawnym tekstem. Sprawdź podatne buildy, usuń logi i zmień narażone hasła.
- AUTOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLIKACJA
- 6 listopada 2026
- CZAS CZYTANIA
- 10 min czytania
- TEMAT
- Tożsamość i dostęp
Johnson Controls ostrzega przed podatnością CVE-2026-106019 w instalatorach systemów C•CURE 9000 3.20 i victor 8.0. Podczas instalacji, aktualizacji albo naprawy podatny instalator mógł zapisywać dane uwierzytelniające w lokalnych plikach logów jako jawny tekst.
Problem dotyczy konkretnych buildów 3.20.597 i 8.0.597, udostępnianych do pobrania między 1 lipca a 18 września 2026 r. Samo przejście na poprawiony instalator nie usuwa wcześniej utworzonych logów i nie unieważnia ujawnionych haseł. Dlatego reakcja musi obejmować zarówno aktualizację, jak i poszukiwanie śladów oraz rotację sekretów.
Najważniejsze działanie: użyj instalatora build 3.20.607 lub nowszego, usuń wszystkie lokalne kopie podatnego pakietu, zidentyfikuj serwery instalowane lub naprawiane tym buildem, bezpiecznie usuń wskazane logi i zmień dane uwierzytelniające, które mogły się w nich znaleźć.
Co dokładnie ujawnia CVE-2026-106019
C•CURE 9000 jest platformą do zarządzania kontrolą dostępu, gośćmi, identyfikatorami i zdarzeniami bezpieczeństwa fizycznego. victor integruje zarządzanie wideo i systemami bezpieczeństwa. Poświadczenia używane przy wdrażaniu takich platform mogą mieć szerokie uprawnienia do baz danych, usług i komponentów administracyjnych.
Johnson Controls klasyfikuje błąd jako CWE-532 — wprowadzanie wrażliwych informacji do pliku dziennika. Lokalny użytkownik, proces o niskich uprawnieniach albo napastnik mający dostęp do systemu plików może odczytać pozostawione dane. Producent wskazuje również drugi scenariusz: logi mogły zostać automatycznie skopiowane do centralnego systemu monitorowania, narzędzia wsparcia albo kopii zapasowej, powiększając obszar poszukiwań.
Podatność otrzymała ocenę 8,8/10 w CVSS 4.0 (High). Johnson Controls nie informuje w komunikacie o potwierdzonym aktywnym wykorzystaniu. Wysoka ocena wynika z potencjalnego dostępu do administracyjnych poświadczeń i dalszego wpływu technicznego lub operacyjnego.
Które wersje C•CURE 9000 i victor są podatne
| Produkt | Podatny instalator | Poprawiony instalator |
|---|---|---|
| C•CURE 9000 3.20 | build 3.20.597 | build 3.20.607 lub nowszy |
| victor 8.0 | build 8.0.597 | build 8.0.607 lub nowszy |
Wadliwy build był dostępny przez ograniczony okres, ale to nie oznacza, że ryzyko wygasło 18 września. Kopia instalatora może nadal znajdować się w repozytorium wdrożeniowym, katalogu administratora, systemie dystrybucji oprogramowania lub u integratora. Serwer zainstalowany w tym okresie może również nadal przechowywać stare logi.
Gdzie szukać logów zawierających dane uwierzytelniające
Producent wymienia katalog C:\ProgramData\JCI\InstallerTemp\ oraz między innymi następujące pliki:
UnifiedInstallDashboard.log;CCurePortal_[TIMESTAMP].log;CCureWebClient_[TIMESTAMP].log;CCPortal_[TIMESTAMP].log;CrossFireWebService_[TIMESTAMP].log;VictorApplicationServer_[TIMESTAMP].log;vWSInstallerHelper.log;DBManager_Deploy_UNIFIEDSERVER-[TIMESTAMP].log;UnifiedServer_[TIMESTAMP].log.
Lista powinna być punktem startowym, nie jedynym zakresem. Sprawdź, czy te pliki trafiły do SIEM, systemu zgłoszeń, archiwum diagnostycznego, kopii zapasowej lub folderu udostępnionego integratorowi. Nie kopiuj podejrzanych logów do kolejnych miejsc bez potrzeby, ponieważ może to powielać sekret.
Plan reakcji dla firmy
1. Ustal, gdzie użyto builda 597
Przejrzyj historię wdrożeń, sumy kontrolne pakietów, dzienniki systemu dystrybucji oraz dokumentację integratora. Uwzględnij instalacje, aktualizacje i operacje naprawy od 1 lipca. Sam numer uruchomionej aplikacji nie zawsze dowodzi, którego instalatora użyto wcześniej.
2. Zastąp instalator i zablokuj ponowne użycie
Pobierz build 607 lub nowszy z autoryzowanego źródła. Usuń podatny pakiet z repozytoriów, udziałów i procedur odtwarzania. Zweryfikuj, czy narzędzia automatyzacji nie odwołują się do starej ścieżki lub cache.
3. Zabezpiecz dowody, a następnie usuń narażone logi
Jeżeli podejrzewasz nadużycie, najpierw skoordynuj zachowanie dowodów z zespołem reagowania. Następnie usuń wskazane logi zgodnie z komunikatem producenta i polityką retencji. Zwykłe przeniesienie pliku do innego katalogu nie eliminuje ryzyka.
4. Zmień wszystkie możliwe do odtworzenia sekrety
Rotacja powinna objąć konta administracyjne, bazy danych, konta usługowe i inne poświadczenia podawane instalatorowi. Sprawdź, czy to samo hasło nie było używane w innych systemach. Jeżeli log trafił do centralnej platformy, oceń również konta i osoby mające do niej dostęp.
5. Przejrzyj dostęp do plików i zachowanie systemu
Johnson Controls zaleca analizę zdarzeń, telemetrii i aktywności dotyczącej C•CURE 9000/victor sprzed 3 listopada 2026 r. Sprawdź audyt dostępu do katalogu instalatora, odczyty wykonywane przez konta nieadministracyjne, eksporty logów, nowe sesje administracyjne i nietypowe operacje w systemie kontroli dostępu.
Dlaczego to problem bezpieczeństwa fizycznego i cyberbezpieczeństwa
System kontroli dostępu nie jest zwykłą aplikacją biurową. Łączy tożsamość cyfrową z drzwiami, strefami, identyfikatorami, monitoringiem i reakcją ochrony. Utrata poświadczeń administratora może więc wpływać nie tylko na dane, ale również na ciągłość operacji i wiarygodność zapisów bezpieczeństwa.
Właścicielem reakcji nie powinien być wyłącznie zespół IT. Do oceny trzeba włączyć bezpieczeństwo fizyczne, administratorów baz danych, integratora, właściciela obiektu, SOC oraz osoby odpowiedzialne za ciągłość działania. Wspólny plan zmniejsza ryzyko, że rotacja hasła nieoczekiwanie przerwie działanie usług zależnych.
Przy większych środowiskach warto prowadzić katalog kont usługowych i zależności przed awarią. Nasz materiał o bezpiecznych hasłach i błędnych przekonaniach wyjaśnia, dlaczego unikalność i kontrolowana rotacja są ważniejsze niż kosmetyczne zmiany jednego znaku.
Fakty źródłowe i wnioski Breachroad
Johnson Controls potwierdza podatne i naprawione buildy, okres dostępności wadliwego instalatora, zapisywanie danych uwierzytelniających jawnym tekstem, przykładowe ścieżki logów oraz konieczność ich usunięcia i rotacji poświadczeń. Producent nie zgłasza w komunikacie aktywnej kampanii wykorzystującej CVE-2026-106019.
Rozszerzenie poszukiwań na SIEM, kopie zapasowe i systemy zgłoszeń, wspólna reakcja IT i ochrony fizycznej oraz kolejność bezpiecznej rotacji są rekomendacjami Breachroad. Organizacje mogą przećwiczyć obsługę sekretów i incydentów na szkoleniach cyberbezpieczeństwa dla firm, a audyt bezpieczeństwa IT może zweryfikować uprawnienia, retencję logów i zależności kont usługowych.
FAQ: CVE-2026-106019 w C•CURE 9000 i victor
Czy wystarczy zainstalować poprawiony build 607?
Nie. Nowy instalator zapobiega tworzeniu wadliwych logów w przyszłości, ale nie usuwa starych plików i nie zmienia ujawnionych danych uwierzytelniających.
Kto może odczytać poświadczenia?
Według producenta lokalny użytkownik lub proces mający dostęp do odpowiednich plików. Ryzyko obejmuje też systemy, do których logi zostały skopiowane lub zarchiwizowane.
Czy podatność jest aktywnie wykorzystywana?
Komunikat Johnson Controls nie zgłasza potwierdzonego aktywnego wykorzystania. Organizacja powinna mimo to sprawdzić dostęp do plików i zmienić narażone sekrety.
Czy trzeba zmienić wszystkie hasła w systemie?
Priorytetem są poświadczenia podawane podczas instalacji, aktualizacji lub naprawy podatnym buildem oraz sekrety, które mogły trafić do logów. Zakres powinien wynikać z analizy plików i zależności usług.
Źródła pierwotne: Johnson Controls — JCI-PSA-2026-45, Johnson Controls — lista biuletynów bezpieczeństwa, Johnson Controls — materiały hardeningowe.
