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 ч. MESZ): Публикувани са корекциите за PHP 8.5, 8.4, 8.3 и 8.2.
- 21 октомври 2026 г.: BSI предупреждава за „критични уязвимости, които застрашават уеб приложенията по света“, и препоръчва да се коригира незабавно. Според данни на BSI големи хостинг доставчици отчасти са изключили сървъри от мрежата превантивно.
Двете уязвимости в PHP накратко
Става дума за две отделни грешки в ядрото на PHP: CVE-2026-109618 и CVE-2026-109619. И двете могат според данните на екипа по сигурността на PHP да доведат до това нападател да може да изпълнява програмен код на сървъра, без да се удостоверява (unauthenticated Remote Code Execution). Уязвимостите са оценени с 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 е свързан: 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 & Co. не помага. Трябва да се актуализира версията на 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 и по-стари вече няма официални актуализации за сигурност. Операторите на такива системи имат две възможности:
- Преминаване към поддържана версия (препоръчително). Колкото по-стара е версията, толкова по-голяма е трудността при адаптиране на приложението и разширенията, затова преминаването трябва да се тества предварително.
- Пренасяне на корекциите назад (backport). Екипът по сигурността на PHP е предоставил корекциите в клонове за разработка в GitHub. Който компилира PHP сам, може да пренесе тези промени в по-стари версии. Това е временно решение и изисква специални знания.
И PHP 8.2 е поддържан само до 31 декември 2026 г. Планирайте затова преминаването към PHP 8.4 или 8.5 още сега и не го отлагайте за края на годината.
Временни мерки и въпросът „Да изключим ли сървъра от мрежата?“
Екипът по сигурността на PHP е описал с обявяването и временни защитни мерки. Те намаляват риска, но не затварят напълно пропуските. Те не заместват актуализацията и са предназначени само да запълнят времето до актуализацията.
Дали един сървър трябва да бъде изключен от мрежата до актуализацията, зависи от неговата важност и достъпността му. BSI посочва, че големи доставчици са предприели тази стъпка. Като практическо правило важи:
- Публично достъпен сървър, актуализация възможна сега: коригирайте незабавно, изключване не е необходимо.
- Публично достъпен сървър, актуализация невъзможна в кратък срок: ограничете достъпа (например чрез защитна стена само за известни адреси) или изключете услугата временно, особено при
mod_php. - Сървър, достъпен само вътрешно: коригирайте своевременно, спешността е по-малка.
Често задавани въпроси
Трябва ли да актуализирам WordPress, Joomla или Nextcloud?
Не заради тази уязвимост. Тя се намира в PHP, а не в приложението. Актуализирайте версията на PHP на сървъра. Независимо от това актуализирането на самото приложение също е препоръчително.
Как да разбера дали някой вече е експлоатирал уязвимостта?
Категоричен отговор е труден. Подозрителни са непознати PHP файлове в уеб директорията, необичайни процеси под потребителя на уеб сървъра, нови потребителски акаунти или cron задачи и необичаен изходящ трафик. При конкретно подозрение системата трябва да бъде подложена на форензичен анализ и при съмнение да бъде преинсталирана.
Достатъчна ли е защитна стена за уеб приложения (Web Application Firewall)?
Защитната стена може да засече известни модели на атаки, но не замества актуализацията. Повече за взаимодействието на няколко защитни слоя можете да прочетете в нашата статия Защита на 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.