Comments 66
https://php2shell.ru - методы зщаиты от PHP2Shell и ссылки на патчи, информация обновляется.
Спамить плохо
Зависть? Человек помощь сообществу хочет!
Пусть придумает другой способ, все его комментарии это спам этой ссылкой. Если применять критерий полезности для общества, то окажется, что всем можно спамить чем угодно где угодно, а это, очевидно, вредно.
P.S. Если оценивать текст сайта, то первый же рекомендуемый способ исправления уязвимости (не считая самого патча), судя по [1], на самом деле не работает. На сайте даже нет почты для обратной связи, поэтому @unsec никогда бы не узнал, если у него что-то написано не так.
Не открывается.
информация обновляется
Таки похоже, что есть и третья уязвимость:
Похоже, это CVE-2026-115560, PHP её уже анонсировал. Срабатывает только при смене serialize_handler на лету через ini_set() перед session_start(), экстренного патча не будет, фикс войдёт в плановый релиз. Закрывается тем же session.upload_progress.enabled=0, так что тем, кто выключил его 21-го, ничего делать не нужно.
Уязвимы ли совсем старые версии PHP? До сих пор есть сайты, которые работают на 5.X
да, уязвимы
5.4 включительно
Sansec wrote “PHP 5.4 or later” and watchTowr named versions 5, 6, 7 and 8, which includes a PHP 6 that never shipped. The advisory lists patched versions for 8.2 through 8.5 only, and the mechanism goes back further than the rumor, since the same jump sits in the PHP-5.3 allocator. I have not seen an exploit shown on those old versions either.
Да, ValdikSS прав, уязвимы версии начиная с 5.4. Официально PHP выпустил исправления только для 8.2–8.5. Для 7.4–8.1 есть бэкпорты в исходниках, а для 5.4–7.3 от апстрима ничего не будет. Так что для 5.x всё зависит от того, откуда пакет. CloudLinux заявляет бэкпорт во все alt-php и ea-php, включая EOL-ветки, а часть панелей пересобрала свои PHP вплоть до 5.4. Для sury и Remi надёжнее смотреть changelog конкретного пакета на CVE-2026-109618/109619. Если CVE там нет, считайте версию уязвимой.
Хорошие новости, патч выпущен также и для 7.4.*, 8.0.* и 8.1.*
https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619
https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619
https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619
Так ведь получается достаточно уменьшить на фронтенде макс размер файла до меньшего размера, чем указано в memory_limit/post_max_size/upload_max_filesize, чтобы еще на уровне nginx запрос обрывался с 413 (или apache c 400), и утечка памяти была бы невозможной, т.к. memory_limit бы и не дергался (это касается CVE-2026-109618)
Проблема еще в том, что memory_limit может быть задан в php.ini и потом еще 10 раз изменен в .htaccess и самих php скриптах. Причем как в большую, так и в меньшую сторону. Много раз наблюдал когда изначально стоит допустим 1024мб лимит, но скрипт обрывается с ошибкой по памяти. В итоге выясняется что где-то в недрах скриптов зачем-то стоит невозмутимая строчка типа ini_set(‘memory_limit’, '128M');
А если в nginx сделать совсем уж малое значение, то появиться могут проблемы у нормальных запросов.
Справедливо, но в официальной рекомендации memory_limit=-1 идёт в связке. Его задают через php_admin_value, чтобы скрипт и .htaccess не могли переопределить. Плюс низкий post_max_size и лимит размера запроса на уровне веб-сервера (client_max_body_size / LimitRequestBody). Память тогда ограничивают снаружи: cgroup или лимиты контейнера и pm.max_children. Отдельно сказано не использовать RLIMIT_AS / RLIMIT_DATA. Всё это временная мера до патча, а не замена ему.
Во многих дистрибутивах уже забэкпортили фикс на более старые версии PHP - тем не менее, скрипт выдает, что уязвимость есть.
php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium
SECURITY UPDATE: Remote RCE via state corruption issue
<...>
CVE-2026-109618_109619.patch
Скрипт тупо грепает версию из php -v, а там апстримный номер не меняется при секьюрити-бэкпортах. Смотреть нужно исключительно changelog самого пакета через apt-changelog или rpm, иначе получите ложную тревогу на полностью защищенной системе
100%
zgrep -E ‘CVE-2026-109618|CVE-2026-109619’ /usr/share/doc/php8.3-common/changelog.Debian.gz
- debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via
- CVE-2026-109618
- CVE-2026-109619
Добавлю к changelog ещё одну проверку: пакет может быть обновлён, а воркеры при этом продолжают крутить старый код в памяти до перезапуска FPM или Apache. Поэтому смотрите ещё Build Date в phpinfo(), открытом через веб, а не в php -v: у CLI и FPM бинарники могут быть из разных пакетов. Если дата после 21.10 и в changelog есть CVE, патч действительно работает.
Оперативно обновился до 8.4.27 , образ интернет магазина в докере. Стояла 8.4.18 , правда репу пришлось поменять .. в той что была последняя версия 8.4.26 была. Mailcow сборка тоже еще не обновились .. последняя версия 8.2.29 установлена.
Для Ubuntu Ondřej Surý (официальный maintainer пакетов PHP в Debian и Ubuntu) поддерживает сборки PHP вплоть до 5.6.
Сегодня он выкатил обновления для всех поддерживаемых им версий, т.е. есть собранные бинарники для РHP 5.6, всех 7.x и всех 8.x.
@Gnidenko стоит добавить ссылку на PPA для Ubuntu в статью, чтобы было заметнее.
Да, товарищ Ondřej Surý прям выручает. Правда серверы у него теперь перегружены, судя по периодическим 503-им...
Используйте зеркало https://mirror.yandex.ru/mirrors/packages.sury.org/php/
К тому же с 2024 он блокировал российские IP. Сейчас не знаю, у меня почему-то обновилось с его репозитория.
автор этих пакетов (Ondřej Surý) официально объявил о миграции репозиториев Ubuntu с нестабильной платформы Launchpad PPA на собственные выделенные серверы packages.sury.org
и вчера обновления на sury.org появились раньше чем на launchpad.net
Ондржей в очередной раз спасает половину мирового веба в одиночку, мужик буквально держит на своих плечах легаси миллионов серверов...
Теперь нужен скрипт для поиска руткитов.
Руткит называется так потому, что работает с правами рута. В данном случае, даже если вы сумеете пробиться сквозь эту дыру внутрь сревера, а это капец как сложно, то сможете запустить что-нибудь с правами пользователя, от имени которого работает php, например, www-data. Эскалировать права до рута - задача ещё сложнее, чем вломиться в сервер.
Эксплойты то показали хоть один?
Обновился на своем серваке, Debian 13 все подкатилось оперативно... А что будет с вебом у хостеров можно себе только вообразить... Мамкины кулхацкеры и серьезные дядьки будут штурмовать в ближайший год-два все что шевелится.
Совет выставить memory_limit в минус один на проде без жестких внешних cgroups закончится тем, что первый же тяжелый экспорт положит сервер по OOM-киллеру
Всё же лучше чем вирусня на сервере.
Ну и есть шанс что вылетит именно веб-сервер с последующим перезапуском, особенно если lru-gen включить.
Согласен. В официальной рекомендации -1 и не задумано как отдельная мера: к нему в связке идут php_admin_value (как вы писали ниже), низкий post_max_size и лимит размера запроса на веб-сервере (client_max_body_size / LimitRequestBody). Память при этом ограничивают снаружи, через cgroup и pm.max_children. Отдельно сказано не использовать RLIMIT_AS / RLIMIT_DATA. Но это всё равно временная мера до патча.
Уязвимы обработчики форм с загрузкой файлов multipart/form data. Если загрузки файлов нет, можно и не переживать.
Чтобы таким образом не переживать, нужно сначала отключить данный функционал для всего PHP. Запрос с multipart/form отправить на ваш сервер никто не мешает, даже если у вас нет функционала его обработки.
Как таким способом вызвать переполнение памяти? в этом ведь корень проблемы?
Отправить большой запрос. Опционально - ещё и в формате gzip-бомбы. Что именно здесь непонятного?
Он не будет обрабатываться, если нет эндпойнта и обработчика, так бы и вешали любые сервера, шли "большие запросы", или gzip бомбу куда захочется, никакой ddos и не нужен.
Он будет записан в $_FILES ещё до того, как ваш фреймворк получит управление и увидит что нет обработчика.
Вот это формирование $_FILES и вызывает OOM. Если что, под OOM тут понимается выход за внутренний memory limit отведённый запросу, а не системный.
Обычно этот memory limit как раз и защищает сервер от DoS, но в этот раз в его обработке обнаружилась проблема.
А опция upload_progress поможет в защите?session.upload_progress.enabled = Off
Ресурсы не потребляются, если просто отправлять файл на сервер. Нужно чтобы php на сервере явно записал файл в переменную.
Я вам даже привёл эту переменную.
Эта переменная просто содержит служебную информацию о файле.
Я проверил на своем сервере, у меня очень ограниченное количество оперпамяти. Закинул видео-файл 250 мб. Да, он загружается без всяких эндпойнтов обращением к корневому index.php и попадает в папку /tmp.
Но потребление оперпамяти и других ресурсов при этом незаметно, после загрузки сразу удаляется, т.к. никакой работы не выполняется.
Почему-то эти два дня я вижу много таких сообщений от людей, которые упорно думают, что уязвимость случается только если php-скрипт что-то делает, и если в скрипте что-то не делать - то дыра-то у них в безопасности!
Но это не так. Уязвимость не в каких-то конструкциях языка. Уязвимость глубоко в ядре, и абсолютно любой сервер без обновления уязвим независимо от своей настройки.
Где код эксплоита ? Как проверить свой сервер ?
"свой", ага...
Ну в данном конкретном случае мне надо проверить пару свои серверов.
лучше проверь версию PHP если так переживаешь... эксплоит ему подавай
У меня версия PHP на серверах "очень старая", апгрейдить невозможно, это утянет кучу всего - работы на месяц (если не больше). Я применил ряд затычек и хочу проверить на сколько они эффективны. Во Фре, кстати, есть рандомизация виртуальных адресов и стека (ASLR), мне кажется что это должно сильно усложнить создание эксплоита.
Уже есть бэкпорты патчей под все уязвимые версии.
ASLR есть и в Linux и он не спасает от этой уязвимости. В век нейросетей вообще особенно опасно думать, что под редкую ось никто эксплойт не напишет.
Особая опасность этой уязвимости ещё и в том, что её можно очень по-разному использовать, так что защититься от какого-нибуть одного способа сделать странный запрос недостаточно, чтобы спать спокойно.
Блин, когда вижу код PHP прям отдает таким вайбом детства, школьных лет 😅 Давно ж это было 🌚 Тогда еще v3 актуальна была.А еще была такая штука как PERL… Мдо.
Да, чуть не забыл, а эксплоит то где взять? Это не мне, друг попросил 😅
дулинго изза этого не работает?)
php-расширение которое можно собрать для любой старой версии - хороший вариант? https://github.com/HOSTED-POWER/php_uploadprogress_guard
Проблема НЕ в upload_progress. Это какая-то хроническая боль в интернете - все ломятся его отключать, думая, что тем самым они решили проблему. Но upload_progress это всего лишь теоретическийй способ атаки и его отключение - попытка избежать некоторых возможных сценариев атаки. Вот только бесполезно пытаться защищаться от известных способов эксплуатации, когда всегда могут появиться новые способы буквально через день или даже через минуту.
Понятно, почему хостер (по ссылке видимо кто-то из хостеров) пытается найти обходные пути попроще и побыстрее. Ему обновить множество уязвимых версий на тысячах сайтов довольно сложно, надо что-то сделать уже сейчас. Но это как прикладывание подорожника для лечения сахарного диабета. И далее хостеру не избежать массового обновления.
Официально PHP выпустил исправления только для 8.2–8.5. Для 7.4–8.1 есть бэкпорты в исходниках, а для 5.4–7.3 от апстрима ничего не будет. Поэтому для старых веток всё зависит от того, откуда пакет. CloudLinux заявляет бэкпорт во все alt-php и ea-php, включая EOL-ветки. Для Ubuntu 20.04 с 7.4 исправление есть, по сообщениям, только в Pro. Часть панелей пересобрала свои PHP вплоть до 5.4. Для sury и Remi надёжнее смотреть changelog конкретного пакета на CVE-2026-109618/109619, чем ждать новостей. Если CVE там нет, считайте версию уязвимой.
Про ложные срабатывания: дистрибутивы бэкпортят фикс без смены версии (Ubuntu 24.04 так и остаётся на 8.3.6), поэтому скрипты, которые смотрят на php -v, врут. Мы сделали проверку по релизу пакета (rpm/dpkg/apk) с таблицей исправленных сборок по вендорам: https://github.com/GetPageSpeed/php2shell-check. Для CentOS 7 есть бесплатные пропатченные PHP 5.6-8.4 (дисклеймер: это наш проект GetPageSpeed): https://www.getpagespeed.com/php2shell
PHP2Shell: две RCE в ядре PHP без авторизации. Кто уязвим и как проверить сервер за минуту