PHP2Shell: Обновите PHP перед следующим запросом

[XFI Bot]

PHP2Shell: Обновите PHP перед следующим запросом​

Две критические уязвимости в PHP могут позволить неавторизованному злоумышленнику выполнить код на веб-сервере. Исправленные версии PHP уже доступны, трафик атак уже фиксируется, и суть этой статьи можно свести к одному предложению: немедленно обновите PHP.

Уязвимости имеют идентификаторы

У Вас недостаточно прав для просмотра ссылок. Вход или Регистрация

и

У Вас недостаточно прав для просмотра ссылок. Вход или Регистрация

. Обе имеют оценку CVSS 4.0 равную 9,2, и их эксплуатация может произойти до того, как обычный код приложения успеет принять меры защиты.

Это проблема среды выполнения PHP. Обновление WordPress, Magento, Laravel или плагинов - всегда разумный шаг, но он не устраняет эти уязвимости. Даже прекрасно поддерживаемая CMS, построенная на уязвимом PHP, по-прежнему использует уязвимый PHP.

Что произошло​

Эти две уязвимости затрагивают разные части обработки запросов в PHP. Одна из них может привести к повреждению памяти, когда состояние «не хватает памяти» прерывает инициализацию внутренних данных запроса. Другая может оставить состояние, связанное с запросом, доступным после освобождения памяти, что позволяет последующему запросу, обрабатываемому тем же рабочим процессом, использовать устаревшие данные.

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

Проект PHP предупреждает, что под угрозой находятся системы, обслуживающие веб-запросы через PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed. Был продемонстрирован полноценный эксплойт без аутентификации, направленный против типичных конфигураций mod_php, а уязвимые пути также существуют в средах PHP-FPM.

В ранних уведомлениях говорилось, что активного использования уязвимости не наблюдалось. Ситуация быстро изменилась, как и следовало ожидать после публичного раскрытия информации.

У Вас недостаточно прав для просмотра ссылок. Вход или Регистрация

об обнаружении атакующего трафика и попытках модификации полезных нагрузок с целью обхода фильтрации.

У Вас недостаточно прав для просмотра ссылок. Вход или Регистрация

.

Установите исправленную версию PHP​

Проект PHP выпустил следующие исправленные версии:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

Установите исправленные пакеты, предоставленные репозиторием или поставщиком операционной системы, которую вы фактически используете. Это различие имеет значение. Debian, Ubuntu, AlmaLinux, CloudLinux, Remi, поставщики панелей управления, производители NAS и платформы управляемого хостинга могут переносить исправления, сохраняя при этом собственную схему версий пакетов. Проверьте уведомление о безопасности от поставщика, а не делайте выводы о безопасности сервера, основываясь только на первых двух цифрах в команде php -v.

После установки обновления перезапустите Apache, PHP-FPM, контейнеры или другие долго работающие PHP-процессы. Новые пакеты на диске не исправляют старые процессы, уже находящиеся в памяти.

Затем проверьте версию, используемую самим веб-сайтом. Бинарник PHP для командной строки, модуль веб-сервера, пул FPM и образ контейнера могут быть установлены по-разному. Удивительно легко обновить «вежливый» бинарник PHP, отвечающий в вашем терминале, в то время как общедоступный веб-сайт продолжает взаимодействовать со своим более старым «собратом».

Если PHP поставляется из образа контейнера, пересоберите или загрузите исправленный образ, повторно разверните его и убедитесь, что старых копий не осталось. Если он является частью сетевого хранилища (NAS), маршрутизатора, бытовой техники или панели управления хостингом, следуйте рекомендациям производителя. Не заменяйте встроенный пакет вручную, если только производитель явно не дает на это указания.

Старым версиям PHP требуется нечто большее, чем просто оптимизм​

PHP 8.1 и более старые ветки больше не поддерживаются проектом PHP. Разработчики предоставили минимальные бэкпорты на уровне исходного кода для PHP 7.4, 8.0 и 8.1, чтобы помочь поставщикам, использующим эти версии, но это не новые поддерживаемые выпуски PHP и не являются веским поводом для бесконечного использования устаревшего стека.

Анализ Cloudflare показывает, что уязвимое поведение прослеживается вплоть до PHP 5.4. Поэтому администраторам старых приложений следует проверить, предоставляет ли их дистрибутив или коммерческий поставщик с долгосрочной поддержкой исправленный пакет. Если нет, переход на поддерживаемую версию PHP является частью мер по устранению уязвимости.

Старая версия PHP может скрываться за сайтом, который бесперебойно работал в течение многих лет. К сожалению, "он по-прежнему выдает страницы" и "он по-прежнему получает исправления безопасности" - это две совершенно разные проверки работоспособности.

Если вы не можете выполнить обновление немедленно​

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

