Обсуждение Как защитить php 5.6? Легко! (CVE-2026-109618 и CVE-2026-109619)

[paton]

Все наверно слышал про найденные ИИшками новые уязвимости в php CVE-2026-109618 и CVE-2026-109619(кто нет гуглим)

Сайтов много и пока нет времени обновлять их всех. крч посовещался я тут с теми же ИИками и такое сделал.

у меня VestaCP + php5.6-fpm, настроки для сервера 32гб - 8 ядер, Debian



1). Ставим 555 на папки и 444 на файлы

cd /home/admin/web

find . -type f -name "*.php" -exec chmod 444 {} \;

find . -type d -exec chmod 555 {} \;

возвращаем права 755 на папки в которые идет добавление материала(картинки кеш и т.д.) в DLE например это uploads и /engine/cache/

для того что бы в этих папках нельзя было выполнить php код прописываем в nginx

location ~* ^/(uploads|img|torrent)/.*\.php$ {
    deny all;
    return 403;
}
location ~* ^/engine/cache/.*\.php$ {
    deny all;
    return 403;
}

2) php.ini

; Отключаем опасные функции, через которые запускаются шеллы на сервере
disable_functions = exec,system,passthru,shell_exec,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

; Отключаем отслеживание прогресса загрузки файлов (частый вектор для Use-After-Free)
session.upload_progress.enabled = Off

; Запрещаем PHP открывать удаленные файлы (снижает риски инъекций)
allow_url_fopen = Off
allow_url_include = Off
post_max_size = 2M
upload_max_filesize = 2M
memory_limit = -1

у меня в VestaCP отдельные конфиги для fpm5.6

/etc/php/5.6/fpm/pool.d/site.ru.conf

# ЗАЩИТА: Сбрасываем воркер после каждого запроса для очистки памяти
pm.max_requests = 1

# ЗАЩИТА: Срезаем максимальный размер загрузок до безопасных 2 МБ
php_admin_value[upload_max_filesize] = 2M
php_admin_value[post_max_size] = 2M

# ЗАЩИТА: Отключаем внутренний лимит памяти PHP для нейтрализации CVE-2026-109618
php_admin_value[memory_limit] = -1

3). Ограничение памяти на уровне ОС (Защита сервера)

systemctl edit php5-fpm

[Service]
# Ограничиваем максимальное потребление памяти всей службой PHP-FPM до 8 ГБ
MemoryMax=8G
MemoryHigh=6G

перезагружаем все службы

systemctl restart php5.6-fpm

systemctl restart nginx





P.S.: Если у вас статический сайт без добавления новостей и коментов то можно просто запретить POST запросы и все

nginx

if ($request_method = POST) {
    return 444; # Сбросить соединение без ответа
}

P.S. 2: Это копия моей статьи с серча(что бы больше народу увидело).

 

[Skyworker]

Все верно! Достаточно было спросить ИИ Гугла, как прикрыть эту форточку для старых систем и он разложил все по полочкам за 5 минут. Здешний ИИ туповат, конечно 😄

 

[paton]

@Skyworker ну как бы что бы получить эти все настройки я задал не 1 вопрос, и не 1 день мучал ИИ, если бы он сразу все это выдал я бы и пост не создавал. pm.max_requests = 1 php_admin_value[memory_limit] = -1 эти два параметра он родил только после того как скинул статью про взлом энтузиастом за 2000$

 

[paton]

кстати это как раз был ИИ гугла гемини)

 

[Skyworker]

@Skyworker ну как бы что бы получить эти все настройки я задал не 1 вопрос, и не 1 день мучал ИИ, если бы он сразу все это выдал я бы и пост не создавал. pm.max_requests = 1 php_admin_value[memory_limit] = -1 эти два параметра он родил только после того как скинул статью про взлом энтузиастом за 2000$

Мне обычный чат Гугла дал весь расклад при правильном заданном вопросе, еще и кучу вариантов блока дырки предложил. gimini - это же тот же Гугл, только платный, но в другой обертке.

 

[paton]

Еще парочка
1. Главное правило: не хранить сайты на аккаунте admin
Учетная запись admin в VestaCP — это суперпользователь панели. Ей по умолчанию подвластны все настройки сервера, DNS, почтовые домены и другие пользователи.
Что делать: Используйте аккаунт admin исключительно для администрирования (управление панелью, создание других пользователей, мониторинг).
Как правильно: Для каждого реального сайта создайте отдельного обычного пользователя в панели (например, site_owner1, client_project). Если сайт этого пользователя взломают через уязвимость в CMS или PHP, злоумышленник будет заперт в рамках домашней директории (/home/site_owner1/) и не сможет навредить остальной системе или соседним сайтам.

2. Как WAF в Nginx помогает против PHP2Shell?
WAF (Web Application Firewall, например, на базе ModSecurity, NAXSI или коммерческих решений) анализирует весь входящий HTTP-трафик до того, как запрос попадет в интерпретатор PHP.
Если в WAF загружены актуальные сигнатуры (правила обнаружения, которые выпустили вендоры безопасности вроде Positive Technologies, «Лаборатории Касперского» или профильные сообщества), он способен:
Перехватить вредоносные запросы: Заблокировать аномальные HTTP-запросы со специфическими структурами, аномально раздутым значением PHPSESSID или паттернами, вызывающими искусственное переполнение памяти.