21 октомври 2026 г. | PHP | ИТ сигурност
На 21 октомври 2026 г. екипът по сигурността на PHP публикува актуализации за всички версии на PHP, които все още се поддържат. Те отстраняват две критични уязвимости, станали известни като PHP2Shell. BSI публикува предупреждение и настоява засегнатите системи незабавно да бъдат актуализирани с корекциите. Ако поддържате уеб сървър с PHP, трябва да предприемете действия още днес. Това важи и за всички, които използват „само“ WordPress, Nextcloud или Joomla, защото тези приложения работят с PHP.
Тази статия обобщава какво се е случило, кои версии на PHP са засегнати, коя версия ви е необходима сега и как за няколко минути да проверите дали сървърът ви е защитен.
Съдържание на статията
- Какво се случи? Хронология на събитията
- Преглед на двете уязвимости в PHP
- Кой е засегнат?
- Тези версии на PHP са защитени
- Как да проверите и актуализирате сървъра си
- PHP 8.1 и по-стари версии: няма официална актуализация
- Временни мерки и въпросът „Да изключим ли сървъра от мрежата?“
- Често задавани въпроси
- Съдействие от Biricon IT Services
Какво се случи? Хронология на събитията
Екипът по сигурността на PHP обяви предварително предстоящите корекции, за да даде време на хостинг доставчиците и администраторите да се подготвят. Самите корекции бяха публикувани на 21 октомври 2026 г. Още същия ден BSI публикува своето предупреждение (версия 1.1).
- 20 октомври 2026 г.: Екипът по сигурността на PHP предупреждава предварително, че на следващия ден ще бъдат публикувани актуализации на сигурността.
- 21 октомври 2026 г., 14:00 UTC (16:00 ч. централноевропейско лятно време): Публикувани са корекциите за PHP 8.5, 8.4, 8.3 и 8.2.
- 21 октомври 2026 г.: BSI предупреждава за „критичните уязвимости, които застрашават уеб приложенията по целия свят“, и препоръчва незабавно прилагане на корекциите. По данни на BSI някои големи хостинг доставчици превантивно са изключили част от сървърите си от мрежата.
Преглед на двете уязвимости в PHP
Става дума за два отделни дефекта в ядрото на PHP: CVE-2026-109618 и CVE-2026-109619. Според екипа по сигурността на PHP и двата могат да позволят на атакуващ да изпълнява програмен код на сървъра, без да се удостоверява (отдалечено изпълнение на код без удостоверяване). Уязвимостите са оценени с CVSS v4.0: 9,2 (критични).
| Характеристика | Значение |
|---|---|
| Идентификатори | CVE-2026-109618 и CVE-2026-109619 |
| Оценка | CVSS v4.0: 9,2 — критична |
| Последствия | Изпълнение на код на сървъра (Remote Code Execution) без удостоверяване |
| Причина 1 | Нарушаване на целостта на паметта, когато PHP остане без оперативна памет по време на обработката (Out-of-Memory) |
| Причина 2 | Неактуално глобално състояние, което остава в паметта между заявките |
| Особено застрашени | Apache с mod_php |
Според оценката на BSI към момента на публикуването няма потвърдени атаки, но има непотвърдени сведения за опити за експлоатиране на уязвимостите. Опитът показва, че при критични уязвимости в толкова широко разпространен софтуер може да се очаква атакуващите да анализират корекциите и да подготвят автоматизирани атаки. Затова времето за прилагане на корекциите е ограничено.
Кой е засегнат?
По принцип е засегнат всеки сървър, на който работи PHP, независимо от начина на интеграция: PHP-FPM, mod_php в Apache, php-cgi, FrankenPHP или LiteSpeed. Според екипа по сигурността на PHP рискът е най-висок при Apache с mod_php.
BSI изрично посочва приложения, базирани на PHP, които поради това също могат да бъдат засегнати:
- Системи за управление на съдържание: WordPress, Drupal, TYPO3, Joomla
- Платформи за онлайн магазини: Magento
- Облачни услуги и съхранение на файлове: Nextcloud
- Интерфейси на защитни стени: pfSense, OPNsense
За целта не е необходимо в самото приложение да има дефект. Уязвимостта е в PHP, затова само актуализиране на WordPress, Nextcloud & други подобни приложения не е достатъчно. Трябва да се актуализира версията на PHP на сървъра. При защитни стени като pfSense и OPNsense коригираната версия на PHP се получава чрез съответната актуализация на фърмуера от производителя.
Тези версии на PHP са защитени
Уязвимостите са отстранени в следните версии. Всички по-стари версии се считат за уязвими.
| Клон на 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 | Поддръжката приключва на 31 декември 2026 г. |
| PHP 8.1 и по-стари версии | няма официална актуализация, вижте по-долу | |
Как да проверите и актуализирате сървъра си
1. Установете инсталираната версия на PHP
В командния ред на сървъра php -v показва версията на PHP за командния ред. Уеб сървърът може да използва друга версия на PHP. Затова проверете и версията на PHP-FPM или на модула на Apache, например с php-fpm8.3 -v или чрез страница, която извежда резултата от phpinfo() (след това незабавно я премахнете).
2. Инсталирайте актуализацията чрез пакетния мениджър
При Debian, Ubuntu, RHEL и сродните дистрибуции коригираната версия се получава чрез стандартния пакетен мениджър, например с apt update && apt upgrade или dnf upgrade. При външни източници като Sury-PPA или хранилището Remi новите пакети обикновено се появяват скоро след публикуването.
apt changelog php8.3-fpm или rpm -q --changelog php | grep CVE-2026-1096).
3. Рестартирайте услугата PHP
Самото актуализиране на пакета не е достатъчно: работещите PHP процеси запазват стария код в паметта. Рестартирайте PHP-FPM (systemctl restart php8.3-fpm) или Apache (systemctl restart apache2) и след това проверете дали процесите са стартирани след актуализацията.
4. Уебсайтове на хостинг
При споделен хостинг актуализацията обикновено се извършва от доставчика. В клиентския панел най-често можете да зададете версията на PHP за всеки уебсайт. Изберете една от посочените по-горе защитени версии или попитайте доставчика дали корекциите са приложени. По данни на BSI отделни доставчици превантивно са изключили сървъри от мрежата. Ако сайтът ви е недостъпен за кратко, това може да е причината.
PHP 8.1 и по-стари версии: няма официална актуализация
За PHP 8.1 и по-стари версии вече няма официални актуализации на сигурността. Администраторите на такива системи имат две възможности:
- Преминаване към поддържана версия (препоръчително). Колкото по-стара е версията, толкова повече промени са необходими в приложението и разширенията, затова преминаването трябва да се тества предварително.
- Пренасяне на корекциите към по-старата версия. Екипът по сигурността на PHP е предоставил корекциите в развойни клонове в GitHub. Ако компилирате PHP сами, можете да пренесете тези промени към по-стари версии. Това е временно решение и изисква специализирани познания.
Поддръжката на PHP 8.2 също продължава само до 31 декември 2026 г. Затова планирайте преминаването към PHP 8.4 или 8.5 още сега и не го отлагайте за края на годината.
Временни мерки и въпросът „Да изключим ли сървъра от мрежата?“
Заедно със съобщението екипът по сигурността на PHP описа и временни защитни мерки. Те намаляват риска, но не отстраняват напълно уязвимостите. Не заменят актуализацията и са предназначени само за периода до нейното прилагане.
Дали сървърът трябва да бъде изключен от мрежата до актуализирането му, зависи от неговата важност и достъпност. BSI посочва, че големи доставчици са предприели тази стъпка. Като общо правило:
- Публично достъпен сървър, който може да се актуализира веднага: приложете корекциите незабавно; не е необходимо изключване.
- Публично достъпен сървър, който не може да се актуализира скоро: ограничете достъпа (например чрез защитна стена само за известни адреси) или временно спрете услугата, особено при
mod_php. - Сървър, достъпен само от вътрешната мрежа: приложете корекциите в кратък срок; спешността е по-ниска.
Често задавани въпроси
Трябва ли да актуализирам WordPress, Joomla или Nextcloud?
Не и заради тази уязвимост. Тя е в PHP, а не в приложението. Актуализирайте версията на PHP на сървъра. Независимо от това актуализирането на самото приложение също е добра практика.
Как да разбера дали някой вече е използвал уязвимостта?
Трудно е да се даде категоричен отговор. Подозрителни признаци са непознати PHP файлове в уеб директорията, необичайни процеси, изпълнявани от потребителя на уеб сървъра, нови потребителски акаунти или cron задачи и необичаен изходящ трафик. При конкретно подозрение системата трябва да бъде подложена на криминалистичен анализ, а при съмнение — преинсталирана.
Достатъчна ли е защитна стена за уеб приложения?
Защитната стена може да блокира познати модели на атаки, но не замества актуализацията. Повече за съвместната работа на няколко слоя защита ще намерите в нашата статия Защита на Odoo 19: защитна стена, 2FA & Web RBL. Принципите важат за всяко уеб приложение.
Засегнат ли е Odoo?
Не. Odoo е написан на Python и не работи с PHP. Засегнати биха били само PHP приложенията, които работят на същия сървър.
Къде да намеря официалната информация?
Съобщението на екипа по сигурността на PHP ще намерите в архива с новини на php.net (публикация от 20 октомври 2026 г.), а версиите — на php.net/downloads. Предупреждението на BSI е с номер 2026-297981-1032 и може да бъде намерено на bsi.bund.de .
Съдействие от Biricon IT Services
Ако не сте сигурни коя версия на PHP работи на сървъра ви или имате нужда от помощ с прилагането на корекциите, с удоволствие ще ви съдействаме: при описването на всички PHP системи, инсталирането на актуализациите, преминаването към поддържана версия на PHP и проверката за компрометиране. Като доставчик на ИТ услуги поддържаме сървъри, защитни стени и уеб приложения за малки и средни предприятия.
Актуално към: 21 октомври 2026 г. Ситуацията може да се промени бързо; водещи са публикациите на екипа по сигурността на PHP и на BSI.