Хабр Курсы для админов
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 16
а официальных патчей для ветки 5.6 не выйдет никогда?
На Sury вышли патчи в том числе на 5.6.
Хорошо конечно когда сайт один свой и к нему можно применить все эти "отключите/зажмите". А когда есть сотни/тысячи клиентских (не своих) сайтов и не вариант кому-то поломать ограничениями работу каких-то форм или (что еще хуже) не сразу поломать, а выяснится через месяц что 1/100 запросов не работают как надо. Например если все же есть необходимость заливать что-то большое (post_max_size) или какие-то плагины импортов все же хотят значения max_input_vars сильно больше стокового.
Тот же session.upload_progress как я понял в opencart используется и сайтов на нем очень много клиентских. Не хотелось бы никаких функций отключать и никакими лимитами ничего зажимать.
Да и на производительность (MaxConnectionsPerChild) тоже не плевать как бы...
Плюс версии php ниже 5.6 вообще мало кого волнуют. Это понятно, но опять же, на них существуют клиентские сайты, которые никто никогда обновлять не собирается. Или могут быть случаи когда это физически невозможно - например что-то зашифровано в ioncube под одну определенную версию и все, вариантов обновить просто нет.
Пока я вижу решение проблемы для себя так:
1) 8.2-8.5 офф. обновление от php.net
2) 5.6-8.1 https://github.com/Anton-Barinov/php2shell-patches
3) 5.2-5.5 пока остаются неуловимыми джо и ждем может кто-нибудь снизойдет и пофиксит в них тоже
Маякните тут в комментарии если что-то появится.
Еще не изучал вопрос что именно и как там пофиксил sury.org Тоже только офф решения от php применил или на старые версии тоже что-то сделал?
Я описал свой случай - может кому-то поможет.
В моем случае 32 МБ для post_max_size достаточно, а вы можете установить любой ваш размер - главное чтобы он совпадал с описанными в статье ограничениями перед PHP.
Защита опирается не на конкретную цифру в 32 МБ, а на изменение механизма обработки нехватки памяти. Уязвимость CVE-2026-109618 срабатывает исключительно в том случае, если внутренний менеджер памяти PHP достигает значения, указанного в memory_limit. Установив memory_limit = -1, мы полностью деактивировали этот уязвимый триггер в Zend Engine.
Теперь при загрузке тяжелых файлов (64 МБ, 128 МБ и т.д.) интерпретатор не ограничен собственными лимитами. Если суммарная нагрузка исчерпает 4 ГБ физической памяти, выделенной контейнеру в docker-compose.yml, процесс будет принудительно завершен OOM-killer'ом ядра ОС Linux (сигнал SIGKILL). Это мгновенное прерывание процесса на уровне операционной системы полностью исключает выполнение уязвимых процедур очистки (shutdown) с «мусорными» указателями внутри PHP.
Если бы мне был важен session.upload_progress, то я бы наверно прямо сейчас вынес только эту часть кода в дополнительный маленький контейнер с пропатченой версией PHP.
Я к тому что все это костыли для решения здесь и сейчас. Через год кто вспомнит почему memory_limit стоит -1 или разворачивая с нуля кто вспомнит что надо именно вот так все настроить?
Плюс сейчас у всех оно на слуху, а через год кто-то не будет знать про все эти нюансы и просто например понадобится запустить что-то старое под php5.
Получается на php.net сейчас распространяются потенциально опасные исходники. Которые логично было бы вообще убрать из доступа раз уж они не собираются ничего фиксить.
Для того, чтобы через год не забыли - есть такая штука, называется: документирование. А если документирование не ведется, то... за все надо платить: либо ресурсами на текущее сопровождение, либо шишками при разовых работах. Что более целесообразно владелец сайта волен выбирать сам.
Не надо убирать исходники. Старые версии могут быть нужны. Они предполагают,что использовать их будут те, кто понимает что он делает.
Патч для PHP 5.4 можно попробовать взять из сырцов CloudLinux: https://repo.cloudlinux.com/cloudlinux/9/cloudlinux-x86_64-server-9/Source/Packages/
Пакет их распотрошить можно командой:
rpm2cpio alt-php54-5.4.45-203.el9.src.rpm | cpio -idmv
При таком количестве клиентских сайтов проще готовые панельки использовать.
ispmanager вчера выпустили свои сборки, исправляющие уязвимость в устаревших версиях PHP начиная с 5.4 и до актуальных
Не могу поставить плюс, а спасибо сказать хочется: тоже PHP5.6 - ваши советы очень кстати! Спасибо!
Почему вы все еще используете 5.6? Интересно.
Есть два таких сайта. Там старые CMS с кучей кастомных доработок, поэтому обновление равносильно "сделать с нуля". В одном случае не доходят руки, во втором - владелец сайта пошел по пути "сперва сделать идеальный дизайн, а пока поработать на старой" (естественно, дизайн за 3 года не сделали, а время ушло)
Юзайте https://freeunit.org/ - где только 1 worker - выдерживает 10000 клиентов в сек…
Насколько реально провести атаки по этим CVE? Ибо сами разрабы утверждают что это практически невозможно и это все - истерия.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выживаем при PHP2Shell (CVE-2026-109618 / CVE-2026-109619) на легаси‑стеке: Varnish + Docker + Apache mod_php (PHP 5.6)