Накратко: Файл, който само извиква 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 файловете.
Към това се добавя: изходът показва стойностите на текущата заявка, тоест и бисквитки и заглавни части. Ако атакуващ може да насочи посетител към страницата и да прочете отговора, например чрез Cross-Site Scripting уязвимост другаде, стават видими дори бисквитките, маркирани като HttpOnly.
Защо phpinfo не е доказателство срещу PHP2Shell
Мнозина са създали файла точно за да проверят състоянието на пачовете. За това обаче той става само условно. Дистрибуциите и хостинг доставчиците често внасят корекциите като backport; според съобщения например Ubuntu 24.04 след актуализацията продължава да показва 8.3.6. Показаният номер казва малко. Обратно, актуален номер не доказва, че всички работни процеси (worker) са рестартирани.
Надеждно е състоянието на пакета с номерата на CVE в журнала на промените, допълнено с рестарт на всички PHP процеси. Как става това, обяснява статията Правилна проверка на версията на PHP и състоянието на пачовете.
Краткотраен изход в уеб контекста все пак има своето място: той показва кой php.ini и кои стойности действително важат за уебсайта, защото командният ред често чете друга конфигурация. Фона за нивата и приоритета обяснява Обяснение на php.ini. Ако Ви трябва, тогава със защита на достъпа, със случайно име на файла и само за минути.
За повечето въпроси така или иначе има по-добри пътища. Версията на PHP на един FPM пул е записана в конфигурацията му и в списъка с процеси. Отделни стойности могат да се запитат със скрипт извън уеб корена чрез ini_get(), без да се разкрива всичко. А в хостинг панелите интерфейсът показва зададената версия за всеки уебсайт, макар и без информация за backport корекции.
Откриване на забравени файлове: конкретни стъпки за проверка
Така откривате остатъци на Linux сървър. Командите само четат и не променят нищо.
- Търсене на файлове с извикване на phpinfo (съобразете пътя):
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
- Проверка на типични имена на файлове, дори без попадение в съдържанието:
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
-
Оценка на попаденията: Не всяко намерено място е тестов файл. Инструменти за администриране, панели или фреймуърци могат да ползват
phpinfo()зад вход. Решаващо е дали файлът е достъпен от интернет без вход. -
Вижте достъпите в журнала, преди да изтриете:
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
- Изтриване и смяна на тайните: Ако в изхода е имало парола или ключ и файлът е бил публичен, стойността се смята за известна. Сменете я.
Намерено място с неизвестна дата на създаване и странно съдържание до извикването на phpinfo може да е и задна врата. Тогава не само изтривайте, а запазете и дайте да проверят, вижте Откриване и премахване на уеб шелове.
Предотвратяване за постоянно вместо почистване
Три мерки гарантират, че темата няма да се върне. Първо: включете phpinfo в списъка disable_functions на php.ini за уеб контекста. Проверете преди това дали Вашият панел ползва функцията за страница със състояние. Как действа настройката и къде са границите ѝ, е описано в Правилно използване на disable_functions.
; 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и други мерки за заздравяване трайно в рамките на заздравяването на сървъра.
Заключение: Един phpinfo файл се създава за секунди и също толкова бързо се забравя. Който го търси и премахва сега, затваря ненужно изтичане на данни и разчита за състоянието на пачовете на надеждни доказателства.
Често задавани въпроси
Самият phpinfo файл уязвимост ли е?
Той не отваря достъп, но дава на атакуващите подробно описание на сървъра: версия, модули, пътища, настройки и, в зависимост от средата, и променливи на средата. Това улеснява целенасочени атаки и може да разкрие данни за достъп.
Доказва ли номерът на версията в phpinfo, че PHP2Shell е пачнат?
Не. Дистрибуциите и хостинг доставчиците често внасят корекциите като backport и показаният номер остава същият. Състоянието на пачовете се доказва с журнала на промените на пакета и потвърждение от доставчика, плюс рестарт на всички PHP процеси.
Какво да направя, ако phpinfo файл е бил публичен по-дълго време?
Изтрийте файла, вижте в журнала за достъп кой го е извиквал и сменете всички тайни, които са се виждали в изхода, например пароли за бази данни или API ключове от променливи на средата.
Мога ли да изключа phpinfo() напълно?
Да, чрез disable_functions в php.ini на уеб контекста. Проверете преди това дали панел или приложение ползва функцията за страници със състояние, и рестартирайте PHP процесите след това.