Według Drupal Security Team poprawka bezpieczeństwa ma ukazać się 20 maja między 17:00 a 21:00 UTC. Zapowiedź z 18 maja zastrzega, że problem nie dotyczy wszystkich konfiguracji, a szczegóły pojawią się wraz z aktualizacją. Właściciele portali firmowych i publicznych powinni już teraz uzgodnić dostępność administratora, przygotowanie testów oraz okno wdrożenia.

Kto odbierze komunikat o poprawce do portalu, jeśli pojawi się on 20 maja pod koniec zapowiedzianego przedziału? To pytanie zadajmy administratorowi i właścicielowi usługi jeszcze 19 maja. Odpowiedź „zajmiemy się tym po publikacji” pozostawia bez ustalenia wykonawcę i osobę, która zdecyduje o zmianie. Przy zapowiedzi Drupal Security Team znamy już termin, do którego można odnieść przygotowania. Proponowany sprawdzian gotowości sprowadza się do jednego pytania. Poprośmy o wskazanie osoby, która przeczyta komunikat, sprawdzi jego znaczenie dla własnego portalu i przekaże wynik właścicielowi usługi. Uzgodnijmy też, kto będzie dostępny do wykonania potrzebnej aktualizacji i odebrania testów. Takie ustalenia można rozpocząć przed poznaniem szczegółów podatności.

Zapowiedź wyznacza termin, zakres wymaga sprawdzenia

Jak podaje Drupal Security Team w zapowiedzi z 18 maja, wydanie jest planowane na 20 maja, w przedziale 17:00–21:00 UTC. W planie prac potraktujmy te godziny jako okno publikacji. Nie wpisujmy automatycznie godziny 21:00 jako terminu zakończenia aktualizacji własnego portalu. Termin wdrożenia i czas na testy uzgodnijmy osobno, z uwzględnieniem momentu udostępnienia poprawki.

Zastrzeżenie Drupal Security Team, że nie wszystkie konfiguracje są dotknięte, pozostawia zadanie dla administratora: po publikacji szczegółów powinien porównać je z konfiguracją utrzymywanej usługi. Do tego czasu nie oznaczajmy konkretnego portalu jako objętego problemem ani jako wolnego od niego. Przygotujmy miejsce na wynik sprawdzenia oraz podstawę takiej oceny.

Zapowiedź Drupal Security Team nie ujawnia mechanizmu podatności. W przygotowaniu do 20 maja skupmy się więc na kolejności decyzji: od odczytania komunikatu, przez ocenę własnej konfiguracji, po ustalenie potrzebnej zmiany. Szczegółową instrukcję techniczną oprzyjmy dopiero na informacjach towarzyszących aktualizacji.

Gotowość portalu na 20 maja powinna obejmować wykonawcę, testy i uzgodnione okno wdrożenia.

Dyżur administratora wymaga potwierdzenia dostępności

Przed 20 maja sprawdźmy własną procedurę obsługi aktualizacji jednym pytaniem: czy wskazany administrator potwierdził dostępność w zapowiedzianym oknie? Traktujmy to jako zalecenie organizacyjne, bez przypisywania komukolwiek zaniedbań. Sam wpis w planie prac nie powinien zastępować uzgodnienia z osobą, która ma przeczytać komunikat i wykonać zmianę.

W zadaniu dotyczącym portalu opartego na Drupal zapiszmy osobno odbiór informacji i wykonanie aktualizacji. Jeżeli odpowiadają za nie różne osoby, ustalmy sposób przekazania wyniku oceny konfiguracji. Właściciel usługi powinien wiedzieć, od kogo otrzyma wiadomość o potrzebie wdrożenia i do kogo skieruje pytanie o jego status.

Na 20 maja przygotujmy również opis testów: co sprawdzimy w portalu, jakiego wyniku oczekujemy i kto go zaakceptuje. Nie wyznaczajmy zakresu tych prób na podstawie domysłów o nieujawnionej podatności. Zacznijmy od uzgodnienia z właścicielem usługi, które działanie portalu test ma potwierdzić po zmianie, a po publikacji szczegółów zweryfikujmy przygotowany plan.

Właściciel portalu powinien zatwierdzić warunki wdrożenia

