Drupal Webform CVE-2026-96355: zwykły formularz może uruchomić kod

Zespół bezpieczeństwa Drupala opublikował 23 września krytyczne ostrzeżenie dotyczące popularnego modułu Webform. Podatność CVE-2026-96355 może sprawić, że dane wpisane przez osobę w formularzu zostaną później ocenione jak kod szablonu. W zależności od konfiguracji skutkiem może być ujawnienie informacji, zapisany XSS albo zdalne wykonanie kodu.

Problem nie dotyczy rdzenia Drupala i nie oznacza, że każdy formularz Webform jest podatny. Dotyczy instalacji z konkretnym niestandardowym formatem elementu wielowartościowego, który używa tokenów wartości zgłoszenia. Ponieważ formularze są zwykle publiczne, osoba atakująca może jednak nie potrzebować konta.

Które wersje trzeba zaktualizować

Advisory SA-CONTRIB-2026-175 wskazuje jako podatne:

• Webform w gałęzi 6.2 przed 6.2.12;
• Webform 6.3.0 przed 6.3.1.

Rozwiązaniem jest przejście odpowiednio do Webform 6.2.12 albo 6.3.1. Oficjalna ocena Drupal Security Team to Critical, 18/25. Warunkiem jest wspomniana konfiguracja formatowania; część skutków zależy również od dodatkowych modułów i ustawień konkretnej strony.

Administrator powinien uważać na jedną praktyczną pułapkę: numer wersji widoczny w repozytorium wdrożeniowym nie zawsze jest numerem wersji działającej na produkcji. Stary kontener, nieodświeżony węzeł albo nieudane wdrożenie może nadal obsługiwać ruch.

Dlaczego formularz staje się granicą bezpieczeństwa

Formularz kontaktowy wygląda niewinnie, lecz łączy anonimowego użytkownika z bazą danych, wiadomościami e-mail, CRM, plikami i panelem pracownika. Dane wprowadzone dzisiaj mogą być wyświetlane później w potwierdzeniu, eksporcie lub widoku administracyjnym.

Jeśli system zastępuje tokeny w konfigurowalnym szablonie i pomyli wartość od użytkownika z fragmentem tego szablonu, treść przechodzi z roli „danych” do roli „instrukcji”. To ta sama rodzina problemu, którą firmy spotykają w generatorach dokumentów, wiadomościach transakcyjnych i narzędziach low-code.

Ryzyko nie kończy się na serwerze WWW. Przejęta aplikacja może mieć dostęp do bazy klientów, SMTP, pamięci obiektowej, webhooków i kluczy do systemów marketingowych. Dlatego właścicielem reakcji nie powinien być wyłącznie administrator CMS.

Co zrobić dzisiaj

Najpierw zbuduj listę stron używających Drupala i sprawdź, gdzie moduł Webform jest aktywny. Nie ograniczaj się do serwisu głównego: sprawdź portale rekrutacyjne, intranety dostępne z internetu, strony wydarzeń i dawne kampanie.

Następnie:

1. potwierdź działającą wersję modułu na każdym środowisku;
2. zabezpiecz konfigurację, pliki, bazę i logi potrzebne do ewentualnej analizy;
3. zaktualizuj Webform do 6.2.12 lub 6.3.1;
4. uruchom wymagane aktualizacje bazy i odbuduj cache zgodnie z procedurą Drupala;
5. przetestuj publiczne formularze, potwierdzenia, powiadomienia e-mail, eksporty i integracje;
6. przejrzyj konfiguracje niestandardowych formatów wielu wartości oraz tokenów zgłoszeń;
7. potwierdź wersję na wszystkich węzłach po zakończeniu wdrożenia.

Wyłączenie jednego formularza może być krótkoterminowym ograniczeniem ryzyka, jeżeli aktualizacja wymaga okna serwisowego. Nie zastępuje jednak poprawki i nie chroni innych formularzy z podobną konfiguracją.

Jak szukać oznak wykorzystania

Zacznij od historii zgłoszeń do formularzy z niestandardowym formatowaniem. Szukaj treści, która nie przypomina normalnych danych biznesowych, nietypowych znaczników szablonów, długich ciągów i prób wpłynięcia na renderowanie. Zestaw czas zgłoszenia z późniejszym wyświetleniem w panelu, generowaniem wiadomości lub eksportu.

Na serwerze sprawdź zmiany plików, nowe procesy, połączenia wychodzące, nietypowe błędy renderowania oraz aktywność kont administracyjnych. W bazie i konfiguracji przejrzyj nowe role, zmienione uprawnienia, handlerów formularzy i nieoczekiwane integracje.

Brak alarmu WAF nie jest dowodem bezpieczeństwa. Złośliwa wartość może przypominać zwykły tekst podczas wysłania, a niebezpieczny skutek pojawić się dopiero wtedy, gdy pracownik otworzy zgłoszenie lub system wyrenderuje je w określonym widoku.

Decyzje dla firmy, nie tylko zespołu Drupal

Ustal, jakie dane zbierają podatne formularze. Rekrutacja może zawierać CV, adresy i historię pracy; zapytanie handlowe — dane kontaktowe i opis infrastruktury; zgłoszenie wsparcia — załączniki, identyfikatory i informacje o kliencie. Ta mapa decyduje o zakresie analizy i ewentualnych obowiązkach prawnych.

Jeżeli znajdziesz oznaki wykonania kodu, nie usuwaj ich odruchowo przed zabezpieczeniem dowodów. Odizoluj usługę, uruchom procedurę incydentową, ustal dostępne sekrety i odbuduj aplikację z zaufanego źródła. Zmieniaj poświadczenia w kontrolowanej kolejności po zamknięciu wejścia.

Fakty źródłowe i wnioski Breachroad

Drupal Security Team potwierdza CVE-2026-96355, podatne i poprawione wersje, wymagany niestandardowy format, możliwość anonimowego przesłania danych oraz skutki od ujawnienia informacji i XSS do RCE. Advisory nie potwierdza masowej kampanii ataków i jasno wskazuje zależność od konfiguracji.

Plan inwentaryzacji, korelacji zgłoszeń z renderowaniem, badania połączeń oraz analizy danych formularzy jest rekomendacją Breachroad. Szkolenie z bezpieczeństwa aplikacji webowych pomaga zespołom rozpoznawać granicę między danymi i kodem, a test penetracyjny aplikacji pozwala sprawdzić realny przepływ formularzy, uprawnień i integracji.