Накратко: Хронологията на PHP2Shell обхваща засега четири доказани дати: първи наблюдаван опит за атака на 17.10., предварително обявяване от php.net на 20.10., пачовете на 21.10. в 16 ч. по немско време и ново съобщение за CVE-2026-115560 на 23.10.2026. За операторите от това следва: пачнете, рестартирайте всички PHP процеси и запазете логовете най-късно от 20.10.
Защо хронологията на PHP2Shell е важна за операторите
При уязвимост с такава тежест значение има не само дали сървърът Ви е пачнат днес. Решаващо е и колко дълго преди това е бил уязвим. Този времеви прозорец определя кои логове да запазите, кои файлове да проверите и дали с основание можете да изключите компрометиране.
PHP2Shell засяга самия PHP, а не отделна CMS. Две критични уязвимости, CVE-2026-109618 и CVE-2026-109619, позволяват отдалечено изпълнение на злонамерен код без вход в системата. И двете са оценени с CVSS v4.0 9,2. Разбираемо въведение ще намерите на страницата Какво е PHP2Shell?.
Следващата хронология съдържа само дати, които са доказани към 25.10.2026. Където данните се основават на медийни съобщения, това е отбелязано.
| Дата | Събитие | Основание |
|---|---|---|
| 17.10.2026 | Първи наблюдаван опит за атака (Amazon) | Медийни съобщения |
| 20.10.2026 | Предварително обявяване от php.net | php.net |
| 21.10.2026, 14:00 UTC | Публикуване на пачовете (16 ч. по немско време) | php.net |
| 23.10.2026 | Съобщение за CVE-2026-115560 | php.net |
| 25.10.2026 | Състояние на този преглед | – |
17 октомври: първият наблюдаван опит за атака
Според медийни съобщения на 17.10.2026 е наблюдаван първи опит за атака, докладван от Amazon. Това е четири дни преди пачовете. Значи е имало период, в който вече са правени опити за атаки, но все още не е съществувала актуализация.
Дали и колко атаки в тази фаза са били успешни, не е доказано. Важно е следствието за Вашата собствена проверка: сървър, който днес е пачнат, може да е бил компрометиран преди това. Пачът не премахва вече внедрен зловреден софтуер и не доказва, че преди това нищо не се е случило.
20 и 21 октомври: предварително обявяване и пачове
На 20.10.2026 проектът PHP обяви актуализациите за сигурност на php.net. На 21.10.2026 в 14:00 UTC, т.е. в 16 ч. по немско време, последваха поправените версии.
| Клон | Последна уязвима версия | Поправено във |
|---|---|---|
| PHP 8.5 | 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.34 | 8.2.35 |
За PHP 8.1 и по-стари вече няма официални актуализации, а само минимални backport корекции на изходния код за 7.4, 8.0 и 8.1. Според специализираната преса са засегнати почти всички версии чак до PHP 5.4. Засегнати са режимите на работа PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Най-висок риск екипът на PHP вижда при mod_php, където е показан експлойт още преди да започне да се изпълнява какъвто и да е код на приложението.
Дистрибуциите и хостинг доставчиците понякога внасят backport корекции. Тогава например Plesk продължава да показва 8.2.34, въпреки че сървърът е пачнат. Меродавни са състоянието на пакета и потвърждението от доставчика, а не показаният номер на версията. Как да го проверите коректно, е описано на страницата Как да проверите правилно версията на PHP и състоянието на пача.
23 октомври: съобщение за CVE-2026-115560
На 23.10.2026 проектът PHP публикува ново съобщение, този път за CVE-2026-115560. Според него експлоатация е възможна само при необичайна конфигурация: в конфигурацията е зададен serialize_handler php_binary или php_serialize, приложението го превключва на php преди session_start() чрез ini_set() и upload progress на сесиите е активен.
Мярката е проста и трябва да се зададе независимо от това дали познавате такава комбинация при себе си:
; в php.ini, във FPM пула или в конфигурацията на сървъра
; не чрез ini_set() или .user.ini
session.upload_progress.enabled = 0
След това рестартирайте всички PHP worker процеси. Пълното съобщение трябва да последва със следващата редовна версия с поправки. Дотогава настройката остава препоръчваното преходно решение.
Състояние към 25 октомври: ситуация и открити въпроси
BSI (Федералната служба за информационна сигурност на Германия) обяви ниво на предупреждение 3 / оранжево. Тя препоръчва незабавна актуализация и, ако това не е възможно веднага, уеб сървърите да се изключат временно от мрежата. BSI очакваше бърза мащабна експлоатация; потвърдени успешни атаки в широк мащаб според BSI първоначално не били известни. Оценката на BSI е обобщена на страницата Какво препоръчва BSI за PHP2Shell.
Cloudflare съобщи за наблюдавани опити за атака и внедри защитни правила, но предупреждава, че правила, базирани само на данните от заявките, не са достатъчни. Palo Alto Networks (Unit 42) преброи над 22,6 милиона изложени на риск, потенциално уязвими инстанции. Потвърдени Indicators of Compromise не са публикувани; разпознаването се основава на анализ на поведението.
Някои доставчици са изключили уебсайтове превантивно. Това не означава автоматично, че тези сайтове са били хакнати. Към състоянието на този преглед открит остава преди всичко въпросът колко сървъри действително са били компрометирани във времето преди пача.
Какво означава хронологията за Вашите логове и проверки
От датите се получават три периода: преди 17.10., между 17.10. и момента на Вашия собствен пач и рестарт, както и след това. Средният период е критичният. Колкото по-дълго е продължил при Вас, толкова по-задълбочена трябва да е проверката.
Специализираната преса съветва логовете на сървъра да се пазят от 20.10.2026. Запазете и наличните по-стари логове, преди автоматичната ротация да ги изтрие.
Прост начин да запазите логовете непроменени и да фиксирате състоянието:
# Логовете се запазват в един архив (пътищата да се адаптират към Вашата система)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Контролна сума за по-късно доказване
sha256sum /root/logs-sicherung-*.tar.gz
# Колко дълго системата пази логовете?
grep -R "rotate" /etc/logrotate.d/
Отбележете и кога точно е внесена актуализацията и кога са рестартирани PHP процесите. Новите файлове сами по себе си не защитават, докато стари процеси продължават да работят в паметта. Как да анализирате запазените логове, описва наръчникът Анализ на логовете на уеб сървъра след атака.
Как конкретно помага PHP SOS?
- Заедно с Вас определяме действителния прозорец на уязвимост на Вашия сървър: състояние на пакета, момент на пача, рестарт на всички worker процеси.
- Запазваме логовете и състоянието на системата по проследим начин, преди нещо да бъде променено.
- Проверяваме за поведенчески аномалии като нови PHP файлове, чужди процеси и необичайни изходящи връзки.
- Документираме резултата така, че ръководството, длъжностните лица по защита на данните и застрахователите да могат да работят с него.
Хода стъпка по стъпка описва нашата спешна помощ при PHP2Shell.
Често задавани въпроси
Кога бяха публикувани пачовете за PHP2Shell?
Проектът PHP публикува поправените версии на 21.10.2026 в 14:00 UTC, т.е. в 16 ч. по немско време. Поправени са PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35.
От коя дата да съхранявам логовете на сървъра?
Специализираната преса съветва логовете да се пазят от 20.10.2026. Тъй като според медийни съобщения още на 17.10. е наблюдаван първи опит за атака, си струва да запазите и наличните по-стари логове, преди ротацията да ги изтрие.
CVE-2026-115560 също ли е толкова опасна, колкото първите две уязвимости?
Според съобщението от 23.10.2026 експлоатация е възможна само при необичайна конфигурация на сесиите. Като мярка за намаляване на риска се препоръчва session.upload_progress.enabled=0, докато излезе следващата редовна версия с поправки.
Има ли потвърдени Indicators of Compromise за PHP2Shell?
Не, към 25.10.2026 не са публикувани потвърдени Indicators of Compromise. Разпознаването се опира на анализ на поведението, например необичайни процеси, нови файлове и подозрителни връзки.