Krótko: Luki bezpieczeństwa w PHP są zgłaszane poufnie, najlepiej przez prywatny formularz Advisory w repozytorium GitHub php/php-src, alternatywnie na security@php.net. Programiści PHP klasyfikują znalezisko jako wysokie, średnie lub niskie; poważne błędy są poprawiane w osobnym repozytorium bezpieczeństwa i publikowane dopiero wraz z wydaniem, razem z GitHub Security Advisory i zwykle numerem CVE. W PHP2Shell ten proces przebiegł w ekspresowym tempie: zapowiedź 20.10.2026, poprawki 21.10.2026, uzupełniająca informacja 23.10.2026.
Kto zajmuje się bezpieczeństwem w PHP?
PHP to projekt open source. Polityka bezpieczeństwa w wiki opisuje go jako projekt wolontariuszy bez budżetu na nagrody. Dla każdej wersji są release managerowie, którzy odpowiadają za wydania. Do tego dochodzi PHP Foundation, która według własnego opisu zatrudnia zespół programistów na część i na pełny etat, pracujący nad utrzymaniem, bezpieczeństwem i nowymi funkcjami PHP.
Dla firm oznacza to: nie ma producenta z umową, infolinią lub gwarantowanymi czasami reakcji. Kto potrzebuje wiążących zobowiązań, otrzyma je od swojej dystrybucji Linuksa, dostawcy hostingu lub dostawcy wsparcia długoterminowego, a nie od samego projektu PHP. Warto znać ten łańcuch dostaw.
Jak zgłasza się lukę
Droga jest opisana w polityce bezpieczeństwa na GitHubie:
- Zgłoszenie: przez prywatny formularz Security Advisories w repozytorium
php/php-src. Kto nie może z niego skorzystać albo chce omówić temat, który nie jest zgłoszeniem błędu, pisze na security@php.net. - Zwięzły opis: Oczekiwany jest krótki przykład pokazujący błąd, a nie długi raport o możliwych skutkach. Dzięki temu zespół może szybciej ocenić zgłoszenie.
- Poufność: Zgłoszenie pozostaje prywatne do czasu publikacji.
- Wymienienie: Zgłaszający są wymieniani jako współtwórcy według systemu credit MITRE.
Starsza strona wiki wymienia dodatkowo klasyczny system śledzenia błędów z typem „Security”. Rozstrzygająca jest dziś droga przez GitHub.
Co projekt PHP uznaje za lukę bezpieczeństwa
Nie każda awaria jest luką bezpieczeństwa. Wiki podaje cztery kryteria: błąd umożliwia nieuprawnione działania, przekracza granice bezpieczeństwa, otwiera dostęp do cudzych danych albo poważnie pogarsza dostępność lub wydajność. Klasyfikacja ma trzy stopnie:
| Stopień | Znaczenie według polityki | Numer CVE |
|---|---|---|
| Wysoki | osoby trzecie mogą skompromitować większość instalacji, wykonać kod lub odczytać pliki | z reguły tak |
| Średni | podobny skutek, ale tylko w rzadszych warunkach, na przykład przy rzadkim rozszerzeniu lub konfiguracji | zwykle tak |
| Niski | teoretycznie możliwe, w praktyce bardzo trudne do wykorzystania | zwykle nie |
Równie pouczająca jest lista tego, co wyraźnie nie jest luką bezpieczeństwa: złośliwy kod wykonywany celowo, obejścia open_basedir i disable_functions, złośliwe dane przekazywane do unserialize(), użycie FFI oraz zwykłe przerwanie z powodu pamięci, w którym działa memory_limit i kończy się tylko bieżące żądanie. Dla operatorów oznacza to: disable_functions to sensowne utwardzanie, ale nie mur obronny.
Od poprawki do publikacji
Poprawki dla luk wysokich i średnich są według wiki wprowadzane w osobnym repozytorium bezpieczeństwa, zanim powstanie wydanie. Błędy niskiego stopnia przechodzą jak zwykłe poprawki błędów. Luka jest publikowana według zasady odpowiedzialnego ujawniania: najpierw poprawka, potem szczegóły. Wydania ukazują się według wiki najczęściej w czwartki, często w ramach regularnych comiesięcznych publikacji.
Wraz z wydaniem ukazuje się GitHub Security Advisory z własnym identyfikatorem (GHSA) i stopniem ważności. W repozytorium pojawiło się na przykład 24.09.2026 kilka advisories dotyczących wrapperów strumieni, FastCGI i filtrów, ze stopniami od niskiego do wysokiego. Pakiety źródłowe na php.net są oferowane z sumami kontrolnymi SHA-256 i podpisami GPG release managerów; tagi Git są podpisane. Które gałęzie wersji w ogóle jeszcze otrzymują poprawki bezpieczeństwa, pokazuje strona o wersjach PHP i cyklu wydawniczym.
PHP2Shell jako przykład sytuacji awaryjnej
PHP2Shell pokazuje, jak proces przebiega pod presją:
- 20.10.2026: php.net zapowiada krytyczne wydanie bezpieczeństwa na 21.10.2026 na godz. 14:00 UTC i zastrzega sobie wcześniejszą publikację, jeśli szczegóły staną się publiczne lub pojawią się ataki. Według kilku doniesień szczegóły rzeczywiście stały się znane przed upływem terminu embarga; tło wyjaśnia artykuł Dlaczego luka w PHP stała się znana przed poprawką.
- 21.10.2026: Ukazują się PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35, a do tego advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) i GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), obie sklasyfikowane jako krytyczne. Według php.net dystrybucje Linuksa i dostawcy wsparcia długoterminowego otrzymali poprawki wcześniej. Dla 7.4, 8.0 i 8.1 istnieją minimalne backporty.
- 23.10.2026: Informacyjna uwaga o CVE-2026-115560 zaleca
session.upload_progress.enabled=0; pełne advisory pojawi się wraz z następnym wydaniem.
Wnioski dla operatorów
- Subskrybować źródła: php.net, GitHub Advisories
php/php-srci komunikaty bezpieczeństwa Państwa dystrybucji. - Znać łańcuch dostaw: Kto dostarcza Państwa pakiet PHP i jak szybko dochodzą tam backporty?
- Planować okno czasowe: Wydania krytyczne mogą pojawić się poza zwykłym rytmem; okno na poprawki musi być możliwe w krótkim czasie.
- Zaplanować restart: Aktualizacja działa dopiero po zrestartowaniu wszystkich procesów PHP.
- Zabezpieczyć dowód: Udokumentować wersję, stan pakietu i moment.
Jak konkretnie pomaga PHP SOS?
Dzięki usłudze poprawek PHP przejmujemy część, która leży po Państwa stronie:
- Śledzenie komunikatów: Obserwujemy php.net, advisories i komunikaty dystrybucji oraz oceniamy, czy Państwa systemy są dotknięte.
- Wdrożenie poprawki: Aktualizacja z odpowiedniego źródła, restart wszystkich procesów, kontrola działającej wersji.
- Zabezpieczenie okresu przejściowego: Tam, gdzie aktualizacja utknęła, wdrażamy oficjalne środki przejściowe.
- Dokumentacja: Otrzymują Państwo dowód z wersjami, stanami pakietów i momentami.
Częste pytania
Jak zgłosić lukę bezpieczeństwa w PHP?
Najlepiej przez prywatny formularz zgłoszeń Security Advisories w repozytorium GitHub php/php-src. Kto nie może z niego skorzystać, pisze na security@php.net. Zgłoszenie pozostaje poufne do czasu publikacji.
Czy projekt PHP płaci nagrodę za znalezione luki?
Nie. Według polityki bezpieczeństwa PHP jest projektem wolontariuszy, bez pieniędzy na bug bounty. Zgłaszający są jednak wymieniani jako współtwórcy.
Czy obejście disable_functions jest luką bezpieczeństwa?
Według polityki projektu PHP nie. Obejścia open_basedir i disable_functions nie są uznawane za problem bezpieczeństwa PHP. Te ustawienia są utwardzaniem, ale nie niezawodną granicą bezpieczeństwa.
Gdzie dowiem się o nowych lukach bezpieczeństwa PHP?
Na stronie głównej php.net z komunikatami o wydaniach oraz w Security Advisories repozytorium GitHub php/php-src. Kto pobiera PHP z dystrybucji, śledzi dodatkowo jej komunikaty o bezpieczeństwie.
Dlaczego PHP2Shell opublikowano w środę?
Wydania ukazują się według wiki najczęściej w czwartki. Dla PHP2Shell php.net zapowiedziało 20.10.2026 wydanie bezpieczeństwa na środę 21.10.2026, godz. 14:00 UTC, i zastrzegło sobie wcześniejszą publikację na wypadek upublicznienia szczegółów.