На обычном сервере история короткая: обновить пакет и перезапустить PHP. На хостинге с ispmanager и CloudLinux всё оказалось интереснее. За ночь и утро мы закрыли уязвимости на всех серверах и по пути наступили почти на все грабли, которые не описаны ни в бюллетене PHP, ни в документации панели.

Это не пересказ бюллетеня, а список того, что пошло не по инструкции, и как мы это решили. Если вы администрируете сервер с ispmanager, особенно на CloudLinux, проверьте у себя каждый пункт: часть проблем не видна, пока не посмотришь в нужное место.

Временные меры до выхода патчей

Пока пакетов нет, полностью закрыть уязвимости нельзя, можно только отрезать известные пути атаки. Публичные эксплоиты, появившиеся ещё до релиза, использовали обработчик прогресса загрузки файлов, который срабатывает на любой запрос multipart/form-data, даже если на сайте нет ни одной формы загрузки.

Мы сделали две вещи:

1. Отключили session.upload_progress.enabled во всех версиях PHP. Это рекомендация самого PHP, функцию почти никто не использует, сайты от её отключения не страдают. Важно: значение должно задаваться в php.ini или в конфигурации пула, а не через ini_set() или .user.ini, иначе оно применится слишком поздно.
2. Заблокировали multipart на уровне nginx для всех сайтов. В ispmanager каждый vhost подключает /etc/nginx/vhosts-includes/*.conf, поэтому одного файла хватает на весь сервер:

if ($http_content_type ~* "multipart") {
    return 403;
}

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

Два места, которые легко пропустить:

• Дефолтный server в /etc/nginx/nginx.conf. Он ловит запросы по IP и с неизвестным Host и в ispmanager проксирует их в Apache, но vhosts-includes не подключает. Без отдельного include туда атака по IP проходит мимо блока.
• Apache на внешнем адресе. Если Apache слушает не 127.0.0.1, а внешний IP, запрос можно отправить прямо ему, минуя nginx. Проверка: ss -ltnp | grep httpd.

Ловушка CageFS: настройка из панели не доходит до сайтов

Днём мы отключили session.upload_progress.enabled штатно: «Настройки web-сервера → PHP → версия → настройки». Панель показала, что значение сохранено. Вечером проверка изнутри клетки CageFS показала, что у сайтов оно по-прежнему включено.

Причина в том, как устроен alt-php на CloudLinux:

• ispmanager записал значение в /opt/alt/phpXX/etc/php.d.all/session.ini, то есть в ini расширения session;
• расширение session в alt-php встроено и через PHP Selector не подключается, поэтому этот ini внутри клетки никто не читает;
• внутри клетки PHP читает основной /opt/alt/phpXX/etc/php.ini и пользовательский alt_php.ini из /opt/alt/phpXX/link/conf, а это совсем другой каталог, чем видит root.

Отсюда главный урок: проверять PHP нужно от имени пользователя внутри клетки, а не от root:

su -s /bin/bash -c "/opt/alt/php83/usr/bin/php -r 'var_dump(ini_get(\"session.upload_progress.enabled\"));'" ЛОГИН_КЛИЕНТА

Что сработало:

1. Дописать директиву в конец php.ini каждой версии, который действительно загружается (путь даёт php --ini, строка Loaded Configuration File).
2. Выполнить cagefsctl --rebuild-alt-php-ini, чтобы пересобрать пользовательские alt_php.ini.
3. Выполнить cagefsctl --update: у нативного PHP внутри клетки своя копия /etc/php.ini в скелете CageFS, и без обновления скелета правка до сайтов не доходит.
4. Не забыть персональные php.ini сайтов в режиме CGI: ispmanager держит их в /var/www/ПОЛЬЗОВАТЕЛЬ/data/php-bin*/php.ini.
5. Перезапустить httpd и FPM.

И ещё одна деталь: в ту же ночь в 03:37 что-то пересобрало php.ini всех alt-php из шаблона. Если правка живёт только в php.ini, её стоит подстраховать задачей cron, которая проверяет и восстанавливает строку, пока патчи не вышли. Мы так и сделали, и cron несколько раз действительно её возвращал, например после обновления пакетов alt-php.