Самым безопасным временным решением является предотвращение поступления запросов в PHP. Остановите уязвимый PHP-сервис или веб-сервис либо заблокируйте публичный доступ на уровне балансировщика нагрузки, обратного прокси-сервера или брандмауэра. Страница технического обслуживания WordPress или Magento — это не то же самое: для её отображения PHP всё равно выполняется. Перевод приложения в режим «только для чтения» также сам по себе недостаточен, поскольку уязвимая обработка происходит внутри среды выполнения, а не только при записи данных приложением.

Cloudflare развернул временную защиту WAF для всех тарифных планов, включая бесплатный. Размещение сайта за Cloudflare может добавить полезный уровень защиты на время обновления систем, но Cloudflare явно описывает это как многоуровневую защиту, а не замену установке исправлений. Другие прокси-серверы и WAF-продукты могут публиковать свои собственные правила и рекомендации.

В

У Вас недостаточно прав для просмотра ссылок. Вход или Регистрация

также рекомендуются временные меры по укреплению безопасности:

• Отключите отображение прогресса загрузки в сессии с помощью session.upload_progress.enabled=0, а затем перезапустите все PHP-рабочие процессы. Установите этот параметр в файле php.ini, пуле PHP-FPM или другой конфигурации на уровне сервера, загружаемой до анализа запроса. Установка этого параметра через код приложения или файл .user.ini для этой цели будет слишком запоздалой.
• Уменьшите значения post_max_size и upload_max_filesize до минимальных значений, необходимых приложению. Если загрузка файлов не требуется, отклоняйте многочастные запросы на веб-сервере или обратном прокси.
• Применяйте ограничения на размер тела запроса на прокси или веб-сервере, в том числе для запросов без пригодного заголовка Content-Length.
• В PHP 8.5 установите fatal_error_backtraces=0 и перезапустите рабочие процессы.

Эти меры ограничивают подтвержденные пути атаки, но уязвимости образуют цепочку с несколькими маршрутами. Не существует какого-либо «волшебного» параметра конфигурации, который сделал бы уязвимую сборку PHP эквивалентной исправленной.

В одном из ранних электронных писем отрасли также предлагалось включить параметр session.use_only_cookies. Это по-прежнему является разумной мерой безопасности для сеансов, но окончательные рекомендации по PHP конкретно сосредоточены на отключении возможности загрузки файлов в рамках сеанса. Ни один из этих параметров не должен задерживать обновление.

Проверьте, что происходило до установки патча​

Поскольку в настоящее время фиксируются атаки, установка обновления - лишь первая задача, которую необходимо выполнить на сервере, подключенном к Интернету. Просмотрите веб-журналы, журналы прокси, PHP, аутентификации и системные журналы на предмет необычных запросов или поведения. Ищите незнакомые файлы, запланированные задания, пользователей, процессы, SSH-ключи и неожиданные исходящие соединения.

Если есть признаки взлома, изолируйте сервер. Сохраните информацию, необходимую для расследования, восстановите систему из исходного кода, о котором известно, что он исправен, и смените учетные данные и секретные ключи, к которым мог получить доступ злоумышленник. Недостаточно просто сменить один пароль, если на сервере хранились учетные данные для баз данных, токены API, ключи развертывания или данные доступа к другим системам.

Резервные копии должны быть уже сохранены в независимом месте, зашифрованы и периодически проверяться. Резервная копия чрезвычайно полезна после инцидента, при условии, что она не привязана к скомпрометированному серверу и не поджидает вас с ошибкой восстановления.

Наконец, составьте перечень ресурсов. Проверьте производственную среду, тестовую среду, среду разработки, забытые субдомены, старые проекты клиентов, CI-раннеры, аппаратные устройства и контейнеры. Интернет-сканеры не знают, какой сервер должен был быть временным, и не славятся тем, что уважают комментарии типа "TODO".

Сначала установите исправление, потом проводите расследование - ни то, ни другое не откладывайте​

Уязвимости CVE-2026-109618 и CVE-2026-109619 затрагивают уровень, лежащий в основе огромного количества веб-сайтов и приложений. Они относятся к категории критических, исправления уже доступны, а вредоносные запросы уже циркулируют в сети.

Обновитесь до исправленной сборки PHP, перезапустите все рабочие процессы и проверьте, какая версия фактически обслуживает веб-трафик. Если немедленное обновление действительно невозможно, ограничьте публичный доступ к сервису или установите перед ним временные средства защиты на время проведения технического обслуживания. Страница с уведомлением о техническом обслуживании и благие намерения не являются мерами безопасности.

У Вас недостаточно прав для просмотра ссылок. Вход или Регистрация

У Вас недостаточно прав для просмотра ссылок. Вход или Регистрация

​

 

[XFI Bot]

Ну и сайт пока существующий с рекомендациями на русском -

У Вас недостаточно прав для просмотра ссылок. Вход или Регистрация

