21 października 2026 jednego dnia wyszło pięć poważnych problemów z bezpieczeństwem. Dwa z nich, w PHP i w GitLabie, pozwalają obcej osobie uruchomić własny kod na serwerze bez logowania. Jeśli masz stronę na WordPressie, sklep, aplikację na Node.js albo cokolwiek na Railway, ta lista dotyczy Ciebie. Nie czekaj z tym do przyszłego tygodnia.
Najpierw: kto u Ciebie odpowiada za serwer
Jeśli masz zwykły hosting współdzielony, PHP aktualizuje firma hostingowa. Jeśli masz VPS, kontenery albo serwer, który ktoś Ci kiedyś postawił, aktualizacja jest po Twojej stronie albo po stronie osoby, która ten serwer utrzymuje. Wyślij jej dziś trzy pytania:
- Na jakiej wersji PHP i Node.js działa moja strona na produkcji, a nie na Twoim komputerze?
- Czy po 21 października PHP i Node.js zostały zaktualizowane do wersji z poprawką, a serwer zrestartowany?
- Czy jakiś nasz serwer albo sekret był na Railway lub na własnym GitLabie?
PHP2Shell: krytyczna luka w samym PHP
Dwie luki (CVE-2026-109618 i CVE-2026-109619, ocena 9,2 na 10) siedzą w PHP, w miejscu, które czyta przychodzące zapytanie, zanim ruszy kod Twojej strony. Dlatego zabezpieczenia WordPressa, Drupala czy Joomli nic tu nie dają. Dotyczy to Apache z mod_php, PHP-FPM, CGI, FrankenPHP i LiteSpeed. Szczegóły wyciekły przed planowaną publikacją i próby ataków już widać.
Co zrobić:
- Zaktualizuj PHP do 8.5.12, 8.4.27, 8.3.36 albo 8.2.35. Na 8.1 i starszych nie ma oficjalnej poprawki: przejdź na wspieraną wersję albo zainstaluj łatkę od dystrybucji Linuksa (Ubuntu i AlmaLinux już je wydały).
- Aktualizacja WordPressa, wtyczek czy pakietów Composera nic nie zmienia. Błąd jest w PHP, nie w aplikacji.
- Po aktualizacji zrestartuj wszystkie procesy PHP, przebuduj i wdróż ponownie kontenery. Sprawdź wersję po stronie serwera WWW, bo ta z wiersza poleceń może być inna.
- Jeśli nie możesz załatać dziś, odetnij serwer od internetu albo ogranicz dostęp. WAF pomaga tylko wtedy, gdy nie da się go ominąć i wejść na serwer bezpośrednio.
GitLab: 10 na 10, jeśli masz własny serwer
CVE-2026-110264 pozwala bez logowania uruchomić kod na serwerze GitLaba przez specjalnie przygotowane wyrażenie regularne. Kod działa jako użytkownik git, który ma dostęp do wszystkich repozytoriów, zmiennych CI i tokenów. Dotyczy wersji od 7.0. GitLab.com i GitLab Dedicated są już załatane.
- Zaktualizuj do 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 albo 18.11.13, zgodnie z oficjalną ścieżką aktualizacji. Obejścia nie ma.
- Jeśli serwer był dostępny z internetu, wymień jego sekrety i tokeny. Poprawka zamyka dziurę, ale nie cofa tego, co już mogło wyciec.
Node.js: dziesięć poprawek, cztery ważne
Najpoważniejsza (CVE-2026-111497) to błąd w dekompresji Brotli, który może prowadzić do uruchomienia kodu. Złośliwe dane mogą przyjść w zapytaniu do Twojego serwera albo w odpowiedzi z serwisu, z którego Twój serwer coś pobiera, więc zapora z przodu pokrywa tylko połowę. Trzy kolejne osłabiają sprawdzanie nazw hostów i certyfikatów TLS.
- Zaktualizuj Node.js do 26.12.1, 24.22.1 albo 22.23.4.
npm audit fixnie pomoże, bo błąd jest w samym Node.js, nie w pakiecie. - Node.js 20 i starsze nie dostaną poprawki. Przejdź na 22 albo 24.
- Przebuduj obrazy, zrestartuj i sprawdź wersję w każdej działającej kopii aplikacji.
eMudhra: słabe klucze urzędu certyfikacji
Urząd certyfikacji eMudhra wygenerował osiem kluczy pośrednich tak źle, że tajną część da się wyliczyć z publicznej w ułamku sekundy. Ktoś między Tobą a stroną, na przykład w publicznym Wi-Fi, mógłby podsunąć fałszywy certyfikat. Nadużyć na razie nie widać, a Chrome, Apple i Microsoft już te certyfikaty blokują.
Gorzej z programami, które mają własną listę zaufanych certyfikatów: Node.js (kolejny powód do aktualizacji), Python (zaktualizuj certifi, pip, uv), programy w Go (przebuduj nową wersją Go), Firefox i NSS. Nigdy nie wyłączaj sprawdzania certyfikatów, żeby pozbyć się błędu.
Railway: wymień wszystkie sekrety
Railway poinformował, że ktoś mógł dostać się do zaszyfrowanych zmiennych środowiskowych klientów, a część z nich odczytać. Firma uważa, że problem dotyczy części użytkowników, ale prosi wszystkich o wymianę sekretów. Te zmienne trzymają klucze do bazy danych, chmury, Stripe’a, GitHuba i API modeli AI, a skradzionego klucza można użyć bez dotykania Twojej aplikacji.
- Spisz każdy sekret z każdego projektu i środowiska.
- Unieważnij go tam, gdzie został wydany (Stripe, AWS, GitHub, OpenAI, Anthropic). Sama zmiana zmiennej w Railway nie wyłącza skradzionego klucza.
- Wpisz nowy klucz do Railway i wdróż ponownie każdą usługę. Działająca aplikacja trzyma starą wartość do czasu ponownego wdrożenia.
- Sprawdź w logach dostawców, zwłaszcza w wydatkach na AI, czy nie ma użycia, którego nie rozpoznajesz.
Kolejność na dziś
| Kolejność | Co | Kogo dotyczy |
|---|---|---|
| 1 | PHP i GitLab | Każdy serwer z PHP lub własnym GitLabem dostępny z internetu |
| 2 | Wymiana sekretów | Każdy, kto używa Railway |
| 3 | Node.js | Aplikacje i narzędzia na Node.js |
| 4 | Listy certyfikatów | Serwery i skrypty z Pythonem, Go, Node.js |
Dla każdej poprawki kroki są te same: sprawdź, co naprawdę działa na produkcji, zainstaluj poprawioną wersję, przebuduj i zrestartuj, sprawdź wersję na produkcji. Czego nie da się załatać dziś, to odetnij albo ogranicz.
Źródła: film Academind, Help Net Security o PHP2Shell, The Hacker News o GitLabie, The Hacker News o Node.js, BleepingComputer o eMudhra, The Hacker News o Railway. Stan na 22 października 2026.