Накратко: Ако php -v показва след актуализацията същата версия, най-често причината е backport: дистрибуцията вгражда само поправката за сигурност в съществуващата си PHP версия и номерът остава същият. Ubuntu 24.04 така продължава да съобщава 8.3.6, въпреки че пакетът е коригиран срещу PHP2Shell. Изяснете въпроса чрез състоянието на пакета и changelog-а и проверете допълнително дали уебсайтът наистина работи с новия код.
Типичен момент след PHP2Shell
Админът е инсталирал актуализацията, всичко без грешки. За контрол въвежда php -v и вижда същата версия като преди. Не е ли сработила актуализацията? Сървърът още ли е отворен? Този въпрос е сред най-честите от 21 октомври 2026 г. насам.
Добрата новина: в повечето случаи всичко е наред. Лошата: има и случаи, в които същият номер действително сочи към проблем. Тази статия помага да се разграничи едното от другото.
Защо дистрибуциите не променят номера
Корпоративните и LTS дистрибуциите обещават стабилност. В рамките на едно издание поведението и интерфейсите по възможност не трябва да се променят. Скок от PHP 8.3.6 на 8.3.36 би донесъл множество поправки на грешки и малки промени в поведението, които биха могли да смутят приложенията.
Затова много поддържащи на пакети вграждат само конкретната поправка за сигурност в съществуващата си версия. Този процес се нарича backport. Upstream версията, която самият PHP съобщава чрез php -v, остава същата. Променя се състоянието на пакета, което дистрибуцията присвоява.
На примера на Ubuntu 24.04 това изглежда така: PHP съобщава 8.3.6. Коригираното състояние на пакета обаче според USN-8948-1 е 8.3.6-0ubuntu0.24.04.13. Броя се задната част. Debian реши при PHP2Shell по друг начин и за bookworm и trixie достави новите upstream версии 8.2.35 и 8.4.27. Прегледът по издания е в статията Debian и Ubuntu: пачнат ли е моят PHP пакет?.
Струва си веднъж да разчленим такава версия на пакет. На примера 8.3.6-0ubuntu0.24.04.13: частта пред тирето е upstream версията, тоест това, което самият PHP съобщава. След нея следва ревизията на дистрибуцията. ubuntu0.24.04 сочи към изданието, последното число отброява преработките. Всяка поправка за сигурност увеличава това число. При Ubuntu Pro се появява допълнително добавка като +esm5, при актуализациите за сигурност на Debian - като ~deb12u1. Който умее да чете тези части, разпознава с един поглед дали пакетът е променян след съобщение за сигурност.
Къде навсякъде се появява старият номер
Непроменената версия се появява не само в php -v. Тя стои и на места, които се виждат отвън или се анализират от инструменти:
| Място | Какво стои там | Последица |
|---|---|---|
php -v и php -i |
Upstream версия, дата на компилация | Админите се съмняват в актуализацията |
| страница с phpinfo | Upstream версия | същият ефект в браузъра |
заглавие X-Powered-By |
Upstream версия, ако expose_php е включено |
външни скенери съобщават уязвимост |
| Хостинг панели като Plesk | Upstream версия | показване например на 8.2.34 въпреки пача |
| Скенери за уязвимости | сравнение по номер | фалшива тревога при backport-ове |
Външните скенери са отделен случай. Който ги ползва, след PHP2Shell евентуално получава находки за сървъри, които отдавна са коригирани. Не пренебрегвайте тези находки като цяло, а докажете за всеки сървър състоянието на пакета и отбележете находката като проверена. Още една причина указанията за версия да се скриват отвън има в статията expose_php и заглавия на сървъра.
Кога същият номер е предупредителен сигнал
Има три ситуации, в които непромененият номер действително сочи към проблем:
- Източникът на пакети доставя upstream версията. Ако PHP идва от източник, който обикновено доставя актуалната upstream версия, например Debian при PHP2Shell или външни източници като Remi и sury.org, след актуализацията трябва да се появи 8.5.12, 8.4.27, 8.3.36 или 8.2.35. Ако там още стои старият номер, пакетът не е бил актуализиран.
- Проверявате погрешната инсталация.
php -vпоказва командния ред. Ако уебсайтът работи през друга версия, например от хостинг панел или Software Collection, изходът не казва нищо за уебсайта. - Състоянието на пакета не се е променило. Ако и състоянието на пакета е същото като преди актуализацията, актуализацията за този пакет не е пристигнала, например защото е бил задържан или източникът липсва.
За нетехниците това може да се обобщи така: номерът на версията описва модела, състоянието на пакета - състоянието на поддръжката. Два сървъра със същата PHP версия могат значително да се различават по сигурност. Затова не питайте Вашата ИТ или доставчика на услуги за версията, а за доказателството за пача.
Как да изясните въпроса за пет минути
Следните команди са само за четене. Примерите изхождат от Ubuntu или Debian и PHP 8.3; на RHEL системи ползвайте rpm -q вместо dpkg-query.
# 1. Какво съобщава самият PHP, включително дата на компилация?
php -v
# 2. Кое състояние на пакета е инсталирано, от кой източник?
apt policy php8.3-fpm
# 3. Съдържа ли changelog-ът номерата CVE?
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"
# 4. Откога работят PHP процесите на уебсайта?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Датата на компилация в изхода на php -v е указание, но не доказателство. Надеждното доказателство дава записът в changelog-а. Как да го намерите и запишете, когато е формулиран другояче или липсва, описва статията Доказване на номера CVE в changelog-а на пакета.
След всяка проверка записвайте и двата номера: upstream версията от php -v и състоянието на пакета. Който по-късно попита защо сървърът е „още на 8.3.6“, получава така ясен отговор.
Общата проверка чрез версия, пакет и процеси обобщава страницата Проверка на PHP версията и състоянието на пача.
Как помага PHP SOS конкретно?
- Изясняваме за всеки сървър дали непроменен номер на версия е backport или липсваща актуализация.
- Оценяваме находките от скенерите за уязвимости и доказваме фалшивите тревоги със състоянието на пакета и changelog-а.
- Проверяваме коя PHP инсталация уебсайтът наистина ползва и дали процесите ѝ са рестартирани.
- В услугата за пач на PHP документираме една до друга upstream версията и състоянието на пакета.
Често задавани въпроси
Непачнат ли е сървърът ми, ако php -v показва стария номер?
Не непременно. Много дистрибуции вграждат поправките като backport в съществуващата версия. Ubuntu 24.04 например продължава да показва 8.3.6, въпреки че пакетът според USN-8948-1 е коригиран. Решаващи са състоянието на пакета и changelog-ът.
Защо скенерът ми за сигурност съобщава уязвимост въпреки актуализацията?
Много скенери четат само номера на версията, например от заглавието X-Powered-By. При backport-ове това води до фалшиви тревоги. Проверете състоянието на пакета и документирайте резултата, вместо просто да пренебрегнете находката.
Възможно ли е php -v да показва нов номер, а уебсайтът да не?
Да. php -v показва командния ред. Уебсайтът може да работи през друга инсталация или през процеси, стартирани преди актуализацията. Затова проверете и FPM услугата или Apache и времето им на стартиране.
Помага ли датата на компилация в изхода на php -v?
Тя е указание, но не доказателство. Дата на компилация след 21 октомври 2026 г. подхожда на коригиран пакет, но не доказва, че поправката е включена. Записът в changelog-а е по-доброто доказателство.