.

 

[Sadorimatsu]

О да, я как раз одна из жертв такого взлома у хостера своего. Он даже обозначил это так: Уровень уязвимости - Князь тьмы. И ведь лучше не назвать, дыра очень серьёзная и притом касается абсолютно всех.

 

[anastasiya]

я как раз одна из жертв такого взлома у хостера своего.

как это проявляется?

 

[Sadorimatsu]

как это проявляется?

Изначально сбой обнаружился в VMmanager 6 у First.VDS. Я попал в список пострадавших, где злоумышленники смогли прочитать весь мой виртуальный сервер, но ничего в нём не делая, иначе говоря смогли узнать данные от БД, как и добраться до БД проблем нет, тем самым был риск и факт возможной кражи ПД. Выгружали ли сервер тоже неизвестно, известен лишь факт чтения всех файлов на сервере. Моя задача как пострадавшей стороне и оператору, подать уведомление РКН с момента получения письма от провайдера своего, сообщить о том, какие меры были приняты, какие расследование провел и какой ущерб мог получить. Всё это надо в РКН расписывать было и по закону обязаны это сообщить в течении 24 часов + можно добавить сразу базовый отчёт по расследованию, если не проводил, то галку там не ставим и обязуемся подать такой отчёт за 72 часа, я подавал его сразу, так что не заморачивался. Базовая процедура по серверу требует сменить все пароли SSH, MySQL и сбросить пароли пользователей на XF. И проверить всё ли в порядке с файлами. Ну и как из новости известно нужно обновить РНР до необходимых версией + nginx.

Спойлер

 

[Casablanca]

Установил обновление вчера почти сразу.
А как можно по логам узнать был взлом или нет?

 

[MrFallen]

Изначально сбой обнаружился в VMmanager 6 у First.VDS.

Разве это не 2 разные уязвимости?

 

[MrFallen]

Моя задача как пострадавшей стороне и оператору, подать уведомление РКН с момента получения письма от провайдера своего, сообщить о том, какие меры были приняты, какие расследование провел и какой ущерб мог получить. Всё это надо в РКН расписывать было и по закону обязаны это сообщить в течении 24 часов + можно добавить сразу базовый отчёт по расследованию, если не проводил, то галку там не ставим и обязуемся подать такой отчёт за 72 часа, я подавал его сразу, так что не заморачивался.

OFFTOP

Я не знаю даже как описать то, что я прочитал. То ли восхищаться, то ли недоумевать.

 

[Matew]

OFFTOP

Я не знаю даже как описать то, что я прочитал. То ли восхищаться, то ли недоумевать.

Он зареган как оператор ПД, так что тут лучше сообщить. А если не зареган, то свой выбор уже в принципе сделан)

 

[Sadorimatsu]

Разве это не 2 разные уязвимости?

Скорей общая т.к. залезли как раз по причине общей дыры в РНР, это просто выяснилось чуть позже. Тут и понеслось.

Я не знаю даже как описать то, что я прочитал. То ли восхищаться, то ли недоумевать.

Если вы входите в условие обслуживания РКН и подавали уже уведомление об обработке ПД, то по закону обязуетесь уведомить, в противном случае могут проверить пострадавших и здравствуй штраф (для физ.лиц от 50 до 100к), о которых обязательно сообщит провайдер в своём отчёте. Учитывая, что ситуация вылезла в масштабный взлом т.к. коснулось не только моего провайдера и пострадавших прилично. Я то от этого особо не пострадал, сервер в порядке, но сам факт возможной утечки ПД это не отменяет т.к. чтение было зафиксировано. Если вы не входите в условием обработки ПД и письмо счастья от провайдера не получали, то можете выдохнуть. Когда случился взлом, знали бы как паниковали клиенты от юр.лиц, кто-то даже не успел подать уведомление РКН спустя уже 2 дня. Конечно, вы можете не подавать, но ничто не мешает РКН поднять проверку по списку пострадавшим и проверить, кто из него уведомлял, а кого стоит проверить. Так что, выбор есть всегда, а кто не рискнул подать, что же, пусть молятся, чтобы их не заметили.

Я когда занимался формированием документов, уже под корку въелись все эти нюансы. Рисковать не хочется, да и благо сам подстраховался.

 

[Sadorimatsu]

Установил обновление вчера почти сразу.
А как можно по логам узнать был взлом или нет?

Если чтение было напрямую вашей виртуалки, то по факту никак. Если вам не сообщал об этом провайдер ваш, то вам беспокоится нечего. А так, в помощь базовые команды вашей ОС сервера на диагностику логов посещений, активности, списка IP в тот период. Ну и конечно проверить статус файлов на факт чтения и их изменения и добавления. Более вы всё равно сделать не сможете. Или оставляйте заявку поддержке провайдера, сами изучат. Для базовой профилактики не лишне обновить все пароли.