# Файлове phpinfo(): защо трябва да изчезнат

> Забравен phpinfo файл издава пътища, модули и понякога данни за достъп. Как да откриете и премахнете такива файлове и да проверявате PHP по-сигурно.

Източник: https://phpsos.de/bg/blog/phpinfo-dateien-entfernen/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Файл, който само извиква `phpinfo()`, показва на всеки посетител версията, модулите, пътищата и настройките на PHP, често и променливи на средата с данни за достъп. За сигурността във връзка с phpinfo затова важи: такива файлове никога не бива да остават трайно в уеб корена, трябва да се изтриват след употреба, а състоянието на PHP е по-добре да се проверява чрез управлението на пакетите и конфигурацията. Състоянието на пачовете срещу PHP2Shell изходът на phpinfo така или иначе не доказва.

## Тестовият файл, който остава

От 21.10.2026 г. хиляди администратори проверяват коя версия на PHP доставят техните уебсайтове. Най-бързият път е известен: създавате файл `info.php` с един-единствен ред, извиквате го в браузъра и отчитате резултата. Това работи. Проблемът започва след това, когато файлът бива забравен.

Такива файлове оцеляват учудващо дълго. Преместват се при миграции, попадат в резервни копия и след години се появяват в директории, които никой вече не познава. Автоматизирани скенери постоянно питат за типични имена на файлове. Което за администратора е било помощно средство, за атакуващия е ръководство за строеж на сървъра.

Особено засегнати са агенциите и хостинг доставчиците с много сайтове на клиенти. Който в натоварена седмица проверява десетки уебсайтове, бързо създава десетки тестови файлове. Една-единствена забравена папка е достатъчна файлът да е достъпен и месеци по-късно.

## Какво издава phpinfo() и защо това има значение за сигурността

Според наръчника на PHP `phpinfo()` извежда текущото състояние на PHP. Чрез константи може да се управлява кои части да се появят; без указание се появява всичко.

| Област (константа) | Съдържание според наръчника | Защо е деликатно |
|---|---|---|
| `INFO_GENERAL` | Build, местоположение на php.ini, уеб сървър, система | издава операционната система и пътища |
| `INFO_CONFIGURATION` | локални и главни стойности на всички директиви | показва дали `disable_functions` или `open_basedir` действат |
| `INFO_MODULES` | заредени разширения с настройки | атакуващите виждат кои функции са налични |
| `INFO_ENVIRONMENT` | променливи на средата | тук често стоят данни за достъп до бази данни или API |
| `INFO_VARIABLES` | предварително дефинирани променливи (Environment, GET, POST, Cookie, Server) | съдържа заглавни части и бисквитки на текущата заявка |