W informacji dla zarządu na 19 maja rozdzielmy znane dane od otwartych decyzji. Znane są zapowiedziane godziny publikacji; do ustalenia we własnej organizacji pozostają obsada, testy i termin wykonania potrzebnej zmiany. Oceny tego, czy własny portal wymaga aktualizacji z powodu zapowiedzianego problemu, nie zastępujmy ogólnym statusem „bezpieczeństwo sprawdzone”.

Właściciel portalu powinien uzgodnić z administratorem, kto zatwierdzi rozpoczęcie wdrożenia, kto odbierze wynik testów oraz kto przyjmie problem z ich zakończeniem. W notatce dotyczącej 20 maja zapiszmy te role tak, by wykonawca mógł skontaktować się z osobą decyzyjną. Prośba o dyżur powinna obejmować potwierdzenie tego kontaktu.

Zapowiedź Drupal Security Team nie pozwala określić kosztu prac ani czasu ewentualnej niedostępności własnego portalu. Nie podawajmy ich jako skutków zapowiedzianej poprawki. Poprośmy administratora o ocenę warunków wdrożenia we własnej usłudze, a to, czego nie rozstrzygnie, wpiszmy do planu na 20 maja wraz z osobą odpowiedzialną za wyjaśnienie.

Zastrzeżenie dotyczące konfiguracji Drupal powinno prowadzić do sprawdzenia własnego portalu przed decyzją o zamknięciu zadania.

Polski portal potrzebuje ustaleń dotyczących własnej usługi

Dla polskiego właściciela portalu firmowego lub publicznego praktycznym punktem odniesienia jest dostępność administratora 20 maja. W zaproszeniu na dyżur zachowajmy oznaczenie UTC przy godzinach ze źródła i potwierdźmy, że uczestnicy jednakowo rozumieją termin. Termin publikacji poprawki oraz uzgodniony termin wdrożenia zapiszmy w osobnych polach zadania.

Na podstawie zapowiedzi Drupal Security Team nie można wskazać polskich ofiar ani określić, ilu krajowych portali dotyczy problem. Nie ma zatem podstaw do przypisywania go konkretnej instytucji. W informacji wewnętrznej dotyczącej Drupal skupmy się na własnej usłudze: odpowiedzialności za ocenę konfiguracji, gotowości administratora oraz przygotowaniu testów. Jeżeli któregoś ustalenia brakuje, opiszmy dokładnie, co pozostaje do potwierdzenia przed oknem publikacji.

Co z tym zrobić w poniedziałek

Skoro zapowiedź dotyczy 20 maja, te przygotowania wykonaj już 19 maja. Na każdy punkt przeznacz do 30 minut; celem jest przygotowanie zadania, a samo wdrożenie wymaga osobnego planu.

  1. Ustal obsadę na 20 maja. Wyślij administratorowi i właścicielowi portalu prośbę o potwierdzenie dostępności w oknie 17:00–21:00 UTC. Wpisz w zadaniu odbiorcę komunikatu, wykonawcę aktualizacji i osobę zatwierdzającą zmianę; zaznacz oczekujące potwierdzenia.
  2. Przygotuj ocenę konfiguracji Drupal. Dołącz zapowiedź do zadania i utwórz pola na wynik sprawdzenia własnego portalu oraz jego uzasadnienie. Przypisz administratorowi uzupełnienie oceny po publikacji szczegółów; do tego czasu pozostaw zakres jako nieustalony.
  3. Rozpisz testy i uzgodnienie okna wdrożenia. Przygotuj krótką listę działań portalu do sprawdzenia po zmianie, z oczekiwanym wynikiem i osobą odbierającą test. Zapisz, kto potwierdzi termin wdrożenia po otrzymaniu informacji zapowiedzianych na 20 maja.

Na 19 maja miarą przygotowania portalu powinna być możliwość wskazania, kto podejmie kolejną decyzję po komunikacie Drupal Security Team. Od administratora wymagajmy uzasadnionej oceny konfiguracji, a od właściciela usługi uzgodnienia warunków potrzebnej zmiany. Rezerwacja dyżuru na 20 maja powinna prowadzić do takiego podziału odpowiedzialności.

Źródła

  1. Drupal Security Team: Upcoming highly critical release on May 20, 2026 - PSA-2026-05-18, publikacja: 18 maja 2026.

Redakcja cyberinsight.pl.