Według Cisco poprawienie podatności CVE-2026-20184 w usłudze Webex pozostawia działanie po stronie klientów korzystających z trust anchors w integracji SSO. Aktualizacja komunikatu z 16 kwietnia doprecyzowała ten zakres. Właściciele usług spotkań i firmowej tożsamości sprawdzają więc konfigurację, przypisują odpowiedzialność za certyfikat i planują test ciągłości logowania.

Czy informacja „dostawca poprawił usługę” wystarcza, żeby zamknąć alert dotyczący Webex? W piątek 17 kwietnia odpowiedź oprzyjmy także na uzupełnieniu komunikatu, które pojawiło się poprzedniego wieczoru. Cisco PSIRT opublikowało pierwotną informację 15 kwietnia o 16:00 UTC, a wersję 1.1 datuje na 16 kwietnia, 18:52 UTC. Ta druga data ma znaczenie dla decyzji właściciela usługi, bo doprecyzowanie wskazuje konfigurację wymagającą uwagi klienta. Aktualizacja daje więc powód do ponownego sprawdzenia podstawy zamknięcia alertu, jeśli taka decyzja już zapadła. Pytanie do administratora powinno dotyczyć ustawień własnej organizacji i pozostałego zadania, zamiast kończyć się na potwierdzeniu przeczytania wiadomości o poprawce.

Błąd walidacji certyfikatu dotyczył integracji Webex SSO

Jak podaje Cisco PSIRT w komunikacie o CVE-2026-20184, błąd walidacji certyfikatu w integracji Webex SSO z Control Hub umożliwiał podszycie się pod użytkownika. Wersja 1.1 doprecyzowała, że problem dotyczył organizacji korzystających w tej integracji z trust anchors. Ten warunek powinien wyznaczać zakres przeglądu po stronie klienta.

Zacznijmy od pytania, czy konfiguracja SSO własnej organizacji odpowiada opisanemu warunkowi. Sama obecność Webex w wykazie usług tego nie rozstrzyga. W zapisie kontroli administrator wskazuje, jakie ustawienia sprawdził i na jakiej podstawie ocenił użycie trust anchors. Jeżeli administrator nie ma jeszcze takiej odpowiedzi, pozostawmy wynik jako nieustalony i przypiszmy zadanie sprawdzenia konfiguracji.

Przy ocenie CVE-2026-20184 odróżnijmy możliwość podszycia się od potwierdzenia takiego zdarzenia w organizacji. Własny przegląd powinien odpowiadać na pytanie o konfigurację, bez przesądzania historii jej wykorzystania.

Alert dotyczący Webex zamykajmy na podstawie sprawdzonej konfiguracji i wykonanych zadań klienta.

Wersja 1.1 powinna trafić do oceny zamknięcia alertu

Rozważmy hipotetyczną procedurę, w której alert dotyczący usługi SaaS zamyka się po otrzymaniu informacji o poprawce dostawcy. Przy Webex taka reguła wymaga dodatkowego pytania: czy komunikat przewiduje także czynność klienta? To test kompletności procedury.

Oznaczenie wersji 1.1 oraz wynik weryfikacji SSO w wewnętrznym zgłoszeniu pozwolą osobie zatwierdzającej zamknięcie sprawdzić, czy decyzja uwzględnia doprecyzowanie z 16 kwietnia.

Zakres pracy zależy od konfiguracji Webex w danej organizacji, dlatego instrukcję dostawcy odnieśmy do sprawdzonych ustawień. Gdy wynik pozostaje nieustalony, zgłoszenie ma zawierać konkretne pytanie o SSO oraz termin uzyskania odpowiedzi.

Certyfikat i test logowania potrzebują właścicieli

Właściciel usługi spotkań powinien uzgodnić z właścicielem firmowej tożsamości, kto przygotuje zmianę w Webex i kto potwierdzi jej zakończenie.

W zgłoszeniu dotyczącym certyfikatu określmy warunek zakończenia pracy: wykonanie potrzebnej zmiany oraz zapis wyniku uzgodnionego testu SSO. Samo przypisanie zadania administratorowi to etap przygotowania. Potrzebna jest również osoba, która oceni wynik próby logowania i zdecyduje, jeżeli odbiegnie on od oczekiwania. Ustalenie tej osoby powinno poprzedzać zatwierdzenie planu zmiany.

Koszt prac i czas ewentualnej przerwy w Webex każda organizacja ocenia sama. W tym celu właściciele usługi i tożsamości powinni określić zakres zadania, termin wykonania i sposób sprawdzenia ciągłości logowania. Dopiero te ustalenia trafiają do wewnętrznej informacji o pozostałej pracy.

Zmiana certyfikatu w Webex powinna mieć wskazanego wykonawcę oraz osobę odbierającą wynik testu logowania.

Polski odbiorca powinien sprawdzić własne SSO

Dostępne informacje nie potwierdzają polskiego incydentu związanego z CVE-2026-20184. Nie pozwalają też ocenić liczby krajowych organizacji korzystających z opisanej konfiguracji. Dla polskiego właściciela usługi punktem wyjścia pozostaje zatem pytanie o własne Webex SSO. Polska siedziba firmy nie jest odpowiedzią na pytanie o użycie trust anchors.

W informacji dla zarządu polskiej organizacji przydadzą się wynik tego sprawdzenia, wskazanie osoby odpowiedzialnej za certyfikat oraz status testu logowania. Jeśli któregoś ustalenia brakuje, nazwijmy je wprost. Do takiej notatki nie dopisujmy krajowej skali ataków ani skutków finansowych, bo dostępne informacje ich nie określają. Do uzasadnienia przeglądu wystarczy warunek dotyczący konfiguracji SSO, który opisało Cisco.

Co z tym zrobić w poniedziałek

Na każdą z poniższych czynności przeznacz do 30 minut. To zakres wstępnego sprawdzenia i przygotowania prac dotyczących Webex; zakończenie samej zmiany wymaga osobnego potwierdzenia.

  1. Sprawdź zakres w Control Hub. Przejrzyj dostępną konfigurację SSO pod kątem użycia trust anchors. Zapisz wynik i podstawę ustalenia. Jeśli brakuje dostępu lub odpowiedzi, wskaż osobę, która uzupełni sprawdzenie, oraz termin przekazania wyniku.
  2. Przypisz odpowiedzialność za certyfikat. Dla konfiguracji objętej komunikatem zapisz wykonawcę zadania i osobę zatwierdzającą plan. Dołącz komunikat Cisco w wersji 1.1, a z właścicielem firmowej tożsamości ustal następny krok dotyczący zmiany certyfikatu.
  3. Przygotuj test ciągłości logowania. Zapisz, kto przeprowadzi próbę logowania SSO do Webex po zmianie, jaki wynik uznacie za prawidłowy i gdzie go odnotujecie. Wskaż osobę, do której trafi nieudana próba; termin testu powiąż z wykonaniem zmiany.

Przy Webex odpowiedzialność za zamknięcie alertu powinna obejmować sprawdzenie zadania pozostawionego klientowi. Wymagajmy podstawy decyzji odnoszącej się do własnego SSO oraz potwierdzenia zakończenia potrzebnych prac. Status poprawki dostawcy powinien rozpoczynać tę ocenę, zamiast zastępować jej wynik.

Źródła

  1. Cisco PSIRT: Cisco Webex Services Certificate Validation Vulnerability, publikacja: 15 kwietnia 2026, 16:00 UTC; wersja 1.1: 16 kwietnia 2026, 18:52 UTC.

Redakcja cyberinsight.pl.