Блок multipart ломает вход в панель

Через пару часов после блокировки клиент написал, что не может войти в панель: запрос входа получает 403, а интерфейс бесконечно показывает индикатор загрузки. IP клиента никто не блокировал.

Панель ispmanager работает на своём веб-сервере ihttpd на порту 1500, и при входе напрямую на этот порт nginx действительно ни при чём. Но если включён модуль nginx_proxy, панель доступна и через 443 по адресу https://ХОСТ/ispmgr, а форма входа отправляется как multipart/form-data. Наш блок отвечал 403 ещё в nginx, а фронтенд панели такую ошибку показать не умеет.

Модуль подключается только в vhost хоста панели (/etc/nginx/modules-includes/nginx_proxy/), и все его пути уходят в ihttpd, а не в PHP. Поэтому исключение безопасно делать по связке хоста и пути:

set $cve_mp 0;
if ($http_content_type ~* "multipart") { set $cve_mp 1; }
set $cve_hu "$host:$uri";
if ($cve_hu ~* "^panel\.example\.com:/(ispmgr|mancgi|manimg|long|shell|notify)(/|$)") { set $cve_mp 0; }
if ($cve_mp = 1) { return 403; }

Исключение только по пути без хоста было бы ошибкой: запрос на клиентский-сайт/ispmgr ушёл бы в Apache, а там WordPress перепишет его на index.php, и PHP разберёт multipart. На хосте панели этот путь гарантированно уходит в ihttpd.

