Текуща ситуация: PHP2Shell. Две критични уязвимости в PHP (CVSS 9,2) позволяват злонамерен код без вход. Корекции от 21.10.2026 г.Какво да направите сега →

Debian и Ubuntu: пачнат ли е моят PHP пакет?

Кои PHP пакети Debian и Ubuntu са коригирали срещу PHP2Shell, как да сравните точно инсталираното състояние и къде се проваля доказването.

Актуалност 5 мин. четенеХостинг и дистрибуции

Накратко: Дали Вашият PHP пакет под Debian или Ubuntu е пачнат срещу PHP2Shell, разпознавате по точното състояние на пакета, не по PHP версията. Ubuntu публикува на 21 октомври 2026 г. коригирани пакети за всички поддържани издания, по-старите чрез Ubuntu Pro. Debian коригира php8.2 в bookworm и php8.4 в trixie. Сравнете инсталираното състояние с dpkg --compare-versions и след това рестартирайте всички PHP услуги.

Въпросът зад въпроса

„Пачнат ли е моят PHP пакет?“ звучи като въпрос с отговор да или не. На практика отговорът зависи от три неща: от кой източник е пакетът, кое състояние е инсталирано и работи ли това състояние наистина? Тази статия отговаря на първите две точки за официалните пакети на Debian и Ubuntu. Как принципно да проверите версията и работещите процеси, пише в Проверка на PHP версията и състоянието на пача.

Извлякохме данните от официалните съобщения за сигурност на Ubuntu и от Debian Security Tracker на 25 октомври 2026 г. И двете CVE, CVE-2026-109618 и CVE-2026-109619, са посочени там със същите коригирани състояния.

Коригирани състояния на пакетите при Ubuntu

Ubuntu публикува поправките с две съобщения. USN-8948-1 покрива актуалните издания, USN-8948-2 по-старите, които получават актуализации за сигурност само още чрез Ubuntu Pro. При 16.04 и 14.04 Ubuntu допълнително посочва предложението Legacy Support.

Издание на Ubuntu Изходен пакет Коригирано състояние
26.10 php8.5 8.5.9-0ubuntu2.1
26.04 LTS php8.5 8.5.4-0ubuntu1.5
24.04 LTS php8.3 8.3.6-0ubuntu0.24.04.13
22.04 LTS php8.1 8.1.2-1ubuntu2.28
20.04 LTS (Ubuntu Pro) php7.4 7.4.3-4ubuntu2.29+esm5
18.04 LTS (Ubuntu Pro) php7.2 7.2.24-0ubuntu0.18.04.17+esm14

Забележително е, че всички състояния запазват първоначалната PHP версия. Ubuntu 24.04 остава на 8.3.6, въпреки че поправката е взета от 8.3.36. Защо е така и как да се справите с това, обяснява статията Защо php -v показва същия номер. Засегнати са във всеки случай между другото двоичните пакети за FPM, CLI, CGI и модула за Apache, например php8.3-fpm и libapache2-mod-php8.3.

Коригирани състояния на пакетите при Debian

Debian тръгва тук по друг път и доставя новите upstream версии. Според Security Tracker състоянието изглежда така:

Издание на Debian Изходен пакет Предишно състояние Коригирано състояние Съобщение
12 bookworm php8.2 8.2.32-1~deb12u1 8.2.35-1~deb12u1 DLA-4848-1
13 trixie php8.4 8.4.24-1~deb13u1 8.4.27-1~deb13u1 DSA-6574-1
forky, sid php8.4 8.4.27-1

Съобщението за bookworm излезе като DLA, тоест чрез Debian LTS. За php8.2 в unstable trackerът при извличането още не води коригирано състояние. Който поддържа тестови системи на unstable, трябва да следи това.

По-старите издания на Debian при извличането не се появяват в двата записа за CVE. Ако сървър още работи на такова издание, например Debian 11 с PHP 7.4, не можете да разчитате на актуализация за сигурност от официалния архив. Тогава остават три пътя: да повдигнете операционната система до поддържано издание, да ползвате търговско предложение за дългосрочна поддръжка, чието покритие за PHP2Shell да Ви бъде потвърдено писмено, или да защитите сървъра до миграцията с временни мерки и да ограничите достъпността му. Трайно носим е само първият път.

Как да сравните точно инсталираното състояние

Поглед към номера на версията не стига, защото версиите на Debian се подреждат по собствени правила. dpkg --compare-versions сравнява правилно. Следните команди са само за четене; приспособете имената на пакетите и целевото състояние към Вашето издание.

