Критична PHP уязвимост: обновихме всички PHP клонове в същия ден

CVE-2026-109618 и CVE-2026-109619 — какво се случи, какво направихме и как да проверите сами

Публикувано 21 октомври 2026 | Сигурност | Хостинг

Автор: екипът на Ай Ти България ЕООД

Накратко

На 21 октомври 2026 екипът на PHP обяви CVE-2026-109618 и CVE-2026-109619 — две критични уязвимости с оценка CVSS v4.0 9.2, които позволяват изпълнение на чужд код върху сървъра без автентикация. Поправени са в PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 и PHP 8.2.35. Официалната позиция на PHP е еднозначна: няма пълна смекчаваща мярка, обновяването е единственият безопасен избор. Обновихме всички инсталирани PHP клонове на нашите сървъри вечерта на 21 октомври 2026 г., в деня на обявяването.

  • Обновени са всички инсталирани PHP клонове, не само актуалните
  • Поправките са приложени в рамките на часове след обявяването
  • Нито един сайт при нас не работи през mod_php — конфигурацията с най-висок риск
  • Направен е пълен рестарт на всички PHP-FPM услуги, не само презареждане
  • Проверени са работещата версия на всеки сайт, командата php и cron задачите
  • Нито един клиентски сайт не беше засегнат и не се наложи възстановяване
  • От клиентите ни не се изисква никакво действие

Засегнати и поправени версии

И двете уязвимости засягат едни и същи версии и са поправени в едни и същи издания. Таблицата показва и какво точно се промени на нашите сървъри на 21 октомври 2026 г.

Клон на PHP Засегнати версии Поправена версия При нас на 21.10.2026
PHP 8.5 под 8.5.12 8.5.12 8.5.11 8.5.12
PHP 8.4 под 8.4.27 8.4.27 8.4.26 8.4.27
PHP 8.3 под 8.3.36 8.3.36 8.3.35 8.3.36
PHP 8.2 под 8.2.35 8.2.35 8.2.34 8.2.35
PHP 8.1 и по-стари засегнати без официална поправка приложени неофициални backport поправки

CVE-2026-109618

Изпълнение на код при изчерпване на паметта

Оценка: CVSS v4.0 9.2 — критична

Advisory: GHSA-w8hw-w9fx-j79w

CVE-2026-109619

Изпълнение на код чрез остаряло вътрешно състояние

Оценка: CVSS v4.0 9.2 — критична

Advisory: GHSA-6wmf-4rv5-p3rp

Какво точно се случи

Проблемът не е в тема, разширение или конкретна платформа. Той е в самия PHP — езика, на който работят огромна част от сайтовете в света. Това е разликата между поправка, която засяга едно приложение, и поправка, която засяга целия сървър.

CVE-2026-109618 — изпълнение на код при изчерпване на паметта. Когато PHP достигне тавана на разрешената памет, обработката може да бъде прекъсната в момент, в който вътрешните данни за заявката са само частично подготвени. Следващото почистване на тези данни може да ги приеме за валидни и да работи с невалидно съдържание.

CVE-2026-109619 — изпълнение на код чрез остаряло вътрешно състояние. Вътрешно състояние, принадлежащо на една заявка, може да остане след като паметта зад него вече е освободена. Следваща заявка, обслужена от същия работен процес, може да го използва, преди нормалното начално зареждане да го изчисти.

Общото между двете: нападателят не се нуждае от профил в сайта ви. Достатъчна е заявка отвън.

Оценка по CVSS v4.0

9.2

Критична — еднаква оценка за двете уязвимости.

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Срок за PHP 8.2

PHP 8.2 излиза от поддръжка на 31 декември 2026 и след тази дата няма да получава поправки по сигурността. Ако сайтът ви е на 8.2, планирайте преминаването сега, а не при следващата критична новина.

Защо този случай не е обичайна поправка

Без автентикация

Нападателят не влиза в сайта. Не му трябва профил, парола или покана. Достатъчна е подходяща заявка отвън.

Преди вашия код

PHP описва демонстриран случай при mod_php, в който атаката сработва, преди кодът на приложението да започне да се изпълнява.

Без заобиколен път

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

Изключителни поправки

Заради сериозността са подготвени минимални поправки дори за клонове извън поддръжка — рядка стъпка за проекта.

Какво направихме на 21 октомври 2026 г.

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

