# Защо php -v показва същия номер след актуализацията

> php -v показва същия номер след актуализацията? Защо backport-овете причиняват това, кога е безобидно, кога е предупредителен сигнал и как да го изясните.

Източник: https://phpsos.de/bg/blog/php-v-zeigt-alte-nummer/  
Актуалност: 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

**Накратко:** Ако `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 пакет?](https://phpsos.de/bg/blog/debian-ubuntu-paket-gepatcht/).

Струва си веднъж да разчленим такава версия на пакет. На примера `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 и заглавия на сървъра](https://phpsos.de/bg/blog/expose-php-versionsangaben/).

## Кога същият номер е предупредителен сигнал

Има три ситуации, в които непромененият номер действително сочи към проблем:

1. **Източникът на пакети доставя upstream версията.** Ако PHP идва от източник, който обикновено доставя актуалната upstream версия, например Debian при PHP2Shell или външни източници като Remi и sury.org, след актуализацията трябва да се появи 8.5.12, 8.4.27, 8.3.36 или 8.2.35. Ако там още стои старият номер, пакетът не е бил актуализиран.
2. **Проверявате погрешната инсталация.** `php -v` показва командния ред. Ако уебсайтът работи през друга версия, например от хостинг панел или Software Collection, изходът не казва нищо за уебсайта.
3. **Състоянието на пакета не се е променило.** Ако и състоянието на пакета е същото като преди актуализацията, актуализацията за този пакет не е пристигнала, например защото е бил задържан или източникът липсва.

За нетехниците това може да се обобщи така: номерът на версията описва модела, състоянието на пакета - състоянието на поддръжката. Два сървъра със същата PHP версия могат значително да се различават по сигурност. Затова не питайте Вашата ИТ или доставчика на услуги за версията, а за доказателството за пача.

## Как да изясните въпроса за пет минути

Следните команди са само за четене. Примерите изхождат от Ubuntu или Debian и PHP 8.3; на RHEL системи ползвайте `rpm -q` вместо `dpkg-query`.

```bash
# 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-а на пакета](https://phpsos.de/bg/blog/cve-im-changelog-nachweisen/).

> **Съвет:**
> След всяка проверка записвайте и двата номера: upstream версията от `php -v` и състоянието на пакета. Който по-късно попита защо сървърът е „още на 8.3.6“, получава така ясен отговор.

Общата проверка чрез версия, пакет и процеси обобщава страницата [Проверка на PHP версията и състоянието на пача](https://phpsos.de/bg/php2shell/php-version-pruefen/).

## Как помага PHP SOS конкретно?

- Изясняваме за всеки сървър дали непроменен номер на версия е backport или липсваща актуализация.
- Оценяваме находките от скенерите за уязвимости и доказваме фалшивите тревоги със състоянието на пакета и changelog-а.
- Проверяваме коя PHP инсталация уебсайтът наистина ползва и дали процесите ѝ са рестартирани.
- В [услугата за пач на PHP](https://phpsos.de/bg/leistungen/php-patch-service/) документираме една до друга 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-а е по-доброто доказателство.

## Източници

- [Ubuntu Security Notice USN-8948-1](https://ubuntu.com/security/notices/USN-8948-1)
- [Debian Security Tracker: CVE-2026-109618](https://security-tracker.debian.org/tracker/CVE-2026-109618)
- [php.net: Съобщения за сигурност](https://www.php.net/)