Две критични уязвимости в PHP могат да позволят на отдалечен нападател да изпълнява злонамерен код на сървъра без автентикация. Проблемът засяга различни версии на PHP и изисква незабавна проверка и прилагане на съответните защитни актуализации.
На 21 октомври 2026 г. PHP публикува корекции за CVE-2026-109618 и CVE-2026-109619. И двете уязвимости са оценени с CVSS 9.2 от 10, което ги поставя в категорията на критичните рискове. CERT-EU и cPanel препоръчват незабавно обновяване на засегнатите системи.
Какво представляват двете уязвимости?
1. CVE-2026-109618 — Remote Code Execution чрез изчерпване на паметта
Тази уязвимост е свързана с обработката на грешки при изчерпване на паметта (Out of Memory, OOM).
PHP използва параметъра memory_limit, за да ограничава количеството памет, което един скрипт може да използва. При достигане на лимита изпълнението може да бъде прекратено принудително.
Проблемът възниква, когато прекратяването се случи в момент, в който вътрешни структури на PHP все още не са напълно инициализирани. Последващото освобождаване на паметта може да обработи невалидно състояние и да доведе до повреда на паметта.
При определени условия нападател може да използва тази слабост за отдалечено изпълнение на код (RCE — Remote Code Execution).
Рискът не се ограничава до конкретно уеб приложение. Уязвимостта е в самия PHP runtime и може да бъде задействана преди изпълнението на кода на приложението.
2. CVE-2026-109619 — Remote Code Execution чрез остаряло вътрешно състояние
Втората уязвимост е свързана с неправилното управление на вътрешно състояние между отделни заявки.
При определени грешки или прекратяване на изпълнението PHP може да запази препратка към вътрешни данни, чиято памет вече е освободена. Ако същият worker обработи следваща заявка, той може да използва това остаряло състояние, преди то да бъде правилно инициализирано.
Това създава възможност за повреда на паметта и потенциално отдалечено изпълнение на код.
Особено важно е, че при подобен сценарий не е задължително нападателят да има потребителски акаунт в сайта.
Кои версии на PHP са засегнати?
Според публикуваната информация уязвимостите засягат PHP инсталации, които обслужват уеб заявки, включително PHP-FPM, Apache с mod_php, php-cgi и LiteSpeed.
Корекциите за поддържаните версии са публикувани в следните издания:
| Версия на PHP | Коригирана версия |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
За някои по-стари версии, включително PHP 7.4, 8.0 и 8.1 в дистрибуцията EasyApache 4 на cPanel, са публикувани специфични backport корекции. Те не означават, че съответните версии отново са под стандартна поддръжка.
PHP 5 и други стари версии не трябва да се считат за защитени само защото използват последния наличен номер на своя клон. За PHP версии под 7.4 cPanel препоръчва решение за разширена поддръжка, като TuxCare Extended Lifecycle Support (ELS).
Как да проверим дали сайтът ни е засегнат?
Стъпка 1: Проверете действително използваната версия
Ако използвате cPanel:
- Влезте в административния панел.
- Отворете MultiPHP Manager.
- Намерете домейна си.
- Проверете избраната версия на PHP.
Имайте предвид, че версията, показана в MultiPHP Manager, невинаги е достатъчна за потвърждение на инсталираната корекция. Хостинг доставчикът трябва да потвърди и версията на реално използвания пакет.
При SSH достъп може да проверите версията на командния ред:
php -vТази команда показва CLI версията, която може да се различава от версията, използвана от сайта. Затова проверката трябва да обхване и PHP runtime, който обслужва HTTP заявките.
Стъпка 2: Проверете всички домейни и поддомейни
В един cPanel акаунт различните сайтове могат да използват различни версии на PHP. Проверете основния домейн, поддомейните, тестовите среди и всички приложения, които обслужват публични заявки.
Не забравяйте API крайните точки и отделните PHP приложения, които може да са разположени в различни директории.
Как да пачнем уязвимостите при cPanel и WHM?
Вариант 1: Имате WHM и root достъп
При стандартна инсталация с EasyApache 4 обновяването на пакетите се извършва от администратора на сървъра.
След проверка на наличните актуализации може да се използва:
/scripts/rpmupТова е командата, посочена от cPanel за обновяване на PHP пакетите в контекста на тези уязвимости.
След приключване на обновяването проверете:
- Дали са инсталирани коригираните версии на PHP пакетите.
- Дали всички използвани PHP клонове са обновени.
- Дали cPanel/WHM също е актуализиран.
- Дали PHP-FPM worker процесите използват коригираните пакети.
- Дали основните функции на сайтовете работят нормално.
Не приемайте, че само обновяването на cPanel интерфейса автоматично коригира всички отделни PHP версии на сайтовете.
Вариант 2: Имате само cPanel
При стандартен споделен хостинг потребителят обикновено няма права да обновява системните PHP пакети.
В този случай:
- Проверете версията в MultiPHP Manager.
- Свържете се с хостинг доставчика.
- Поискайте обновяване до коригирана версия или потвърждение за инсталиран backport.
- След обновяването проверете действително използваната версия.
Примерно съобщение до доставчика:
Здравейте,
Сайтът ми използва PHP през cPanel. Моля да потвърдите дали сървърът е защитен срещу CVE-2026-109618 и CVE-2026-109619.
Моля да проверите дали са инсталирани съответните коригирани PHP пакети и актуализациите на cPanel/WHM. Ако използваната PHP версия е извън стандартна поддръжка, моля да уточните дали има приложен backport или решение за разширена поддръжка.
Благодаря.
Временни мерки, ако не можете да обновите веднага
Временните мерки намаляват риска, но не заместват корекцията на PHP.
1. Изключете PHP upload progress
Може да зададете:
session.upload_progress.enabled = OffТова изключва конкретния механизъм на PHP за следене на напредъка при качване на файлове. Самото качване може да продължи да работи, ако приложението използва друг механизъм за прогрес.
Тази промяна ограничава определен път за експлоатация, но не премахва и двете уязвимости.
2. Ограничете размера на POST заявките
Параметърът post_max_size ограничава размера на данните, които PHP приема в POST заявка.
Например:
post_max_size = 8Mе възможна временна настройка за сайт, който не изисква големи качвания.
За приложения, които приемат файлове, може да е необходимо по-високо ограничение, например:
post_max_size = 32M
upload_max_filesize = 30MТова са примерни стойности, а не универсална препоръка. Настройките трябва да съответстват на реалните нужди на приложението и на ограниченията на уеб сървъра или обратния прокси.
Допълнително могат да се ограничат броят на multipart частите, броят на полетата, размерът на заглавните части и дълбочината на вложените структури, когато използваната инфраструктура го позволява.
3. Не премахвайте произволно лимита на PHP за паметта
Временното задаване на:
memory_limit = -1премахва ограничението на PHP за използваната памет. Това може да предотврати достигането на конкретния лимит, но същевременно увеличава риска от изчерпване на системните ресурси.
Ако се прилага като част от конкретна стратегия за смекчаване на CVE-2026-109618, трябва да бъде съчетано с независимо ограничение на ресурсите, например чрез cgroup или контейнер, и с подходяща политика за прекратяване на засегнатите worker процеси.
Не задавайте memory_limit = -1 самостоятелно в cPanel без оценка от администратора на сървъра. При споделен хостинг това може да засегне и други приложения.
4. Използвайте WAF като допълнителен слой
Web Application Firewall (WAF), например Cloudflare или защитната система на хостинг доставчика, може да блокира част от подозрителния трафик.
WAF обаче не коригира дефекта в PHP runtime. Не разчитайте на него като единствена защита.
5. Ограничете публичния достъп при висок риск
Ако корекцията не може да бъде приложена своевременно, помислете за временно ограничаване на публичния достъп до засегнатите приложения. Това е особено важно за административни интерфейси, тестови среди и приложения, които приемат произволни входни данни от интернет.
Какво още трябва да направим след пачването?
Обновяването е основната мярка, но при критични уязвимости трябва да се провери и дали системата вече не е била компрометирана.
След прилагане на корекцията:
- Прегледайте access и error логовете за необичайни заявки и грешки.
- Проверете за непознати PHP файлове и неочаквани промени в
.htaccess. - Прегледайте администраторските акаунти и задачите по график.
- Проверете целостта на файловете на приложението.
- При съмнение за пробив изолирайте системата, запазете логовете и направете анализ преди възстановяване от резервно копие.
- След потвърден или вероятен компромис сменете идентификационните данни и тайните от чиста среда.
CVE-2026-109618 и CVE-2026-109619 показват, че сигурността на един уебсайт зависи не само от неговия код, CMS или плъгини, но и от самия PHP runtime.
Най-важните действия са:
- Инвентаризация на всички PHP приложения и версии.
- Незабавно инсталиране на коригираните пакети.
- Проверка на cPanel/WHM и PHP runtime след обновяването.
- Временни ограничения на входните данни и ресурсите, когато пачването се забавя.
- Проверка за признаци на компрометиране.
При тези уязвимости временните настройки могат да намалят риска, но не са равностойни на официалната корекция. За сайтове, които са достъпни от интернет, обновяването трябва да бъде приоритет.