# Инсталирано състояние и произход на пакета
apt policy php8.3-fpm

# Всички инсталирани PHP пакети с версия
dpkg-query -W -f='${Package}\t${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null

# Точно сравнение с коригираното състояние (пример Ubuntu 24.04)
v=$(dpkg-query -W -f='${Version}' php8.3-fpm)
dpkg --compare-versions "$v" ge 8.3.6-0ubuntu0.24.04.13 && echo "korrigiert: $v" || echo "PRÜFEN: $v"

В изхода на apt policy внимавайте за реда с източника на пакета. Ако там не стои архивът за сигурност на Вашата дистрибуция, а например packages.sury.org или PPA, таблиците по-горе не важат. Тогава се брои състоянието на този външен източник, което разглеждаме в статията Хранилището sury.org.

Допълнително си струва погледът в доставения changelog. Как да намерите там номерата CVE и да ги запишете като доказателство, описва статията Доказване на номера CVE в changelog-а на пакета.

Типични клопки при проверката

Проверен е само един пакет: PHP се състои от много двоични пакети. Ако php8.3-cli е актуален, а php8.3-fpm не е, уебсайтът остава отворен. Проверете всички пакети на един клон, особено FPM, CGI и модула за Apache.

Пакетът е задържан: Пакети, фиксирани с apt-mark hold, остават при актуализацията на място. apt-mark showhold ги показва.

Ubuntu Pro не е активен: При 20.04 и по-стари поправките идват само ако Ubuntu Pro е настроен. Без Pro системата остава уязвима въпреки изпълнената актуализация.

Остарял огледален сървър: Ако сървърът взема пакети през вътрешно огледало или прокси, той вижда новите актуализации за сигурност едва когато то бъде актуализирано. При съмнение проверете дали apt update наистина достига източника за сигурност.

Забравен рестарт: Новите пакети действат едва след рестарта на всички услуги, които са заредили PHP. needrestart, ако е инсталиран, показва услуги със стар код.

Важно

Коригираното състояние на пакета доказва само, че уязвимостта е затворена оттук нататък. Дали сървърът е бил атакуван преди това, то не отговаря. Запазете логовете от 20 октомври.

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

  • Установяваме за всеки сървър произхода на всички PHP пакети и сравняваме състоянието с официалните съобщения.
  • Инсталираме актуализации, също и чрез Ubuntu Pro, и рестартираме всички засегнати услуги.
  • С услугата за пач на PHP получавате за всеки сървър доказателство със състояние на пакета, попадение в changelog-а и време на рестарта.
  • На системи с външни източници или стари версии изясняваме кой път води до доказуемо коригирано състояние.

Често задавани въпроси

Коя версия на Ubuntu съдържа поправката за PHP2Shell?

Според USN-8948-1 Ubuntu 22.04, 24.04, 26.04 и 26.10 са снабдени с редовни актуализации. За 14.04, 16.04, 18.04 и 20.04 Ubuntu доставя поправките според USN-8948-2 чрез Ubuntu Pro.

Защо Ubuntu 24.04 продължава да показва PHP 8.3.6?

Ubuntu вгражда поправките за сигурност като backport в съществуващата версия. Номерът на upstream остава 8.3.6, променя се само състоянието на пакета. Според USN-8948-1 коригираното състояние е 8.3.6-0ubuntu0.24.04.13.

Поддържа ли се още Debian 12 bookworm?

Да. Според Debian Security Tracker за php8.2 в bookworm има коригирано състояние 8.2.35-1~deb12u1, обявено като DLA-4848-1 в рамките на Debian LTS.

Важи ли това и за PHP от хранилището sury?

Не. Пакетите от източници на трети страни като sury.org имат собствени състояния на версиите и собствени changelog-ове. Данните на Debian и Ubuntu важат само за техните официални пакети.

Стига ли apt upgrade?

Той инсталира новите пакети, но работещите процеси на PHP-FPM или Apache запазват стария код в паметта. Едва рестартът на всички услуги, които зареждат PHP, прави пача действащ.

Източници

Незабавен контакт

Всеки час има значение. Пишете ни сега.

Опишете накратко системата, версията на PHP и какво сте забелязали. Ние се свързваме с Вас, уточняваме ситуацията и работим отдалечено, докато инцидентът бъде приключен и документиран.

Незабавна помощ