Как узнать версию PHP на сайте, хостинге и сервере

21 октября 2026 года команда PHP выпустила внеплановые версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две критические уязвимости PHP2Shell, через которые код на сервере выполняется без авторизации. Первое, что нужно сделать владельцу сайта, — узнать версию PHP. Вопрос простой, а ответов бывает три разных: панель хостинга пишет «8.3», консоль — «8.1», а исправленный PHP на Ubuntu 24.04 по-прежнему называет себя 8.3.6.

Ниже — все способы посмотреть версию PHP: в панели хостинга, в WordPress, через phpinfo(), по заголовкам ответа и в консоли VPS. Для каждого показываем, что именно он покажет и где обманет. Команды мы сверили с man-страницами и файлами пакетов Debian 12, Debian 13, Ubuntu 22.04 и 24.04, поведение WordPress — с исходным кодом ядра. Данные о версиях и бюллетенях — на 22.10.2026. Подробности самой уязвимости — в нашей новости о PHP2Shell.

Какие версии считаются исправленными

Номер, с которым сверяться, зависит от того, откуда взят PHP. Если его собрали из исходников или взяли официальный Docker-образ php, ориентир — версии с php.net. Если PHP пришёл из пакетов Ubuntu, Debian или другого поставщика (в том числе внутри своего Docker-образа), ориентир — ревизия пакета из бюллетеня этого поставщика.

Для веток 8.1 и старше проект PHP исправлений больше не выпускает. Что делать, если у вас такая версия, разобрали в последнем разделе.

Где смотреть версию PHP и что вы там увидите

У каждого способа своя «точка зрения». Панель знает, какую ветку вы выбрали для сайта. Консоль знает, какой PHP запускается из терминала. Пакетный менеджер знает, какая ревизия установлена. Сводная таблица:

Панель хостинга: версия задаётся для каждого сайта

На виртуальном хостинге версию PHP выбирают в панели, и у двух сайтов на одном аккаунте она может различаться. Вот где её найти у популярных панелей (по документации на 22.10.2026):

• Beget — раздел «Сайты», иконка в строке нужного сайта, на странице настроек можно сменить версию PHP (база знаний Beget). Сборки разных версий лежат в /usr/local/php-cgi/X.X/.
• Timeweb — «Сайты», шестерёнка у сайта, блок «Настройки версии и кодировки». Список доступных версий зависит от ОС сервера: на Ubuntu 22.04 — 7.4–8.5 (документация Timeweb).
• ISPmanager 6 — «Сайты», выбрать сайт, блок «Обработчик (PHP)». Список установленных версий — в «Настройки → Настройки PHP» (документация ISPmanager).
• cPanel — интерфейс MultiPHP Manager: для каждого домена видна версия, метка Inherited, если домен берёт системную версию, и признак PHP-FPM (документация cPanel).

Панель показывает ветку, а не уровень исправлений. Строка «PHP 8.3» в настройках сайта не отвечает на вопрос, стоит ли на сервере 8.3.36. На виртуальном хостинге PHP обновляет хостер, поэтому смотрите его новости или спросите поддержку, применены ли исправления от 21 октября. Например, NetAngels сообщила 21.10.2026, что обновила PHP 5.6, 7.4+ и 8.2+, а владельцам сайтов на 7.0–7.3 и 8.0–8.1 рекомендовала сменить версию. Beget в тот же день ограничила механизм upload_progress и предупредила, что меры не гарантируют полной защиты. Какие хостеры дают свежие ветки PHP, видно в разделе хостинга с PHP. Чем панели отличаются между собой, мы разбирали в обзоре панелей управления хостингом.

WordPress: «Здоровье сайта» и его слепая зона

В WordPress версия PHP видна без доступа к серверу: «Инструменты → Здоровье сайта → Информация → Сервер» (документация WordPress). Там два полезных поля: «Версия PHP» и «PHP SAPI». Это данные того PHP, который прямо сейчас исполняет WordPress, — самый честный ответ на вопрос «на чём работает сайт». Если в SAPI стоит fpm-fcgi, сайт обслуживает PHP-FPM, если apache2handler — модуль Apache.

