Накратко: За да проверите CVE в changelog, потърсете в дневника на промените на инсталирания PHP пакет CVE-2026-109618 и CVE-2026-109619: при Debian и Ubuntu в /usr/share/doc/<paket>/changelog.Debian.gz, при RPM системи с rpm -q --changelog. Намереният запис, заедно със състоянието на пакета, сверката с официалното съобщение за сигурност и момента на рестарта, е надеждно доказателство. Липсата на запис още не е доказателство за отворена уязвимост.
Защо доказателството е повече от „пачнахме“
След PHP2Shell мнозина искат да знаят дали сървърите им са сигурни: ръководството, длъжностното лице по защита на данните, клиентите с обработване по поръчка, понякога и киберзастрахователят. „Пачнахме“ не стига за това. Търси се доказателство, което трето лице може да проследи.
Номерът на версията често не е подходящ, защото дистрибуциите внасят поправките като backport и номерът остава същият. По-добра основа е changelog на пакета. Пише го поддържащият на пакета и при актуализациите за сигурност по правило изброява отстранените CVE номера.
Къде са changelog файловете
Всеки формат на пакети има собствено място. Следният преглед помага да стигнете бързо до правилното.
| Система | Място на changelog | Команда за търсене |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<paket>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (онлайн) | Архив на пакетите на дистрибуцията | apt changelog <paket> |
| RHEL, AlmaLinux, Rocky, Fedora | База данни на RPM пакетите | rpm -q --changelog <paket> |
| Контейнерни образи | в образа, както в базовата система | изпълнете командата в контейнера |
При Debian и Ubuntu директорията с документацията на някои двоични пакети сочи със символична връзка към общ пакет, например php8.3-common. Ако zgrep не намира файла, прегледайте директорията с ls -l /usr/share/doc/ | grep php.
Проверка на CVE в changelog: как да действате
Следните команди са само за четене. Пригодете имената на пакетите към Вашата инсталация.
# Debian/Ubuntu: локално, без мрежа
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu: заглавен ред на най-новия запис със състояние на пакета и дата
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# RHEL семейство: запис заедно с дата и състояние на пакета
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
При Debian и Ubuntu състоянието на пакета стои в заглавния ред на всеки запис, а датата в завършващия ред. При RPM и двете стоят в реда над записите. Така виждате не само дали CVE е споменато, но и с кое състояние на пакета. Сравнете това състояние с инсталираното, например чрез dpkg-query -W или rpm -q. Ако съвпадат, поправката се съдържа в работещия пакет.
Пакети на панели и контейнери
Хостинг панелите носят собствени PHP пакети, например Plesk или cPanel. И те са обикновени DEB или RPM пакети, чийто changelog се чете със същите инструменти. Дали доставчиците споменават в него CVE номера, или само новата версия на PHP, е различно. Ако пакетът назовава upstream версията 8.5.12, 8.4.27, 8.3.36 или 8.2.35, това е достатъчно като доказателство; при backport-ове със стар номер Ви трябва информация от доставчика.
При контейнерите доказателството принадлежи към образа, не към хоста. Проверете пакетите в образа, от който е стартиран работещият контейнер, и допълнително запишете digest на образа. Така по-късно може да се проследи кое състояние действително е работило, дори образът под същия таг междувременно да е бил построен наново.
Когато CVE липсва в changelog
Липсващият запис има няколко възможни причини. Преминете през тях в този ред:
- Търсен е грешен пакет: При няколко PHP клона или източника на един сървър отговорът често е в changelog на друг пакет.
- Upstream версия вместо CVE: Ако източникът доставя новата upstream версия, например 8.4.27, в changelog евентуално стои само „New upstream version“. Тогава самият номер на версията е доказателството, защото php.net посочва версиите 8.5.12, 8.4.27, 8.3.36 и 8.2.35 като коригирани.
- Друга формулировка: Някои поддържащи назовават номера на бъгове или идентификатори на съобщения като GHSA-w8hw-w9fx-j79w и GHSA-6wmf-4rv5-p3rp вместо CVE.
- Сверка с съобщението за сигурност: Ако официалното съобщение на Вашата дистрибуция, например USN или Debian Security Tracker, назовава коригирано състояние на пакета и то или по-ново е инсталирано, това също е доказателство. Състоянията за Debian и Ubuntu ще намерите в статията Debian и Ubuntu: пачнат ли е моят PHP пакет?, а за RHEL семейството в RHEL, AlmaLinux и Rocky Linux.
- Попитайте доставчика: При пакети на панели, билдове на хостера или външни източници помага само писмена информация. Образец предлага ръководството Попитайте хостера за състоянието на пача.
Ако след тези стъпки не остане доказателство, третирайте сървъра като непачнат и въведете преходни мерки, докато въпросът се изясни.
От записа до доказателството
Един запис в changelog доказва, че пакетът съдържа поправката. Той не доказва, че работещите процеси я ползват. Затова пълното доказателство съдържа пет данни за всеки сървър и всяка PHP инсталация:
- сървър, PHP клон и режим на работа, например PHP-FPM или mod_php
- инсталирано състояние на пакета и източник на пакета
- място в changelog или препратка към официалното съобщение за сигурност
- момент на актуализацията и време на стартиране на работещите PHP процеси
- име на проверяващото лице и дата на проверката
Запазете суровия изход на командите като текстов файл до доказателството. По-късно е по-лесно да се проследи, отколкото резюме по памет.
Доказателството отговаря само на въпроса дали уязвимостта е била затворена от определен момент. За времето преди това Ви трябват логовете от 20 октомври 2026 г. насам и при нужда търсене на следи. Общия ход на проверката на версията описва страницата Правилна проверка на версията на PHP и състоянието на пача.
Как помага PHP SOS конкретно?
- Претърсваме changelog файловете на всички PHP пакети на Вашите сървъри и ги сверяваме с официалните съобщения за сигурност.
- Където changelog мълчи, изясняваме състоянието с дистрибуцията, доставчика на панела или хостера.
- Проверяваме дали работещите процеси са рестартирани след актуализацията.
- С PHP Patch Service получавате доказателството за всеки сървър във форма, която можете да предадете на трети лица.
Често задавани въпроси
Защо версията на PHP не стига като доказателство?
Много дистрибуции вграждат поправките за сигурност като backport, без да променят версията на PHP. Тогава номерът на версията не казва нищо за пача. Changelog на инсталирания пакет, напротив, назовава отстранените CVE номера.
Какво значи, ако CVE липсва в changelog?
Може да означава, че поправката липсва. Възможно е обаче поддържащият на пакета да е формулирал иначе, например с номер на бъг или с upstream версия. Тогава сверете състоянието на пакета с официалното съобщение за сигурност или попитайте доставчика.
Колко дълго трябва да пазя доказателството?
Докато може да е от значение за вътрешни проверки, застрахователи или евентуални въпроси по защитата на данните. Съхранявайте го заедно с логовете от 20 октомври 2026 г. насам. Конкретните срокове изяснете с длъжностното лице по защита на данните или с правен съветник.
Мога ли да проверя changelog и без достъп до интернет?
Да. Debian и Ubuntu съхраняват changelog на всеки пакет локално в /usr/share/doc, RPM системите го пазят в базата данни на пакетите. И двете могат да се прочетат без мрежа.