Bartosz Bryniarski

PHP2Shell zaatakował, zanim aplikacja zdążyła się odezwać – więc jakość jej kodu nie miała znaczenia. To dobry pretekst, żeby zapytać o coś, o czym na tanim hostingu nikt nie myśli: co stoi między internetem a moim kodem, kto wybiera wersję interpretera i co staje się punktem wejścia. Cztery modele wdrożenia, od mod_php po statyczną stronę, porównane pod kątem tego, co atakujący dostaje za darmo. Bez tezy, że PHP jest zły – bo PHP podany porządnie wygląda dziś prawie tak samo jak Python.

20 października 2026 wyciekły szczegóły dwóch krytycznych luk w samym silniku PHP (CVE-2026-109618 i CVE-2026-109619, razem nazywanych PHP2Shell): zdalne wykonanie kodu bez logowania, zanim aplikacja zdąży się w ogóle uruchomić. W Polsce COI wyłączył strony BIP w systemie SSDIP, za granicą gasły serwisy rządowe w Holandii, Finlandii i Francji. Co dokładnie się zepsuło, ile serwerów było wystawionych, co wiemy o włamaniach – i dlaczego najgorsza liczba w tej historii to nie CVSS, tylko 69 procent.

W dużym projekcie nie da się pamiętać, że gdzieś już jest funkcja licząca to samo – więc pisze się ją drugi i trzeci raz. To nie lenistwo, to koszt pamięci. Problem w tym, że kopie z czasem się rozchodzą: ta sama najlepsza próba ucznia potrafiła być inna na ekranie i w PDF-ie, a w aplikacji mobilnej ten sam egzamin pokazywał czas raz jako 12:05, raz jako 12 min 5 s. Ta sama choroba złapała niezależnie backend Django i aplikację w React Native. O tym, dlaczego duplikacja to fabryka takich rozjazdów, i jak posprzątać ją bezpiecznie: najpierw dopisać testy, potem scalać, a zielona suita ma świecić tak samo przed i po.

Trzy lata temu pokazałem na blogu klasyczny SQL Injection: formularz logowania w PHP, sklejane zapytanie i wpisane w pole username „' OR 1=1#. Wróćmy do tamtego kodu i zadajmy inne pytanie: czy dziś dałoby się go tak w ogóle napisać? Bo domyślna ścieżka współczesnego PHP i frameworków – obsługa formularza, ORM, zapytania parametryzowane z pudełka – prowadzi do kodu bezpiecznego, a żeby wstrzyknąć SQL, trzeba dziś z tej ścieżki świadomie zejść. Z uczciwym rozdziałem o tym, gdzie wstrzyknięcie wciąż jest łatwe.

Teza krąży po branży od lat: gdyby programiści porządnie testowali własny kod, testerzy byliby zbędni. Patrzę na nią z nietypowej pozycji, bo jestem programistą po studiach podyplomowych z testowania – i rozkładam ją na łopatki trzema argumentami: moje testy testują moją wyobraźnię, tester patrzy na aplikację inaczej niż ja, a testowanie to zawód z własnym warsztatem. Z uczciwym rozdziałem o tym, co się w tej tezie mimo wszystko broni.

Po serii o testowaniu czas na dowód z produkcji, policzony co do sztuki: backend Django z ponad 100 tysiącami linii kodu i 6,6 tysiąca testów, mobilka React Native z 44 tysiącami linii i ponad 1600 testami, do tego 298 testów Playwright, 7 przepływów Maestro i bramka w GitHub Actions, która nie raz zatrzymała zepsute wdrożenie przed produkcją. Z metodą liczenia, proporcjami kodu do testów i uczciwym rozdziałem o tym, czego wciąż nie pokrywam.