Вкладка «Статус» оценивает версию по API WordPress.org, и оценка эта грубая. В исходном коде ядра (class-wp-site-health.php) прямо написано, что флаг is_secure не означает безопасную версию, а лишь то, что ветка получает обновления безопасности. Мы запросили этот API 22.10.2026: для 8.3.6 он ответил «рекомендуемая версия», для 8.1.2 — is_secure: true, хотя ветка 8.1 на php.net поддержку уже не получает. Зелёная плашка в «Здоровье сайта» не значит, что PHP2Shell закрыт.

WordPress рекомендует PHP 8.3 или новее. Если вы управляете сайтом через WP-CLI, учтите: команда wp --info показывает консольный PHP и его php.ini, который, как пишет документация WP-CLI, обычно отличается от веб-версии. Хостинг под WordPress со свежим PHP можно подобрать в разделе хостинга для WordPress, а разницу между shared, VPS и managed — в гайде о хостинге для WordPress.

phpinfo(): полная картина и почему файл надо удалить

Функция phpinfo() выводит, по описанию в документации PHP, версию, параметры сборки, расширения, пути, значения настроек, HTTP-заголовки и все данные окружения, GET, POST, cookie и сервера. Для проверки версии там нужны три строки: PHP Version, Server API и Loaded Configuration File. Последняя показывает, какой php.ini реально прочитан — например, /etc/php/8.3/fpm/php.ini.

Оставленный в корне сайта info.php — подарок для атакующего. В выводе видны точная версия, пути к файлам, включённые функции и переменные окружения. Если пароль к базе или ключи API переданы через переменные окружения, они тоже окажутся в выводе. Безопаснее вывести только версию и режим и сразу удалить файл:

# В корне сайта на сервере (путь замените на свой)
cd /var/www/example.com/public
name="v-$(openssl rand -hex 8).php"
printf '<?php echo PHP_VERSION, " ", PHP_SAPI, "\\n";' > "$name"
curl -s "https://example.com/$name"    # пример ответа: 8.3.6 fpm-fcgi
rm -f "$name"

Случайное имя затрудняет угадывание адреса, но файл остаётся публичным, пока вы его не удалите. Если доступа по SSH нет, тот же файл можно загрузить через файловый менеджер панели, открыть в браузере и удалить. Если полный phpinfo() всё же нужен, держите файл минуты, а не дни.

Заголовок X-Powered-By: отсутствие не значит «безопасно»

Самый быстрый способ — посмотреть заголовки ответа сайта:

curl -sI https://example.com/ | grep -iE '^(server|x-powered-by):'

Строка X-Powered-By: PHP/8.3.6 сообщает заявленную версию. Заголовок могли подменить или отдать из кэша, поэтому подтверждать её лучше через сам PHP сайта. Заголовок управляется директивой expose_php, а в эталонном php.ini-production из исходников PHP она включена: expose_php = On.

Пустой результат говорит только о том, что заголовка нет. Его мог убрать админ (expose_php = Off), отрезать CDN или кэширующий прокси, а страница могла прийти из кэша без участия PHP. Версия при этом может быть любой, в том числе уязвимой. Сканерам и эксплойтам версия не нужна: вредоносный запрос просто отправляют на сайт. Документация PHP в разделе Hiding PHP называет сокрытие «одной из самых слабых форм безопасности». Выключить заголовок полезно, но это не защита.

Консоль: php -v показывает CLI, а сайт работает через FPM или mod_php

Команда php -v выводит версию и в скобках имя SAPI, например PHP 8.3.6 (cli) (built: …). Слово cli важнее цифр: это интерпретатор для терминала и cron. Сайт обслуживает другой процесс — PHP-FPM, модуль Apache, php-cgi или LiteSpeed. У каждого свой php.ini, а версия может отличаться. Так же устроены php -i и php --ini: они показывают настройки CLI, а не веба (параметры командной строки PHP).

Версию веб-PHP на Ubuntu и Debian смотрят так:

# PHP-FPM: в скобках будет fpm-fcgi
php-fpm8.3 -v

# Какие пулы FPM запущены и с какими конфигами
systemctl list-units --type=service --all 'php*-fpm*'
ps -eo pid,lstart,cmd | grep '[p]hp-fpm: master'

# Apache: включён ли модуль PHP (php8.3) или связка с FPM (php8.3-fpm)
a2query -m | grep -i php
a2query -c | grep -i php

