34 łatki jednego dnia i exploit w 51 minut: bezpieczeństwo Drupala w 2026 roku.

21 października 2026 roku Drupal Security Team opublikował 34 biuletyny bezpieczeństwa dla modułów jednego dnia. Dwa z nich opisywały zdalne wykonanie kodu, czyli lukę, przez którą można przejąć serwer. Tydzień wcześniej krytyczną poprawkę dostał sam rdzeń. Pięć miesięcy wcześniej luka w rdzeniu była atakowana na tysiącach stron dwa dni po publikacji poprawki.

Ten tekst nie straszy. Pokazuje skalę w liczbach, żeby łatwiej było odpowiedzieć na jedno pytanie: czy ktoś pilnuje mojej strony co tydzień, czy raz na kwartał?

Liczby, które warto zapamiętać.

Jak często wychodzą poprawki.

Każda poprawka bezpieczeństwa w Drupalu ma publiczny biuletyn (Security Advisory, w skrócie SA) na drupal.org. Numeracja jest roczna, więc liczbę biuletynów w danym roku łatwo policzyć.

Liczba biuletynów dla modułów rośnie od trzech lat, ale prawdziwy skok przyszedł w połowie 2026 roku:

Od czerwca biuletynów jest kilka razy więcej, bo błędy znajduje się szybciej. W maju 2026 Drupal Association dostało grant od programu Alpha-Omega na wyszukiwanie podatności z pomocą AI. Po sześciu tygodniach raportowało ponad dziesięć opublikowanych biuletynów i ponad 30 zgłoszonych problemów. Napisało też wprost, że wąskim gardłem nie jest już znajdowanie błędów, tylko czas wolontariuszy, którzy muszą je zweryfikować i naprawić. Podobne zjawisko opisywałem przy lukach PHP2Shell — tam też większość błędów znalazły narzędzia AI.

Uczciwie trzeba dodać: więcej biuletynów nie znaczy, że kod Drupala jest gorszy niż rok temu. Znaczy, że błędy, które w nim były, wychodzą na jaw szybciej. Dla właściciela strony efekt jest jednak ten sam — jest więcej poprawek do wdrożenia, a każda z nich jest publiczną instrukcją, gdzie szukać dziury.

Biuletyny Drupala wychodzą zwykle w środy. W 2026 roku w zasadzie nie było środy bez nowych poprawek.

To nie dotyczy tylko niszowych modułów.

Wiele biuletynów dotyczy modułów z kilkuset instalacjami. Na liście z ostatnich dwóch lat są jednak też moduły, które ma niemal każda strona firmowa na Drupalu. Liczby instalacji to dane z drupal.org z tygodnia 11 października 2026 roku. Liczą tylko strony, które raportują użycie, więc w rzeczywistości są wyższe.

Osobna kategoria to moduł AI, który wchodzi w skład Drupal CMS. Od początku 2025 roku dostał kilkanaście biuletynów, w tym krytyczne zdalne wykonanie kodu i CSRF. Jeśli strona korzysta z integracji z modelami językowymi, to jedna z najczęściej łatanych części całego ekosystemu.

Coraz częściej pojawiają się też biuletyny oznaczone jako „Unsupported”. Taki biuletyn oznacza, że w module jest znana luka, a opiekun modułu jej nie naprawił. Moduł zostaje oficjalnie porzucony i aktualizacji nie będzie. Jedyne wyjście to zastąpić go czymś innym albo usunąć.

Okno na reakcję się skraca.

Najlepszy przykład z 2026 roku to biuletyn SA-CORE-2026-004 z 20 maja: SQL injection w rdzeniu (CVE-2026-9082), możliwa bez logowania na stronach z bazą PostgreSQL. Przebieg wyglądał tak:

• 20 maja, 5:12 UTC — firma Miggo Security wykrywa publiczną poprawkę.
• 20 maja, 6:03 UTC — Miggo ma działający exploit, napisany z pomocą Claude za mniej niż 10 dolarów. Zastrzega, że w kilku miejscach potrzebna była pomoc człowieka.
• 22 maja — Drupal podnosi ocenę zagrożenia do 23/25, bo wykrywa próby ataku. Imperva odnotowuje w pierwszych dwóch dniach ponad 15 tys. prób ataku na prawie 6 tys. stron w 65 krajach.
• Następnie — amerykańska agencja CISA wpisuje lukę do katalogu podatności wykorzystywanych w atakach.

To nie jest nowy wzorzec, tylko szybszy. Przy luce Drupalgeddon w 2014 roku zespół bezpieczeństwa Drupala ostrzegał, że strony niezałatane w ciągu 7 godzin trzeba traktować jak przejęte. Różnica polega na tym, że dziś do napisania exploita nie potrzeba już wyspecjalizowanego zespołu.

Październikowa luka w rdzeniu (SA-CORE-2026-014, zdalne wykonanie kodu w module Field UI) pokazuje inny problem. Sam rdzeń nie jest na nią bezpośrednio podatny, ale według biuletynu kilka popularnych modułów otwiera do niej drogę, w tym jedną bez logowania. O tym, czy strona jest zagrożona, decyduje więc cały zestaw modułów, a nie tylko wersja rdzenia.

Ile stron działa bez wsparcia.

Poprawki dostają tylko wspierane gałęzie Drupala. W październiku 2026 roku są to 10.6, 11.3 i 11.4. Według danych drupal.org z 11 października 2026:

Do tego dochodzi Drupal 7, który nie dostaje poprawek od 5 stycznia 2025 roku. Tabela drupal.org nie podaje go osobno, ale różnica między liczbą wszystkich stron na Drupalu (823 823) a stron na wersjach 8–12 to ok. 177 tys. — to głównie strony na Drupalu 7. Według W3Techs (sierpień 2026) Drupal 7 to nadal 29,6% wykrytych stron na Drupalu, a wszystkie wersje bez wsparcia razem — ok. 50%.

