# Pliki phpinfo(): dlaczego muszą zniknąć

> Zapomniany plik phpinfo zdradza ścieżki, moduły, a czasem dane dostępowe. Jak znaleźć takie pliki, usunąć je i sprawdzać PHP w bezpieczniejszy sposób.

Źródło: https://phpsos.de/pl/blog/phpinfo-dateien-entfernen/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**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](https://phpsos.de/pl/blog/env-dateien-schuetzen/).

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](https://phpsos.de/pl/php2shell/php-version-pruefen/).

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](https://phpsos.de/pl/php/php-ini-erklaert/). 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ą.

1. **Wyszukać pliki z wywołaniem phpinfo** (dostosować ścieżkę):

```bash
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
```

2. **Sprawdzić typowe nazwy plików**, także bez trafień w treści:

```bash
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
```

3. **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.

4. **Sprawdzić dostępy w logu**, zanim usuniesz:

```bash
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
```

5. **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ą.

> **Wskazówka:**
> 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](https://phpsos.de/pl/ratgeber/webshell-erkennen/).

## 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](https://phpsos.de/pl/ratgeber/disable-functions/).

```ini
; 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_php` i dalsze utwardzanie w ramach [utwardzania serwerów](https://phpsos.de/pl/leistungen/server-haertung/).

**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.

## Źródła

- [Podręcznik PHP: phpinfo()](https://www.php.net/manual/de/function.phpinfo.php)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [php.net: komunikaty bezpieczeństwa](https://www.php.net/)