Имена бинарников в Debian и Ubuntu содержат ветку: /usr/sbin/php-fpm8.2 в пакете php8.2-fpm, /usr/bin/php8.2 в php8.2-cli. Подставьте свою. Если Apache и FPM вам в новинку, начните со сравнения Nginx и Apache и гайда по установке LAMP.

Несколько версий PHP на одном сервере

На VPS часто живут две-три ветки PHP: старая осталась после переезда, новую поставили из репозитория Ondřej Surý, третью принесла панель. Из-за этого php -v показывает 8.3, а сайт продолжает работать на 8.1. Проверку начинают с того, что установлено:

# Ветки из пакетов дистрибутива и репозитория sury
ls /etc/php/

# Какой PHP вызывается командой php и какие ещё доступны
update-alternatives --display php

Пакет php8.x-cli в Debian и Ubuntu регистрирует /usr/bin/php через update-alternatives с приоритетом вида «82» для 8.2 и «83» для 8.3. В автоматическом режиме выбирается вариант с наибольшим приоритетом (man update-alternatives). Поставили новую ветку — команда php переключилась на неё, а сайты остались на прежних пулах FPM.

Какую версию получает конкретный сайт, видно по сокету FPM в конфиге веб-сервера. В Debian и Ubuntu пул по умолчанию слушает /run/php/php8.X-fpm.sock, а номер ветки стоит прямо в имени:

# nginx: в fastcgi_pass будет сокет вида unix:/run/php/php8.1-fpm.sock
grep -Rn 'fastcgi_pass' /etc/nginx/sites-enabled/ /etc/nginx/conf.d/

# Apache с FPM: SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
grep -RnE 'proxy:unix|SetHandler' /etc/apache2/sites-enabled/ /etc/apache2/conf-enabled/

# Если в конфиге общий сокет без номера, смотрим, куда он ведёт
ls -l /run/php/

Панели добавляют свои сборки в отдельные каталоги. В ISPmanager альтернативные версии ставятся в /opt/ из репозитория панели, а «нативная» берётся из ОС (документация ISPmanager). На хостинге Timeweb консольные версии лежат в /opt/phpXX/bin. Как обновляются такие сборки, зависит от их поставщика и подключённого репозитория, поэтому сверяйтесь с инструкциями и списком изменений панели, а не только с бюллетенем дистрибутива. Саму панель тоже нужно держать обновлённой: 11–17 октября атаковали панель VMmanager 6. Это отдельный инцидент, связь с PHP2Shell не установлена, подробности в материале о FirstVDS. Как устроена ISPmanager, мы описали в отдельном гайде.

Пакеты дистрибутива: почему Ubuntu после патча показывает 8.3.6

Ubuntu не переводит LTS-релиз на новые версии PHP, а переносит исправления в старую. После обновления по USN-8948-1 на Ubuntu 24.04 и php -v, и «Здоровье сайта» по-прежнему пишут 8.3.6. Исправление видно только в ревизии пакета: 8.3.6-0ubuntu0.24.04.13. Человек, который ждёт «8.3.36», решит, что сервер не обновлён, а тот, кто видит «8.3.6», не поймёт, есть ли патч. На Ubuntu 22.04 так же: исправленный пакет называется 8.1.2-1ubuntu2.28, а php -v показывает 8.1.2.

Debian в этот раз поступил иначе и выпустил апстримные версии: 8.2.35-1~deb12u1 для Debian 12 и 8.4.27-1~deb13u1 для Debian 13. Правило от этого не меняется: сверяют ревизию пакета с бюллетенем, а не номер из php -v. По трекеру Debian, в основном репозитории bookworm на 22.10.2026 лежит уязвимая 8.2.32-1~deb12u1, исправление пришло только в репозиторий безопасности. Если он не подключён, apt upgrade ничего не принесёт.

# Установленные пакеты PHP и их ревизии
dpkg -l 'php*' | awk '/^ii/ {print $2, $3}'

# Установленная и доступная версия, из какого репозитория (ищите -security)
apt-cache policy php8.3-fpm

# Вспомогательно: упоминаются ли CVE PHP2Shell в changelog установленных пакетов
zgrep -cE 'CVE-2026-10961[89]' /usr/share/doc/php8.3-*/changelog.Debian.gz