Список путей лучше брать из самого модуля (grep location /etc/nginx/modules-includes/nginx_proxy/*.conf), а не по памяти. И проверять сразу после перезагрузки nginx не стоит: первые запросы может ещё обслужить старый воркер со старой конфигурацией.

Забытые Roundcube и phpMyAdmin

Когда вышли патчи alt-php, мы обновили пакеты и сняли блок. И только потом вспомнили, что веб-почта и phpMyAdmin в ispmanager работают не на той версии PHP, которую вы выбрали для сайтов. Обновление alt-php их не касается.

Оба приложения подключаются через vhosts-includes, то есть доступны на каждом домене сервера (/roundcube, /webmail, /phpmyadmin или путь со случайным префиксом). Какой PHP их выполняет, видно по fastcgi_pass в этих файлах:

grep -E 'location|fastcgi_pass' /etc/nginx/vhosts-includes/*roundcube*.conf /etc/nginx/vhosts-includes/*phpmyadmin*.conf

У нас нашлось сразу несколько вариантов на разных серверах:

Вторая колонка важна не меньше первой. Apache получает эти запросы в двух случаях:

• запрос по IP или с неизвестным Host уходит через дефолтный server nginx прямо в Apache, где Alias /webmail и /phpmyadmin глобальные;
• в конфигурации nginx для /webmail и /phpmyadmin стоят error_page 404 @apache и error_page 502 = @apache. Адрес с PATH_INFO вроде /webmail/index.php/x не совпадает с location ~ \.php$, получает 404 и уходит в Apache, где его выполнит mod_php.

На одном из серверов нативный PHP был 5.4 из CentOS 7, для которого исправлений не будет никогда. Пока мы переводили эти приложения на alt-php, блок multipart оставался только на их путях, а сайты уже работали без ограничений:

if ($uri !~* "^/(roundcube|webmail|phpmyadmin)(/|$)") { set $cve_mp 0; }

Клиенты в это время не могли прикреплять вложения в веб-почте, и они это заметили почти сразу.

Почему на CloudLinux номер версии не меняется

CloudLinux выпустил исправления для всех веток alt-php сразу, от 5.4 до 8.5, но не в виде 8.3.36 или 8.4.27, а как новые сборки прежних версий: alt-php83-8.3.35-6, alt-php84-8.4.26-5, alt-php85-8.5.11-5 и так далее. Патч вносится в установленную версию, растёт только номер релиза пакета.

Поэтому скрипты проверки, которые сравнивают PHP_VERSION с 8.3.36, будут показывать «уязвимо» и после обновления. А клиенты, заглянувшие в панель, увидят те же цифры и спросят, почему ничего не обновлено. Надёжных признаков два.

Changelog пакета. Для старых веток CloudLinux дополнительно вырезал обработчик прогресса загрузки целиком:

for p in $(rpm -qa --qf '%{NAME}\n' 'alt-php[0-9]*' | grep -E '^alt-php(5[4-9]|[78][0-9])$' | sort -V); do
  printf '%-10s %-16s ' $p "$(rpm -q --qf '%{VERSION}-%{RELEASE}' $p)"
  rpm -q --changelog $p | head -10 | grep -c 'CVE-2026-10961[89]'
done

Build Date в phpinfo(). У исправленных сборок там 21 октября 2026, у предыдущих более ранние даты. Это то, что можно сообщить клиентам: проверить может любой, без доступа к серверу.

С нативным PHP та же история с другой стороны. На RHEL 9 и его пересборках исправленная версия 8.0 называется php-8.0.30-8.el9_8.1 (бюллетень Red Hat RHSA-2026:87151), а в changelog номера CVE оказались приклеены к последнему пункту списка с совсем другим описанием. Без бюллетеня по changelog это легко принять за обычное обновление.

У пакетов ispmanager (isp-phpXX) changelog вообще шаблонный, с одной записью 2019 года. Признаки исправления там косвенные: номер сборки (у нас 1781 для 8.2-8.5, 1782 для 7.4, 1786 для 7.1) и Build Date 22 октября.

Подводные камни самого обновления

dnf --best --allowerasing на сервере с ispmanager. На CloudLinux 9 dnf update вываливал длинный список конфликтов: в репозитории есть нативный PHP 8.3.36 из модульного потока, и dnf считает его лучшим кандидатом для установленного 8.0. Но модуль Apache от ispmanager (isp-httpd-mod_php) жёстко требует PHP 8.0.x, а от него зависят coremanager-pkg-php и ispmanager-pkg-php, то есть сама панель. Подсказка dnf добавить --best --allowerasing здесь опасна: она удалит пакеты панели. Конфликт безвреден, в конце dnf пишет Nothing to do. Чтобы убрать шум до выхода сборки 8.0: dnf update --exclude='php,php-*'.

Модуль Apache для PHP у ispmanager свой. Он грузится из modules/isp-libphp8.so и принадлежит пакету isp-httpd-mod_php, а не системному php. Исправления этих CVE находятся в ядре PHP, то есть внутри самого модуля, и обновление пакета php его не меняет. Проверка:

grep -rhE 'LoadModule\s+php' /etc/httpd/conf.modules.d/ /etc/httpd/conf.d/
rpm -qf /etc/httpd/modules/isp-libphp8.so
strings /etc/httpd/modules/isp-libphp8.so | grep -m1 -E '[A-Z][a-z]{2} [ 0-9][0-9] 20[0-9]{2}'

Если модуль собран раньше 21 октября, все сайты в режиме «Модуль Apache» остаются уязвимыми. Найти их: grep -lE 'SetHandler\s+application/x-httpd-php\s*$' /etc/httpd/conf/vhosts/*/*. Мы перевели такие сайты на alt-php, а там, где это невозможно (интерфейс, которому нужен доступ вне CageFS), закрыли доступ по IP.

Выключенный PHP хуже включённого. Часть бывших mod_php-сайтов оказалась статикой, и мы выключили им PHP. На одном из них рядом с заглушкой лежал 61 файл старого сайта, и при выключенном PHP их исходники, включая конфиг с паролем от базы, отдавались как текст. Перед выключением PHP проверяйте: find ДОКРУТ -name '*.php*' | wc -l.

Обрыв SSH посреди транзакции. Обновление 160 пакетов alt-php шло несколько минут, и связь оборвалась. Транзакция, к счастью, завершилась, но проверять нужно: dnf history list, dnf check (на CentOS 7: package-cleanup --problems, package-cleanup --dupes). Длинные обновления лучше запускать в tmux.

Тихие пересборки ispmanager. Исправленные isp-php выходили в течение суток по одному: сначала 8.2-8.5, потом 7.4, потом 7.1. Для CentOS 7 сборка 7.4 на момент написания так и не появилась. Имеет смысл несколько раз в день проверять dnf check-update 'isp-php*'.

Как перевести Roundcube и phpMyAdmin на alt-php

На сервере с нативным PHP 5.4 мы перевели служебный пул FPM apache на alt-php56, сохранив тот же сокет. Тогда конфигурацию nginx менять не нужно, а откат сводится к запуску старого сервиса. Выбор 5.6 вместо 7.4 простой: Roundcube 1.4 и старый phpMyAdmin работали на 5.4, 5.6 ближе всего, и CloudLinux выпустил для неё бэкпорт.

Шаги:

1. Свой каталог ini. Вне CageFS alt-php от root подключает только минимум расширений, остальные лежат в php.d.all. Мы собрали один extensions.ini из нужных модулей (session, json, dom, xml*, mbstring, intl, gd, mcrypt, zip, pdo, nd_mysql*). Ini-файлы CloudLinux сами подтягивают зависимости, поэтому дубликаты строк extension= убираем.
2. Конфиг FPM с пулом apache на /var/run/php-fpm.apache.sock, теми же user, group, listen.owner и явным session.save_path, потому что в нативном php.ini он не был задан.
3. Проверка до переключения: PHP_INI_SCAN_DIR=… php -m без ошибок и php-fpm -t -y … с test is successful.
4. systemd-юнит с Environment=PHP_INI_SCAN_DIR=… и ExecStart=… php-fpm --nodaemonize -y ….
5. Переключение: переименовать /etc/php-fpm.d/apache.conf, перезапустить нативный FPM (у него остаётся пул www), запустить новый. Простой несколько секунд.
6. Apache тоже на этот сокет. В roundcube-webmail.conf и phpmyadmin-httpd.conf заменить SetHandler application/x-httpd-php на SetHandler "proxy:unix:/var/run/php-fpm.apache.sock|fcgi://localhost/", в roundcube-isp.conf заменить сокет isp-php74. Проверить, что SetHandler стоит внутри <FilesMatch "\.php$">, иначе в FPM уйдёт и статика.

Удаление дубликатов расширений из шага 1:

awk '/^[[:space:]]*(zend_)?extension[[:space:]]*=/ { k=$0; gsub(/[[:space:]]/,"",k); if (seen[k]++) next } { print }' $FILES > conf.d/extensions.ini

Проверка, кто реально выполняет PHP на каждом пути, включая прямой запрос в Apache и PATH_INFO:

echo '<?php echo PHP_VERSION, " ", php_sapi_name();' > /usr/share/roundcubemail/_v.php
curl -s -H 'Host: nonexistent.invalid' http://127.0.0.1:8080/webmail/_v.php
curl -sk https://ДОМЕН/webmail/_v.php/x
rm -f /usr/share/roundcubemail/_v.php

Везде должно быть 5.6.40 fpm-fcgi. После этого блок nginx можно снимать.

Два минуса решения: на пути через Apache пропадают ограничения open_basedir из конфигов для mod_php, а roundcube-isp.conf помечен ispmanager как перезаписываемый при обновлении пакета. После обновлений панели стоит проверять, что сокеты не вернулись и что /etc/php-fpm.d/apache.conf не появился заново.

Чек-лист для сервера с ispmanager

Если у вас сервер с ispmanager и вы ещё не уверены, что закрыли PHP2Shell полностью, пройдитесь по списку:

• Все используемые ветки alt-php обновлены, в changelog есть CVE-2026-109618/109619 или Build Date не раньше 21 октября 2026.
• Пакеты isp-php* обновлены, сервисы php-fpm* перезапущены (после смены unit-файла сначала systemctl daemon-reload).
• Нативный PHP ОС обновлён или ничего не обслуживает (проверьте пулы в /etc/php-fpm.d/ и кто подключается к их сокетам).
• Модуль Apache isp-libphp8.so собран после 21 октября, или ни один сайт не работает в режиме «Модуль Apache».
• Roundcube и phpMyAdmin работают на исправленном PHP и через nginx, и через Apache.
• Значения PHP проверены от имени пользователя внутри CageFS, а не от root.
• Скелет CageFS обновлён (cagefsctl --update).
• Временные блоки в nginx сняты, включая строку в дефолтном server в nginx.conf.
• На сайтах с выключенным PHP нет .php-файлов.
• Клиентам объяснено, почему номер версии в панели не изменился.

Главный вывод этой ночи простой: на хостинге с панелью «обновить PHP» означает не один пакет, а пять-шесть разных сборок PHP от трёх поставщиков (апстрим через CloudLinux, ispmanager, дистрибутив), и часть из них обслуживает не сайты, а служебные приложения панели. Полезно заранее знать, какой PHP за каким путём стоит, до того как он понадобится ночью.

Источники

• PHP: Security advisory, 21 Oct 2026
• CloudLinux KB: updated package availability
• CloudLinux blog: Imunify360 Ruleset 8.83
• Red Hat RHSA-2026:87151 (PHP 8.0, RHEL 9)
• ispmanager: PHP settings on CloudLinux
• OpenNet: уязвимость в PHP

Защитите админку WordPress от входа из других стран

Для этого мы сделали бесплатный плагин — он закрывает доступ к панели управления для IP-адресов из стран, которых нет в списке разрешённых.

Что делает плагин

Плагин блокирует доступ к wp-admin и wp-login.php для IP-адресов из стран, которые не входят в список разрешённых. Посетители фронтенда сайта, интернет-магазина и личных кабинетов работают без ограничений — блокировка касается только административной части.

Скачать

block-access-to-admin-by-country.zip

Установка

1. Скачайте zip-архив по ссылке выше
2. В панели WordPress откройте Плагины → Добавить новый → Загрузить плагин
3. Выберите скачанный архив и нажмите Установить, затем Активировать
4. Откройте Настройки → Admin Country Block и укажите разрешённые страны

Настройки

• Allowed countries — коды стран через Enter (например: EE, FI, LV). Только IP из этих стран получат доступ к админке.
• Exception IPs — IP-адреса, которые всегда имеют доступ независимо от страны. Укажите здесь свой IP, чтобы не заблокировать себя.
• Cache TTL — время кеширования результата проверки на один IP-адрес (по умолчанию 24 часа).

Для клиентов Core Hosting

На серверах Core Hosting плагин автоматически использует локальную базу данных MaxMind GeoLite2 — без обращений к внешним сервисам, быстро и надёжно. База обновляется еженедельно в автоматическом режиме. Никаких дополнительных настроек не требуется.

Для сайтов на других хостингах

Плагин использует бесплатный геолокационный API (freeipapi.com). При необходимости можно указать любой другой совместимый API в поле API URL. Результаты кешируются, поэтому количество обращений к API минимально.

Плагин поддерживает автоматическое обновление — новые версии будут появляться в стандартном разделе обновлений WordPress.

Плагин бесплатный и в открытом доступе. Если что-то пойдёт не так при установке или появятся вопросы — обращайтесь в поддержку.

Почему мы вносим изменения?

Наша цель — ваш успех. Чтобы его обеспечить, мы инвестируем в будущее:

1. Новая технологическая платформа: Мы переводим пользователей на новую, более мощную среду веб-хостинга. Это означает более высокую скорость работы сайтов, улучшенную безопасность и стабильность.
2. Больше ресурсов: Мы значительно увеличили лимиты дискового пространства и добавили новые профессиональные инструменты (например, SSH-доступ и поддержку Node.js) в популярные пакеты.
3. Стандартизация и прозрачность: Мы обновляем и унифицируем нашу ценовую политику, чтобы сделать ее более понятной и справедливой для всех клиентов. Эти изменения также совпадают с плановым повышением ставки НСО в Эстонии с 22% до 24%.

Что нового в пакетах?

Наши пакеты Simple, Basic и Pro стали еще мощнее. Вот ключевые улучшения:

Обновленные цены с 1 июля 2025 года

Новые цены отражают возросшую ценность пакетов и измененную ставку НСО.

К ценам добавляется НСО 24%.

Что это значит для существующих клиентов?

• Цены: Новые цены вступят в силу с 1 июля 2025 года. Если вы уже пользуетесь услугами по этим ценам, для вас ничего не изменится. Для всех предоплаченных периодов старые цены действуют до их окончания.
• Миграция: Мы плавно перенесем всех пользователей пакетов Simple, Basic и Pro на новую платформу до мая 2026 года. Мы позаботимся обо всех технических деталях, чтобы переход был для вас незаметным.

Мы уверены, что эти обновления помогут вам достигать новых высот. Спасибо, что вы с нами!

Команда Core.Hosting

Гибкость без скрытых доплат

Не все сайты работают на последних версиях PHP, и это нормально. У нас вы можете свободно использовать как современные, так и устаревшие версии PHP: от 5.2 до 8.4 — без дополнительной платы. Это особенно важно, если у вас есть старые проекты, которые нужно просто поддерживать в рабочем состоянии.

Безопасность сайтов — по умолчанию

Мы включили антивирус ImunifyAV+ во все тарифы. Это решение автоматически проверяет и очищает сайты от вредоносного кода, снижая риск взлома и сбоев.

Установка CMS и скриптов — в пару кликов

С нашим автоустановщиком вы можете запустить WordPress, Joomla, OpenCart и другие популярные решения буквально за пару минут — всё просто и интуитивно.

Конструктор сайтов Site.pro в каждом тарифе

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

Бесплатный перенос сайта и почты

Меняете хостинг? Мы перенесем ваш сайт и почту с другого провайдера бесплатно. Всё будет настроено и проверено — вам не нужно вникать в технические детали.

Поддержка, которая отвечает

Наша команда работает с 9:00 до 19:00 и действительно помогает — без ботов и шаблонных отписок.

Core.Hosting — это не просто набор услуг. Это надёжный партнёр, который не усложняет, а помогает. Если вы задумываетесь о смене хостинга — попробуйте нас. Начать легко.

Подробнее: https://core.eu/ru/hosting/shared/ или https://core.hosting

Расскажем вам о том, как создать свой идеальный веб-ресурс на хостинге CORE.

ISP Manager — панель управления хостинга CORE. Она позволяет в пару кликов установить популярные CMS, либо создать сайт с помощью бесплатного конструктора Site.pro.

Удобства работы с ISP Manager

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

Многофункциональность
Панель управления позволяет управлять не только веб-сайтами, но и почтовыми ящиками, базами данных, доменными именами и другими ресурсами. Это делает ISP Manager универсальным инструментом для администрирования.

Быстрая установка популярных CMS
ISP Manager упрощает работу с установкой различных систем управления содержимым (CMS), включая:

• WordPress: Легкий в использовании инструмент для создания блогов и сайтов.
• Drupal: Мощная система для создания сложных и многофункциональных сайтов.
• Joomla: Идеально подходит для создания социальных сетей и корпоративных порталов.
• PrestaShop и Magento: Отличный выбор для создания интернет-магазинов с множеством функций.

Установка этих CMS осуществляется всего за несколько кликов, благодаря встроенным мастерам и автоматическим настройкам.

Чтобы установить скрипт для сайта в ISP Manager:

1. В Основном меню выберите Сайты.
2. В открывшейся форме выберите сайт, для которого необходимо установить скрипт, и нажмите на кнопку CMS.

Установку можно выполнить с параметрами по умолчанию (кнопка «Быстрая установка») или настроить параметры самостоятельно (кнопка «Установить»).

Возможности бесплатного конструктора сайтов Site.pro

Теперь поговорим о конструкторе сайтов Site.pro, который является отличным дополнением к ISP Manager.

Простота использования
Site.pro предлагает интуитивно понятный интерфейс «перетаскивания», что позволяет пользователям без технических навыков создать профессиональный сайт за короткое время.

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

Адаптивность
Все созданные сайты автоматически адаптируются под мобильные устройства, что гарантирует удобство для пользователей.

Интеграция с различными сервисами
Site.pro поддерживает интеграцию с популярными сервисами и инструментами, включая социальные сети, платежные системы и аналитические инструменты.

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

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