Większość właścicieli stron na Drupalu, z którymi rozmawiam, robi aktualizacje bezpieczeństwa Drupala tak samo. To poprawki, które Security Team Drupala publikuje dla core i modułów contrib. Developer widzi security advisory. Ticket trafia do następnego sprintu. Poprawka wchodzi na produkcję po kilku dniach, czasem po dwóch tygodniach.
Przez lata to wystarczało. Dziś już nie.
Powód jest prosty: AI. Model językowy potrafi przeczytać poprawkę bezpieczeństwa i napisać na jej podstawie działający atak. W maju 2026 roku zajęło to badaczom 51 minut.
Na Drupal Slacku widziałem jeszcze krótszą wersję: „stworzenie exploita z dowolnego SA zajmuje mniej niż 10 minut”.
Traktuję to poważnie. W tym artykule pokazuję, co się zmieniło i jak dziś przygotować się do każdego security release. Wyjaśniam też, dlaczego uważam, że aktualizacje bezpieczeństwa to już nie zadanie dla developera. To zadanie dla zespołu supportu z umową.
W tym artykule:
- Co się zmieniło w bezpieczeństwie Drupala między 2018 a 2026 rokiem?
- Dlaczego security advisory to dziś instrukcja ataku?
- Co szybsze exploity oznaczają dla Twojej strony na Drupalu?
- Jak przygotować się do każdej aktualizacji bezpieczeństwa Drupala?
- Dlaczego aktualizacje bezpieczeństwa to zadanie dla supportu, a nie developera?
- Moja rekomendacja
Co się zmieniło w bezpieczeństwie Drupala między 2018 a 2026 rokiem?
Najlepiej widać to na dwóch krytycznych lukach w Drupal core. Dzieli je osiem lat i jedno narzędzie: AI.
W marcu 2018 roku Drupal opublikował SA-CORE-2018-002, znane jako Drupalgeddon 2. Na publiczny kod exploita trzeba było czekać około dwóch tygodni. Firmy hostingowe miały czas, żeby dodać ochronę. Właściciele stron mieli czas, żeby zaplanować aktualizację.
W maju 2026 roku Drupal opublikował SA-CORE-2026-004. To był SQL injection w core, CVE-2026-9082. Badacze z Miggo Security opisali, jak zbudowali na nim exploit. Od wykrycia poprawki do działającego exploita minęło 51 minut. Użyli Claude i wydali na tokeny mniej niż 10 dolarów. Człowiek nadal musiał w jednym miejscu podpowiedzieć modelowi.
Dwa dni później Drupal zaktualizował advisory: wykryto próby wykorzystania luki „in the wild”. CISA dodała ją do katalogu Known Exploited Vulnerabilities. Imperva naliczyła ponad 15 000 prób ataku. Dotyczyły prawie 6000 stron na Drupalu w 65 krajach.
Dwa tygodnie w 2018 roku. 51 minut w 2026 roku. To cała historia.
Security Team Drupala widzi to samo. W ogłoszeniu PSA-2026-10-12 o krytycznym wydaniu core napisał wprost, że exploity mogą powstać „w ciągu godzin lub dni”. Poprosił też właścicieli stron, żeby zarezerwowali czas na aktualizację w dniu wydania.
Przeczytaj również: Bezpieczeństwo Drupala. Dobre praktyki, proaktywne środki i polecane moduły
Dlaczego security advisory to dziś instrukcja ataku?
Każde wydanie bezpieczeństwa publikuje poprawkę. Poprawka to diff w kodzie. Diff pokazuje, która funkcja była podatna. Pokazuje też, jakich danych wejściowych nie sprawdzała.
Przed AI zamiana diffa w atak wymagała doświadczonej osoby i kilku dni pracy. Teraz model czyta diff i znajduje podatną ścieżkę. Pisze zapytanie i testuje je na świeżej instalacji Drupala. Człowiek poprawia po drodze kilka błędów. Bariera umiejętności zniknęła. Koszt jest niższy niż lunch.
Atakujący nie wybierają też celów ręcznie. Skanują internet w poszukiwaniu stron na Drupalu, sprawdzają wersję i atakują. Dlatego Imperva widziała tysiące prób w ciągu kilku dni.
Pytanie nie brzmi już „czy komuś będzie się chciało nas atakować?”. Pytanie brzmi „ile godzin po wydaniu poprawka będzie na naszej produkcji?”.
Co szybsze exploity oznaczają dla Twojej strony na Drupalu?
Widzę trzy konsekwencje.
Okno wydania to Twój termin. Wydania bezpieczeństwa Drupal core pojawiają się w środy, w ogłoszonym oknie czasowym. Jeśli Twoja aktualizacja wchodzi w czwartek, strona jest otwarta przez całą dobę. Skanery w tym czasie już działają.
Nie załatasz wersji bez wsparcia. Poprawki bezpieczeństwa dostają tylko wspierane gałęzie Drupala. W październiku 2026 roku były to 11.4.x, 11.3.x i 10.6.x. Drupal 10.5, 11.2 i starsze wersje nie są już wspierane i nie dostają poprawek. Twoja strona działa na starszej wersji? Wtedy w dniu wydania nie pomoże Ci żadna umowa supportowa. Najpierw potrzebujesz aktualizacji wersji Drupala do wspieranej gałęzi.
Core to tylko połowa pracy. 9 października 2026 roku Security Team opublikował 26 advisories dla modułów contrib w jeden dzień. Jedno z nich było oznaczone jako highly critical. Każdy moduł contrib na Twojej stronie to potencjalne wejście dla atakującego. Ktoś musi czytać te advisories, sprawdzać, które dotyczą Twojej strony, i aktualizować.
Drupal Steward daje pewną ochronę. Security Team mówi jednak wprost: nie przed wszystkimi exploitami. Web application firewall kupuje Ci kilka godzin. Nie zastępuje poprawki.
Przeczytaj również: Drupal 10: koniec wsparcia, data EOL, ryzyka i plan aktualizacji
Jak przygotować się do każdej aktualizacji bezpieczeństwa Drupala?
Większość tej pracy robisz przed dniem wydania, nie w jego trakcie. Tak bym to zrobił, gdybym był właścicielem strony na Drupalu:
- Bądź na wspieranej gałęzi. Sprawdź swoją wersję teraz, nie w dniu wydania. Jeśli jesteś na wersji bez wsparcia, zaplanuj aktualizację od razu.
- Trzymaj się najnowszego patch release. Security Team prosi o to przed każdym krytycznym wydaniem. Dzięki temu aktualizacja bezpieczeństwa to zmiana jednej linii. Nie walka z zależnościami w Composerze.
- Utrzymuj staging zgodny z produkcją. Ta sama wersja PHP, ta sama baza danych, te same moduły. Uruchamiaj testy regularnie, żeby wiedzieć, jak wygląda „zielony” wynik.
- Ustal, kto wdraża i kto akceptuje. Z imienia i nazwiska, z osobą zastępczą. Wydania core przychodzą zwykle po południu i wieczorem czasu europejskiego. Często już po godzinach pracy zespołu.
- Przygotuj rollback. Kopia bazy danych i otagowany release, do którego wrócisz w kilka minut.
- Obserwuj logi po wdrożeniu. Szukaj nietypowych żądań, nowych kont administratorów i plików PHP w katalogu files.
- Pamiętaj o contrib. Advisories dla modułów wychodzą co tydzień, nie tylko razem z core.
Nic z tego nie jest trudne. Wszystko wymaga czasu, dostępów i kogoś, kto zna projekt. To jest prawdziwy problem.
Więcej o samym procesie piszemy w artykule Jak poprawnie zadbać o aktualizację Drupala?. Jeśli nie wiesz, w jakim stanie jest Twoja strona, zacznij od audytu bezpieczeństwa Drupala.
Dlaczego aktualizacje bezpieczeństwa to zadanie dla supportu, a nie developera?
Ticket w następnym sprincie działał, gdy exploit powstawał dwa tygodnie. Nie działa, gdy powstaje w 51 minut.
Policz to. Atakujący potrzebuje mniej niż godziny. Jeśli Twój proces aktualizacji trwa trzy dni, przegrywasz za każdym razem. Wygrywasz tylko wtedy, gdy poprawka jest na produkcji w ciągu kilku godzin od wydania. Za każdym razem, bez zwoływania spotkania.
Twoi developerzy potrafią uruchomić Composera. Umiejętności to nie problem. Problemem są dostępny czas i odpowiedzialność:
- Ktoś śledzi kalendarz wydań bezpieczeństwa Drupala i listę advisories co tydzień.
- Ktoś dba o działający staging, żeby poprawkę dało się przetestować w kilka minut.
- Ktoś ma zarezerwowane godziny w dniu wydania, a nie pełny backlog sprintu.
- Ktoś bierze odpowiedzialność, gdy aktualizacja zepsuje moduł o 20:00.
Często widzę coś odwrotnego. Poprzednia agencja „rzuci okiem”. Albo jedyna osoba, która zna stronę, jest na urlopie. Takie sytuacje opisujemy też w tekście 10 typowych problemów przy utrzymaniu serwisu na Drupalu.
Potrzebujesz zespołu, który odpowiada za stronę. Nie ticketu, który na taki zespół czeka.
Moja rekomendacja
Traktuj aktualizacje bezpieczeństwa Drupala jak usługę z umową, a nie jak zadanie w backlogu. To oznacza zarezerwowane godziny, konkretny zespół i ustalony czas reakcji.
Do tego służy nasze wsparcie Drupala. Dostajesz miesięczny pakiet gwarantowanych godzin i zespół, który zna Twój projekt. Dostajesz też jasny proces na dni krytycznych wydań.
Jak to wygląda w praktyce:
- Monitoring aktualizacji bezpieczeństwa. Śledzimy advisories dla core i contrib. Mówimy Ci, które dotyczą Twojej strony, zanim zapytasz.
- Zarezerwowany czas zespołu. Godziny są zaplanowane z góry. Wydanie bezpieczeństwa nie konkuruje z Twoim sprintem.
- SLA na incydenty. Gwarantowany czas reakcji na krytyczne zgłoszenia, od jednej godziny w pakiecie Enterprise.
- Środowiska i proces. Środowiska staging i dev, Jira Service Desk i Slack. Wycena przed rozpoczęciem pracy i miesięczny raport wykorzystanych godzin.
- Bez długiego zobowiązania. Minimum trzy miesiące, potem miesięczny okres wypowiedzenia.
Nie wiesz, czy lepszy będzie support, czy stały zespół? Porównujemy to w artykule Zespół deweloperski czy wsparcie - jaką usługę wybrać dla swojej strony?.
Chcesz, żeby ktoś odpowiadał za bezpieczeństwo Twojego Drupala?
Tak pracujemy na przykład z Exide Group. Przejęliśmy ich serwis zbudowany na wczesnej wersji Drupala 8, w którym bezpieczne wdrażanie poprawek było trudne. Uporządkowaliśmy kod, wprowadziliśmy Composera, środowiska testowe i Continuous Integration. Od tego czasu regularnie aktualizujemy i rozwijamy serwis. Szczegóły znajdziesz w case study Exide Group.
Pracujemy z Drupalem i PHP od ponad 15 lat. Mamy certyfikat ISO 27001:2022. To pomaga, gdy Twój dział bezpieczeństwa albo zakupów zaczyna zadawać pytania.
Następne krytyczne wydanie przyjdzie na pewno. Porozmawiaj z nami o wsparciu Drupala i spraw, żeby aktualizacje bezpieczeństwa były czyimś obowiązkiem.