W praktyce oznacza to, że mniej więcej co druga strona na Drupalu nie dostanie poprawki na kolejną lukę z listy powyżej. A że strona jest na wspieranej gałęzi, jeszcze nie znaczy, że ma zainstalowane najnowsze poprawki. Tego statystyki drupal.org nie pokazują.

Jak pilnować własnej strony.

Przy takim tempie poprawek miesięczny przegląd aktualizacji, który do niedawna wystarczał, przestaje wystarczać. Rytm, który sprawdza się w 2026 roku:

1. Co tydzień, w środę lub czwartek, sprawdź nowe biuletyny. Najprościej: włącz w module Update Status powiadomienia e-mail o aktualizacjach bezpieczeństwa albo uruchamiaj w projekcie composer audit lub drush pm:security. Biuletyny można też śledzić przez kanał RSS na drupal.org/security.
2. Poprawki krytyczne wdrażaj w ciągu doby. Biuletyny oznaczone jako „Critical” i „Highly critical” nie powinny czekać na cotygodniowy przegląd. Jeśli aktualizacja nie jest możliwa od razu, biuletyn zwykle podaje obejście, np. wyłączenie podatnego modułu.
3. Testuj na kopii strony. Szybkie wdrożenie jest bezpieczne tylko wtedy, gdy jest gdzie je wcześniej sprawdzić. Bez kopii strony każda aktualizacja to ryzyko awarii, a to najczęstszy powód, dla którego firmy je odkładają.
4. Pilnuj wersji minor rdzenia. Wsparcie kończy się nie tylko dla wersji głównych. Drupal 10.5 i 11.2 przestały dostawać poprawki, choć to wciąż „dziesiątka” i „jedenastka”. Przejście na nowszą gałąź warto planować z wyprzedzeniem.
5. Usuwaj zbędne i porzucone moduły. Każdy moduł to kolejne biuletyny do śledzenia. Moduł, który jest włączony, ale nieużywany, albo moduł z biuletynem „Unsupported” to ryzyko bez żadnej korzyści.
6. Miej kopię zapasową, którą ktoś przetestował, i monitoring dostępności. Jeśli mimo wszystko coś się stanie, to one decydują, czy przestój potrwa godzinę, czy tydzień.

Szerzej o tym, dlaczego aktualizacje chronią stronę, piszę w tekście o aktualizacjach Drupala, a o kosztach — w tekście ile kosztuje utrzymanie strony Drupal.

Najczęściej zadawane pytania.

Jak często wychodzą poprawki bezpieczeństwa do Drupala? W 2026 roku praktycznie co tydzień. Do 21 października Drupal Security Team opublikował 253 biuletyny dla modułów i 16 dla rdzenia. Publikacje przypadają zwykle na środę.

Czy poprawki dotyczą tylko mało popularnych modułów? Nie. W 2026 roku łatane były m.in. Webform (357 tys. instalacji, 20 biuletynów jednego dnia), Paragraphs, CAPTCHA, Gin, Colorbox, Entity Browser i sam rdzeń, w tym luka SQL injection wykorzystywana w atakach dwa dni po publikacji.

Skąd wiem, że moja strona potrzebuje aktualizacji? Raport stanu w panelu Drupala pokazuje brakujące aktualizacje bezpieczeństwa. Moduł Update Status może wysyłać o nich e-mail, a polecenia composer audit i drush pm:security sprawdzają to z wiersza poleceń.

Moja strona działa na Drupalu 7 lub 9. Czy to problem? Tak. Drupal 7, 8 i 9 nie dostają już poprawek bezpieczeństwa, podobnie jak Drupal 10.5 i 11.2 oraz starsze gałęzie. Każda nowa luka zostaje na takiej stronie na stałe. Rozwiązaniem jest aktualizacja do wspieranej gałęzi albo, w przypadku Drupala 7, migracja.

Podsumowanie.

W 2026 roku Drupal dostaje poprawki bezpieczeństwa co tydzień, czasem po kilkadziesiąt naraz, a exploit może powstać w godzinę po publikacji. Łatane są nie tylko niszowe moduły, ale też Webform, Paragraphs i sam rdzeń. Jednocześnie mniej więcej połowa stron na Drupalu działa na wersjach, które poprawek w ogóle nie dostają.

Nie trzeba się tego bać, ale trzeba to mieć w kalendarzu. Strona, którą ktoś przegląda co tydzień, testuje poprawki na kopii i wdraża krytyczne w ciągu doby, przechodzi przez taki rok bez historii do opowiadania. Jeśli nie wiesz, w jakim stanie jest Twoja strona, napisz — sprawdzę wersję rdzenia, moduły i zaległe poprawki. Stałą opiekę opisuję na stronie utrzymanie i serwis stron Drupal, a jeśli coś już się stało — naprawa strony Drupal.

Źródła

• Drupal.org: biuletyny bezpieczeństwa dla modułów i dla rdzenia — liczby roczne i miesięczne, stan na 21.10.2026
• Drupal.org: statystyki użycia projektów i rdzenia według wersji — tydzień 11.10.2026
• SA-CORE-2026-004, SA-CORE-2026-014, SA-CONTRIB-2026-175 (Webform)
• The Drop Times: Miggo i exploit w 51 minut; Security Affairs: CVE-2026-9082 atakowana; Qualys: wpis do katalogu CISA KEV
• The Drop Times: pierwsze sześć tygodni inicjatywy bezpieczeństwa AI; Alpha-Omega; The Drop Times: Digital Matters o większych paczkach biuletynów
• The Drop Times: W3Techs — ok. połowa stron na Drupalu na wersjach bez wsparcia