Krótko: Plik, który tylko wywołuje phpinfo(), pokazuje każdemu odwiedzającemu wersję, moduły, ścieżki i ustawienia PHP, często także zmienne środowiskowe z danymi dostępowymi. Dla bezpieczeństwa phpinfo obowiązuje więc: nigdy nie zostawiać takich plików na stałe w webroot, usuwać je po użyciu, a stan PHP sprawdzać raczej przez menedżer pakietów i konfigurację. Stanu poprawek przeciw PHP2Shell wynik phpinfo i tak nie dokumentuje.
Plik testowy, który zostaje
Od 21.10.2026 tysiące administratorów sprawdza, jaką wersję PHP wydają ich strony. Najszybsza droga jest znana: założyć plik info.php z jedną linią, wywołać go w przeglądarce, odczytać wynik. To działa. Problem zaczyna się potem, gdy plik zostaje zapomniany.
Takie pliki przetrwają zaskakująco długo. Wędrują przy przeprowadzkach, trafiają do kopii zapasowych i po latach pojawiają się w katalogach, których nikt już nie zna. Zautomatyzowane skanery stale pytają o typowe nazwy plików. To, co dla administratora było pomocą, dla atakującego jest instrukcją budowy serwera.
Szczególnie dotknięte są agencje i firmy hostingowe z wieloma stronami klientów. Kto w gorączkowym tygodniu sprawdza dziesiątki stron, szybko zakłada dziesiątki plików testowych. Jeden zapomniany katalog wystarczy, aby plik był dostępny jeszcze po miesiącach.
Co zdradza phpinfo() i dlaczego ma to znaczenie dla bezpieczeństwa
Według podręcznika PHP phpinfo() wypisuje aktualny stan PHP. Za pomocą stałych można sterować tym, które części się pojawią; bez podania jest to wszystko.
| Obszar (stała) | Treść według podręcznika | Dlaczego delikatne |
|---|---|---|
INFO_GENERAL |
build, położenie php.ini, serwer WWW, system | zdradza system operacyjny i ścieżki |
INFO_CONFIGURATION |
wartości lokalne i główne wszystkich dyrektyw | pokazuje, czy disable_functions lub open_basedir działają |
INFO_MODULES |
załadowane rozszerzenia z ustawieniami | atakujący widzą, jakie funkcje są dostępne |
INFO_ENVIRONMENT |
zmienne środowiskowe | często znajdują się tu dane dostępowe do bazy danych lub API |
INFO_VARIABLES |
zmienne predefiniowane (Environment, GET, POST, Cookie, Server) | zawiera nagłówki i ciasteczka bieżącego żądania |
Najniebezpieczniejsze są dwa ostatnie wiersze. Nowoczesne aplikacje chętnie ładują dane dostępowe ze zmiennych środowiskowych, na przykład z pliku .env lub z konfiguracji kontenera. Te wartości znajdują się wtedy w wyniku jawnym tekstem. Jak zasadniczo chronić takie sekrety, opisuje artykuł Prawidłowa ochrona danych dostępowych i plików .env.
Dochodzi do tego, że wynik pokazuje wartości bieżącego żądania, a więc także ciasteczka i nagłówki. Jeśli atakujący może skierować odwiedzającego na stronę i odczytać odpowiedź, na przykład przez lukę Cross-Site Scripting w innym miejscu, widoczne stają się nawet ciasteczka oznaczone jako HttpOnly.
Dlaczego phpinfo nie jest dowodem przeciw PHP2Shell
Wielu założyło ten plik właśnie po to, aby sprawdzić stan poprawek. Do tego nadaje się tylko w ograniczonym stopniu. Dystrybucje i firmy hostingowe często wprowadzają poprawki jako backport; według doniesień na przykład Ubuntu 24.04 po aktualizacji nadal pokazuje 8.3.6. Wyświetlany numer mówi więc niewiele. Odwrotnie, aktualny numer nie dowodzi, że wszystkie procesy worker zostały zrestartowane.
Wiarygodny jest stan pakietu z numerami CVE w changelogu, uzupełniony restartem wszystkich procesów PHP. Jak to zrobić, wyjaśnia artykuł Prawidłowe sprawdzanie wersji PHP i stanu poprawek.
Krótkotrwały wynik w kontekście WWW ma mimo to swoje miejsce: pokazuje, jakie php.ini i jakie wartości faktycznie obowiązują dla strony, ponieważ wiersz poleceń często odczytuje inną konfigurację. Tło dotyczące poziomów i pierwszeństwa wyjaśnia artykuł php.ini wyjaśnione. Jeśli tego potrzebujesz, to z ochroną dostępu, z losową nazwą pliku i tylko na kilka minut.
Na większość pytań i tak są lepsze drogi. Wersja PHP puli FPM znajduje się w jej konfiguracji i na liście procesów. Pojedyncze wartości można odpytać skryptem poza webroot za pomocą ini_get(), bez ujawniania wszystkiego. A w panelach hostingu interfejs pokazuje przypisaną wersję dla każdej strony, choć bez informacji o backportach.
Znajdowanie zapomnianych plików: konkretne kroki kontroli
Tak wytropisz pozostałości na serwerze Linux. Polecenia tylko odczytują i niczego nie zmieniają.
- Wyszukać pliki z wywołaniem phpinfo (dostosować ścieżkę):
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
- Sprawdzić typowe nazwy plików, także bez trafień w treści:
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
-
Ocenić trafienia: Nie każde znalezisko jest plikiem testowym. Narzędzia administracyjne, panele lub frameworki mogą używać
phpinfo()za logowaniem. Decyduje to, czy plik jest dostępny z internetu bez logowania. -
Sprawdzić dostępy w logu, zanim usuniesz:
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
- Usunąć i wymienić sekrety: Jeśli w wyniku znajdowało się hasło lub klucz, a plik był publiczny, wartość uchodzi za znaną. Zmień ją.
Znalezisko o nieznanej dacie utworzenia i podejrzanej zawartości obok wywołania phpinfo może być także tylnymi drzwiami. Wtedy nie tylko usuwaj, ale zabezpiecz i daj sprawdzić, zob. Rozpoznawanie i usuwanie webshelli.
Zapobiegać na stałe zamiast sprzątać
Trzy środki sprawiają, że temat nie wróci. Po pierwsze: dodać phpinfo do listy disable_functions w php.ini dla kontekstu WWW. Sprawdź wcześniej, czy Państwa panel nie potrzebuje tej funkcji do strony statusu. Jak ustawienie działa i gdzie leżą jego granice, opisuje artykuł Prawidłowe użycie disable_functions.
; php.ini dla FPM lub Apache, potem zrestartować wszystkie procesy PHP
disable_functions = phpinfo
expose_php = Off
Po drugie: wdrażanie tylko stałym procesem, na przykład przez Git lub pipeline budowania, aby pojedyncze pliki nie trafiały ręcznie do webroot. Po trzecie: informacje o stanie należą do monitoringu lub inwentarza, a nie do publicznej strony.
expose_php = Off dodatkowo usuwa nagłówek, którym PHP przekazuje swoją wersję w każdej odpowiedzi. Nie zastępuje to aktualizacji, ale odbiera zautomatyzowanym skanerom wygodną informację. Kto ma kilka osób z dostępem do serwera, powinien ponadto uzgodnić prostą zasadę: pliki testowe są usuwane w tym samym kroku roboczym, w którym je założono, a nie „później”.
Jak konkretnie pomaga PHP SOS?
- Przeszukujemy Państwa webroot pod kątem plików phpinfo, skryptów testowych i innych pozostałości i oceniamy każde znalezisko.
- Analizujemy dostępy do znalezionych plików i mówimy Państwu, które sekrety warto wymienić.
- Dokumentujemy stan poprawek przeciw PHP2Shell przez changelog pakietu i start procesów zamiast przez wyświetlanie wersji.
- Trwale wdrażamy
disable_functions,expose_phpi dalsze utwardzanie w ramach utwardzania serwerów.
Podsumowanie: Plik phpinfo zakłada się w kilka sekund i równie szybko się o nim zapomina. Kto teraz go wyszuka i usunie, zamyka niepotrzebny wyciek danych i w kwestii stanu poprawek polega na wiarygodnych dowodach.
Częste pytania
Czy plik phpinfo sam w sobie jest luką bezpieczeństwa?
Nie otwiera dostępu, ale dostarcza atakującym szczegółowy opis serwera: wersję, moduły, ścieżki, ustawienia, a zależnie od środowiska także zmienne środowiskowe. Ułatwia to ukierunkowane ataki i może ujawnić dane dostępowe.
Czy numer wersji w phpinfo dowodzi, że PHP2Shell jest załatane?
Nie. Dystrybucje i firmy hostingowe często wprowadzają poprawki jako backport, a wyświetlany numer pozostaje wtedy taki sam. Stan poprawek dokumentują changelog pakietu i potwierdzenie dostawcy oraz restart wszystkich procesów PHP.
Co zrobić, jeśli plik phpinfo był przez dłuższy czas publiczny?
Usunąć plik, sprawdzić w logu dostępu, kto go pobierał, i wymienić wszystkie sekrety, które znalazły się w wyniku, na przykład hasła do baz danych lub klucze API ze zmiennych środowiskowych.
Czy mogę całkowicie wyłączyć phpinfo()?
Tak, przez disable_functions w php.ini kontekstu WWW. Sprawdź wcześniej, czy panel lub aplikacja nie używa tej funkcji do stron statusu, a potem zrestartuj procesy PHP.