Strona na starym PHP i nie da się jej podnieść? Nie łataj, przepisz na EmDash
Dziś PHP dostaje łatki. Twoja strona może ich nie dostać.
21 października 2026 o 14:00 UTC (16:00 w Polsce) zespół PHP publikuje poprawki dwóch krytycznych podatności, obie z oceną CVSS 9.2 (zapowiedź na php.net).
Jedno jest pewne już teraz: PHP 7.4 nie dostaje poprawek bezpieczeństwa od listopada 2022, PHP 8.0 od listopada 2023, a PHP 8.1 od końca 2025 roku (php.net/eol). Jeśli Twoja strona działa na którejś z tych wersji, łatek nie będzie, ani dziś, ani przy następnej dziurze.
Ile wsparcia zostało Twojej wersji PHP?
Daty końca poprawek bezpieczeństwa według php.net.
- PHP 7.4
Zakończone 28 listopada 2022.
- PHP 8.0
Zakończone 26 listopada 2023.
- PHP 8.1
Zakończone 31 grudnia 2025.
- PHP 8.2
Do 31 grudnia 2026.
- PHP 8.3
Do 31 grudnia 2027.
- PHP 8.4
Do 31 grudnia 2028.
- PHP 8.5
Do 31 grudnia 2029.
PHP 8.2 też traci wsparcie, za 10 tygodni.
Dlaczego „po prostu podnieś PHP” często nie działa
Stara strona na PHP 7 to zwykle porzucone wtyczki, własny kod sprzed lat i motyw, który wysypuje się na PHP 8. Podniesienie wersji oznacza wtedy przepisywanie. A skoro i tak przepisujesz, warto zapytać: na co?
Jest też drugi scenariusz, mniej oczywisty. Hosting nie musi Twojej strony wyłączać, żeby przestała działać. Wystarczy, że przestawi domyślną wersję PHP na nowszą albo wycofa stare wersje z oferty. Strona pisana pod PHP 7 potrafi wtedy pokazać biały ekran z dnia na dzień, a Ty przepisujesz ją w pośpiechu zamiast na spokojnie.
Co realnie zmienia EmDash
Nie znika ryzyko. Zmienia się to, kto łata środowisko, jak szybko i jak daleko sięga szkoda, gdy coś pójdzie nie tak.
Runtime
W PHP interpreter łatasz sam albo czekasz na hostingodawcę. EmDash działa na Cloudflare Workers, gdzie silnik V8 łata Cloudflare. Według ich dokumentacji czas od poprawki do produkcji to poniżej 24 godzin, a Workers nie dają dostępu do lokalnego systemu plików.
Wtyczki
W WordPressie 91% nowych podatności w 2025 roku dotyczyło wtyczek (Patchstack), a każda wtyczka działa z pełnym dostępem do strony. Wtyczka sandboxed w EmDash działa w osobnym izolacie, dostaje tylko zadeklarowane uprawnienia, a nowe uprawnienie przy aktualizacji wymaga Twojej zgody.
Treść
Zamiast HTML-a w bazie EmDash zapisuje treść jako Portable Text, czyli uporządkowany JSON. Wstawki HTML są oczyszczane albo zamykane w izolowanym iframe.
Dostęp dla AI
Serwer MCP, przez który agenci AI zarządzają treścią, przyjmuje tylko tokeny i sprawdza zarówno zakres tokenu, jak i rolę użytkownika. Ciasteczko sesji tam nie wystarczy.
Czego EmDash nie załatwia
5.1Czy to znaczy, że EmDasha nie da się zhakować?
Nie. Astro, na którym stoi EmDash, miał we wrześniu 2026 krytyczną podatność: złośliwy obraz AVIF mógł prowadzić do zdalnego wykonania kodu. Naprawiono ją w Astro 7.2.8. Zamiast PHP aktualizujesz paczki npm, regularnie i na czas.
5.2Czy izolacja wtyczek działa zawsze?
Nie. Na Cloudflare wymaga płatnego planu Workers. Wtyczki typu native działają bez izolacji, więc ich autorowi trzeba ufać tak samo jak w WordPressie.
5.3EmDash nie ma żadnych CVE, więc jest bezpieczny?
Brak opublikowanych zgłoszeń bezpieczeństwa u młodego projektu oznacza przede wszystkim krótką historię, a nie dowód. Dlatego mierzymy, aktualizujemy i ograniczamy liczbę wtyczek do minimum.
5.4A ataki przez paczki npm?
To realne ryzyko w świecie JavaScriptu. Bronimy się małą liczbą zależności i sprawdzaniem npm audit przy każdym wdrożeniu.
Raz przepisać zamiast co pół roku zgadywać
Nie twierdzimy, że EmDash jest odporny na ataki. Twierdzimy, że lepiej przepisać stronę raz, na stos, w którym nikt nie musi pamiętać o łataniu interpretera, niż co pół roku zgadywać, czy dzisiejsza dziura w PHP dotyczy i Ciebie.