Главная проверка — ревизия пакета, который обслуживает сайт (php8.3-fpm или libapache2-mod-php8.3), сверенная с бюллетенем. Поиск по changelog лишь подтверждает её: ненулевой счётчик значит, что запись о CVE есть в changelog установленной версии. В changelog пакета Ubuntu 8.3.6-0ubuntu0.24.04.13 на Launchpad есть запись «SECURITY UPDATE» с обоими номерами CVE. На RHEL, AlmaLinux и Rocky аналог — rpm -q --changelog php-fpm | grep -m3 CVE-2026-10961.

Обновлённый пакет ещё не значит обновлённый процесс. Воркеры, запущенные до обновления, продолжают выполнять старый код, пока их не перезапустят. Сравните время старта мастер-процесса FPM со временем установки пакета:

ps -eo pid,lstart,cmd | grep '[p]hp-fpm: master'
# Журнал dpkg ротируется, поэтому смотрим и архивы
zgrep -hE ' (upgrade|install) php8\.3-fpm' /var/log/dpkg.log* | sort | tail -1

# Если процесс старше пакета
sudo systemctl restart php8.3-fpm
# Для mod_php нужен именно restart, а не reload
sudo systemctl restart apache2

Что делать, если версия ниже 8.2

По бюллетеню PHP, ветки 8.1 и старше обновлений от проекта больше не получают. Для 7.4, 8.0 и 8.1 опубликованы только минимальные исходные патчи для тех, кто собирает PHP сам, для 7.3 и старше от PHP нет ничего. Ветка 8.2 по графику поддержки получает исправления безопасности до 31.12.2026, то есть ещё два месяца. Целиться стоит в 8.3 (поддержка до конца 2027 года) или 8.4 (до конца 2028-го). Порядок действий зависит от того, где работает сайт:

• Виртуальный хостинг. Переключите сайт на 8.3 или 8.4 в панели, сначала проверив совместимость плагинов и сделав копию. Пошагово — в гайдах как обновить PHP на хостинге и бэкап WordPress перед обновлением PHP. Если нужной версии в панели нет, это повод сменить хостинг: варианты есть в разделе виртуального хостинга.
• VPS на Ubuntu 22.04 с PHP 8.1. Здесь ветку 8.1 поддерживает сам Ubuntu, и пакет 8.1.2-1ubuntu2.28 исправлен (USN-8948-1). Сайт можно не останавливать, но переход на 8.3 стоит запланировать: как обновить PHP на VPS.
• PHP 7.x или 8.0 из старых сборок. Новых релизов этих веток нет: для 7.4 и 8.0 есть только исходные патчи, для 7.3 и старше — ничего. Готовые пакеты выпускают отдельные поставщики: Ubuntu Pro для старых LTS, CloudLinux (для части версий), репозиторий sury.org. Если ничего из этого нет, CISA в своём предупреждении от 21.10.2026 советует убрать такие системы из интернета до обновления. Если сервер пора менять целиком, свежие образы Linux есть в каталоге VPS на Linux.

Временные меры из бюллетеня PHP — отключение session.upload_progress, снятие лимита памяти PHP (memory_limit=-1) с ограничением памяти на уровне контейнера, уменьшение post_max_size — разработчики сами называют неполными: они снижают риск, но не делают установку безопасной. WAF перед сайтом тоже лишь выигрывает время, подробнее — в гайде WAF для сайта. Что такое CVE и как читать такие бюллетени, объясняет статья глоссария про CVE.

Порядок проверки за десять минут

1. Откройте «Здоровье сайта» или загрузите одноразовый файл с PHP_VERSION и PHP_SAPI — так вы узнаете, на чём работает сайт, а не терминал.
2. Сверьте ветку с панелью хостинга. На shared-хостинге спросите поддержку, применены ли исправления от 21.10.2026.
3. На VPS найдите пул FPM или модуль Apache, который обслуживает сайт: сокет в конфиге nginx или Apache.
4. Сверьте ревизию пакета этой ветки (dpkg -l, apt-cache policy) с бюллетенем — на Ubuntu и Debian номер из php -v о патче не скажет.
5. Убедитесь, что процессы FPM или Apache перезапущены после обновления.
6. Если ветка 8.1 или старше и поставщик её не поддерживает, переходите на 8.3 или 8.4. Если ваш хостер не даёт свежий PHP, подходящий VPS или хостинг можно подобрать в нашем каталоге.