Пакетите излязоха на 21 октомври. Поправките бяха приложени в рамките на часове след обявяването, а обновяването приключи вечерта на същия ден. Обновени са всички инсталирани PHP клонове — не само актуалните — а за по-старите клонове, които все още присъстват в средата, приложихме наличните неофициални backport поправки.

Пълен рестарт, не презареждане. Обновяването на пакета по подразбиране само презарежда PHP-FPM, при което работещи процеси могат да продължат да държат в паметта си стари или вече изтрити библиотеки — тоест кода преди поправката. Затова направихме ръчен пълен рестарт на всяка инсталирана версия и проверихме, че нито един работещ процес не държи стари или изтрити PHP библиотеки.

Накрая проверихме коя версия обслужва всеки сайт и че командата php и cron задачите също работят с поправената версия — лесно пропускана подробност, защото командният ред и обслужващата услуга могат да ползват различни версии.

Последователността

  • Проследяване на предварителното обявление
  • Обновяване на всички клонове след излизането на пакетите
  • Пълен рестарт на всяка PHP-FPM услуга
  • Проверка, че никой процес не държи стари библиотеки
  • Проверка на версията за всеки сайт
  • Проверка на php и cron задачите

Нула mod_php

Нито един сайт при нас не се обслужва през mod_php. Всички работят през PHP-FPM. Според официалното съобщение mod_php е конфигурацията с най-висок риск при този случай.

Как да проверите сами

Ако управлявате собствен сървър, проверката отнема минути. Важна е подверсията, а не само серията: PHP 8.4 без поправката и PHP 8.4.27 са две различни състояния на един и същ сървър.

1. Коя версия на PHP работи

Проверете поотделно командния ред и обслужващата услуга — те могат да са различни версии. Сменете номера с вашия:

php -v php-fpm8.4 -v

Сравнете резултата с 8.5.12, 8.4.27, 8.3.36 и 8.2.35. По-ниска подверсия в същата серия означава, че поправката още не е приложена.

2. Рестартиран ли е PHP-FPM след обновяването

Проверете кога услугата е влязла в текущото си състояние:

systemctl show php8.4-fpm -p ActiveEnterTimestamp

Показаното време трябва да е след момента на обновяването на пакетите. По-ранно време означава, че услугата върви от преди поправката и обновяването не е завършено.

3. Капанът, който често се пропуска

Обновяването на пакета по подразбиране само презарежда PHP-FPM. Презареждането не е равносилно на пълен рестарт — работещи процеси могат да продължат да държат в паметта си стари или вече изтрити библиотеки. Ако сте обновили, но не сте рестартирали напълно, поправката може да не е в сила.

