PHP2Shell атаковали за четыре дня до патча: вывод для защиты

Про уязвимости PHP2Shell (CVE-2026-109618 и CVE-2026-109619) мы уже писали: это критические ошибки PHP с риском удалённого выполнения кода, исправленные 21 октября. Теперь появилась важная деталь: по данным Amazon, атаки начались ещё 17 октября — за четыре дня до выхода исправлений. Это меняет не сами действия (обновиться нужно было в любом случае), а подход к тому, как мы относимся к срокам.

Что сообщил Amazon

Разведка угроз Amazon зафиксировала первые попытки эксплуатации 17 октября, за четыре дня до публикации исправлений. Разные нагрузки указывают на несколько групп. Amazon сообщает, что уязвимости «теперь широко эксплуатируются», хотя успешность атак неясна.

Детали, включая номера CVE и рекомендации, утекли до официального раскрытия, из-за чего команда PHP перенесла выпуск на 20 октября. CISA 21 октября призвала обновляться немедленно.

По данным VirusTotal, в интернете более 5 млн доступных хостов с PHP — масштаб потенциальной поверхности атаки огромен.

Что это меняет

Главный вывод сформулировал сам Amazon: нельзя считать дату публичного раскрытия самой ранней датой начала атак. То есть защита, построенная по принципу «выйдет исправление — тогда и обновлюсь», опаздывает уже на старте, если атаки начались раньше.

Это не значит, что обновляться бесполезно. Наоборот: раз окно сжимается, обновлять нужно быстрее, а между выходом исправления и установкой не должно быть недель.

Что делать

1. Если ещё не обновили PHP — сделайте это сейчас. Подробности и проверка — в наших материалах про PHP2Shell.
2. Проверьте версию PHP: `php -v`. Нужны 8.5.12, 8.4.27, 8.3.36, 8.2.35 или новее.
3. На виртуальном хостинге обновление PHP делает провайдер — уточните в поддержке.
4. Поскольку атаки шли с 17 октября, проверьте журналы сервера за этот период на необычную активность.
5. Если сервер работал в уязвимой версии и доступен из интернета, оцените вероятность компрометации и при сомнениях проведите аудит.

Наше мнение

Эта история закрепляет тенденцию всего октября: окно между уязвимостью и атакой сжимается. У Atlassian атаки начались через часы после публикации примера, у PHP2Shell — за дни до выхода патча. Причин несколько: утечки деталей до раскрытия, ускорение поиска и эксплуатации уязвимостей за счёт ИИ, готовые инструменты.

Практический вывод для бизнеса один: скорость реакции стала важнее, чем раньше. Мы советуем для критичных компонентов — PHP, веб-сервер, CMS — иметь короткий путь обновления: кто отвечает, как быстро ставятся исправления, есть ли резервная копия перед обновлением. А ещё важнее — не быть лёгкой целью: закрыть лишнее от интернета, держать защиту на уровне сервера, следить за журналами. Тогда даже атака до патча с большей вероятностью не достигнет цели.

Почему проверка журналов важна

Когда атаки начинаются раньше раскрытия, обновление закрывает дверь, но не отвечает на вопрос, не вошёл ли кто-то до этого. Поэтому после таких историй важно смотреть журналы за период до официального раскрытия. Признаки — необычные запросы, незнакомые файлы на сервере, исходящие соединения с неизвестными адресами, новые пользователи. Если сервер работал в уязвимой версии и был доступен из интернета в опасный период, проверка — не перестраховка, а необходимость.

Что делать, если обновиться прямо сейчас сложно

Идеальный вариант — обновиться немедленно. Но если по какой-то причине это откладывается (например, на сервере критичное приложение и нужно короткое окно обслуживания), снизьте риск временными мерами: ограничьте доступ к сайту, усильте защиту на уровне сервера и веб-приложения, внимательно следите за журналами. Это не замена обновлению, а способ сократить окно уязвимости. И всё равно запланируйте обновление на ближайшее возможное время: при широкой эксплуатации каждый день промедления повышает шанс стать целью.

Почему эта история про всех, а не только про PHP

Хотя речь о конкретной уязвимости PHP, вывод шире. Любой популярный компонент — веб-сервер, CMS, фреймворк, база данных — рано или поздно получает критическую уязвимость, и всё чаще её начинают использовать до или сразу после раскрытия. Значит, скорость обновления становится отдельным показателем защищённости, таким же важным, как наличие резервных копий или многофакторной аутентификации. Компании, у которых обновление критичного компонента занимает недели согласований, оказываются в зоне риска просто из-за медлительности. Выстроить короткий и понятный путь обновления — такая же мера безопасности, как и всё остальное.