Най-опасни са последните два реда. Съвременните приложения с готовност зареждат данни за достъп от променливи на средата, например от `.env` файл или от конфигурацията на контейнера. Тези стойности стоят тогава в явен текст в изхода. Как да защитавате такива тайни по принцип, описва статията [Правилна защита на данните за достъп и .env файловете](https://phpsos.de/bg/blog/env-dateien-schuetzen/).

Към това се добавя: изходът показва стойностите на текущата заявка, тоест и бисквитки и заглавни части. Ако атакуващ може да насочи посетител към страницата и да прочете отговора, например чрез Cross-Site Scripting уязвимост другаде, стават видими дори бисквитките, маркирани като HttpOnly.

## Защо phpinfo не е доказателство срещу PHP2Shell

Мнозина са създали файла точно за да проверят състоянието на пачовете. За това обаче той става само условно. Дистрибуциите и хостинг доставчиците често внасят корекциите като backport; според съобщения например Ubuntu 24.04 след актуализацията продължава да показва 8.3.6. Показаният номер казва малко. Обратно, актуален номер не доказва, че всички работни процеси (worker) са рестартирани.

Надеждно е състоянието на пакета с номерата на CVE в журнала на промените, допълнено с рестарт на всички PHP процеси. Как става това, обяснява статията [Правилна проверка на версията на PHP и състоянието на пачовете](https://phpsos.de/bg/php2shell/php-version-pruefen/).

Краткотраен изход в уеб контекста все пак има своето място: той показва кой php.ini и кои стойности действително важат за уебсайта, защото командният ред често чете друга конфигурация. Фона за нивата и приоритета обяснява [Обяснение на php.ini](https://phpsos.de/bg/php/php-ini-erklaert/). Ако Ви трябва, тогава със защита на достъпа, със случайно име на файла и само за минути.

За повечето въпроси така или иначе има по-добри пътища. Версията на PHP на един FPM пул е записана в конфигурацията му и в списъка с процеси. Отделни стойности могат да се запитат със скрипт извън уеб корена чрез `ini_get()`, без да се разкрива всичко. А в хостинг панелите интерфейсът показва зададената версия за всеки уебсайт, макар и без информация за backport корекции.

## Откриване на забравени файлове: конкретни стъпки за проверка

Така откривате остатъци на Linux сървър. Командите само четат и не променят нищо.

1. **Търсене на файлове с извикване на phpinfo** (съобразете пътя):

```bash
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
```

2. **Проверка на типични имена на файлове,** дори без попадение в съдържанието:

```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. **Оценка на попаденията:** Не всяко намерено място е тестов файл. Инструменти за администриране, панели или фреймуърци могат да ползват `phpinfo()` зад вход. Решаващо е дали файлът е достъпен от интернет без вход.

4. **Вижте достъпите в журнала,** преди да изтриете:

```bash
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
```

5. **Изтриване и смяна на тайните:** Ако в изхода е имало парола или ключ и файлът е бил публичен, стойността се смята за известна. Сменете я.

> **Съвет:**
> Намерено място с неизвестна дата на създаване и странно съдържание до извикването на phpinfo може да е и задна врата. Тогава не само изтривайте, а запазете и дайте да проверят, вижте [Откриване и премахване на уеб шелове](https://phpsos.de/bg/ratgeber/webshell-erkennen/).

## Предотвратяване за постоянно вместо почистване

Три мерки гарантират, че темата няма да се върне. Първо: включете `phpinfo` в списъка `disable_functions` на php.ini за уеб контекста. Проверете преди това дали Вашият панел ползва функцията за страница със състояние. Как действа настройката и къде са границите ѝ, е описано в [Правилно използване на disable_functions](https://phpsos.de/bg/ratgeber/disable-functions/).

```ini
; php.ini за FPM или Apache, след това рестартирайте всички PHP процеси
disable_functions = phpinfo
expose_php = Off
```

Второ: внедряване само по фиксиран процес, например чрез Git или build pipeline, така че отделни файлове да не стигат на ръка до уеб корена. Трето: информацията за състоянието принадлежи в мониторинга или в описа, а не на публична страница.

`expose_php = Off` премахва допълнително заглавната част, с която PHP съобщава версията си във всеки отговор. Това не замества актуализацията, но отнема на автоматизираните скенери удобна информация. Който има няколко души с достъп до сървъра, трябва освен това да договори просто правило: тестовите файлове се изтриват в същата работна стъпка, в която са създадени, а не „по-късно“.

## Как помага PHP SOS конкретно?

- Претърсваме Вашите уеб корени за phpinfo файлове, тестови скриптове и други остатъци и оценяваме всяка находка.
- Анализираме достъпите до намерените файлове и Ви казваме кои тайни трябва да смените.
- Доказваме състоянието на пачовете срещу PHP2Shell чрез журнала на промените на пакета и рестарта на процесите, а не чрез показване на версия.
- Въвеждаме `disable_functions`, `expose_php` и други мерки за заздравяване трайно в рамките на [заздравяването на сървъра](https://phpsos.de/bg/leistungen/server-haertung/).

**Заключение:** Един phpinfo файл се създава за секунди и също толкова бързо се забравя. Който го търси и премахва сега, затваря ненужно изтичане на данни и разчита за състоянието на пачовете на надеждни доказателства.


## Често задавани въпроси

**Самият phpinfo файл уязвимост ли е?**  
Той не отваря достъп, но дава на атакуващите подробно описание на сървъра: версия, модули, пътища, настройки и, в зависимост от средата, и променливи на средата. Това улеснява целенасочени атаки и може да разкрие данни за достъп.

**Доказва ли номерът на версията в phpinfo, че PHP2Shell е пачнат?**  
Не. Дистрибуциите и хостинг доставчиците често внасят корекциите като backport и показаният номер остава същият. Състоянието на пачовете се доказва с журнала на промените на пакета и потвърждение от доставчика, плюс рестарт на всички PHP процеси.

**Какво да направя, ако phpinfo файл е бил публичен по-дълго време?**  
Изтрийте файла, вижте в журнала за достъп кой го е извиквал и сменете всички тайни, които са се виждали в изхода, например пароли за бази данни или API ключове от променливи на средата.

**Мога ли да изключа phpinfo() напълно?**  
Да, чрез disable_functions в php.ini на уеб контекста. Проверете преди това дали панел или приложение ползва функцията за страници със състояние, и рестартирайте PHP процесите след това.

## Източници

- [Наръчник на PHP: phpinfo()](https://www.php.net/manual/de/function.phpinfo.php)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [php.net: съобщения за сигурност](https://www.php.net/)