Внимавайте и с проверката: грубото търсене на (deleted) в /proc/*/maps дава фалшиви тревоги, защото показва и записи от вида /dev/zero (deleted), които се дължат на OPcache и са напълно нормални. Проверявайте само за изтрити .so библиотеки и за самия php-fpm файл.

Ако не можете да обновите веднага

PHP посочва следните мерки като частични:

session.upload_progress.enabled=0 memory_limit=-1

Те намаляват излагането към конкретни пътеки на атака, но сами по себе си не правят инсталацията безопасна. След промяната всички работни процеси трябва да бъдат рестартирани.

Какво не помага срещу този проблем

Силна парола за администратор

Двуфакторна автентикация

Обновена платформа или разширения

Скриване на съобщенията за грешки

Всички тези мерки са нужни за други рискове. Срещу този не са достатъчни, защото проблемът е под нивото на приложението.

Ако сайтът ви е на споделен хостинг

Когато нямате достъп до сървъра, проверката минава през доставчика. При споделен хостинг без управление обновяването на PHP често е задача на клиента — или чака, докато доставчикът смени версията по общ график. В дните, в които излиза критична поправка, този график е твърде бавен.

При нас обновяването по сигурността е част от услугата и не изисква заявка, тикет или присъствие на клиента. Работим с версии, които получават поправки, следим обявленията на PHP и прилагаме критичните обновления веднага.

Резултатът при този случай е измерим: нула засегнати клиенти и нула необходими действия от тяхна страна.

Поискайте оценка за прехвърляне Виж уеб хостинг

Трите въпроса към доставчика

  • Коя точна подверсия на PHP обслужва сайта ми в момента?
  • Кога беше приложена поправката от 21 октомври 2026?
  • Беше ли направен пълен рестарт на PHP-FPM, а не само презареждане?

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

Засегнат ли е сайтът ми, ако е на хостинга на Ай Ти България?

Не. Обновихме всички инсталирани PHP клонове вечерта на 21 октомври 2026 — деня на обявяването — до PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 и PHP 8.2.35, и рестартирахме напълно всички PHP-FPM услуги. Не е необходимо действие от ваша страна.

Кои точно са уязвимостите и колко са сериозни?

CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) и CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp). И двете позволяват дистанционно изпълнение на код без автентикация и са оценени с CVSS v4.0 9.2, тоест критични. Поправени са в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35.

Използвате ли mod_php, която PHP определя като най-рисковата конфигурация?

Не. Нито един сайт при нас не работи през mod_php — всички се обслужват през PHP-FPM. Според официалното съобщение рискът е най-висок именно при mod_php, където е демонстриран случай на задействане от заявка без автентикация, преди кодът на приложението да започне да се изпълнява.

Защо презареждането на PHP-FPM не е достатъчно и е нужен пълен рестарт?

Обновяването на пакета по подразбиране само презарежда PHP-FPM. При презареждане е възможно работещи процеси да продължат да държат в паметта си стари или вече изтрити PHP библиотеки, тоест кода преди поправката. Затова направихме ръчен пълен рестарт на всяка инсталирана версия и проверихме, че нито един процес не държи стари библиотеки.

Как да проверя дали PHP-FPM наистина е бил рестартиран след обновяването?

С командата systemctl show php8.4-fpm -p ActiveEnterTimestamp, сменена с вашата версия. Показаното време трябва да е след момента на обновяването на пакетите. По-ранно време означава, че услугата върви от преди поправката.

Защо проверката за изтрити файлове в /proc дава фалшиви тревоги?

Грубото търсене на (deleted) в /proc/*/maps показва и записи от вида /dev/zero (deleted), които се дължат на OPcache и са нормални. Проверявайте само за изтрити .so библиотеки и за самия php-fpm файл — останалите съвпадения са шум и водят до погрешен извод.

Засягат ли уязвимостите само определени системи за управление на съдържание?

Не. Проблемът е в самия PHP, а не в приложение, тема или разширение. Засегнати са всички инсталации, обслужващи заявки към уеб — независимо дали отзад стои готова платформа или собствен код.

Помагат ли силната парола, двуфакторната автентикация или защитна стена за приложения?

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

Достатъчно ли е да променя настройки в php.ini, вместо да обновявам?

Не. PHP посочва session.upload_progress.enabled=0 и memory_limit=-1 като мерки, които намаляват излагането към конкретни пътеки на атака, но изрично уточнява, че сами по себе си не правят инсталацията безопасна. Пълно решение е само обновяването до поправена версия.

Какво да направя, ако сайтът ми работи на PHP 8.1 или по-стара версия?

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

Как да проверя коя версия на PHP работи сайтът ми?

С php -v за командния ред и php-fpm8.4 -v за обслужващата услуга, сменена с вашата версия. Важна е подверсията: PHP 8.4 без поправката и PHP 8.4.27 са две различни състояния. Сравнете числото с 8.5.12, 8.4.27, 8.3.36 или 8.2.35.

Какви въпроси да задам на своя доставчик на хостинг?

Три: коя точна подверсия на PHP обслужва сайта ми в момента, кога беше приложена поправката от 21 октомври 2026 и беше ли направен пълен рестарт на PHP-FPM, а не само презареждане. Ясният и бърз отговор на тези три въпроса е най-добрият показател за качеството на управлявания хостинг.

Мога ли да прехвърля сайта си при вас?

Да. Прехвърлянето включва пренос на файловете и базите данни, настройка на подходящата версия на PHP, издаване на сертификат и проверка на сайта преди смяната на адресацията. Свържете се с нас за оценка на конкретния случай.

Източници

Следваща стъпка

Ако не сте сигурни коя подверсия на PHP обслужва сайта ви, кога е била приложена последната поправка по сигурността или беше ли направен пълен рестарт след нея, ще проверим това заедно с вас и ще ви кажем какво показва проверката — без предварително условие да станете наш клиент.

Разгледайте и останалите ни направления: уеб хостинг, SaaS хостинг, хостинг платформа, контролен панел за клиенти и всички новини.

Свържете се с нас Всички новини