Мы обновили наши инфраструктурные решения и закрыли критические уязвимости CVE-2026-109618 и CVE-2026-109619 (известные как PHP2Shell).
Это серьёзные проблемы в самом ядре PHP, которые позволяют неавторизованному атакующему выполнять код на сервере. Исправления уже применены на нашей стороне.
Рекомендуем обновить ваши VPS и перевести веб-проекты на PHP 8.2 и выше (актуальные патч-версии: 8.2.35+, 8.3.36+, 8.4.27+ или 8.5.12+). Старые ветки PHP (7.x, 8.0, 8.1 и ниже) уже не получают полноценной поддержки, и риски для них значительно выше. Обновление PHP на VPS и перевод проектов на современные версии — самый надёжный способ закрыть эти уязвимости надолго.
Если полное обновление PHP и перевод проектов пока невозможны, то ниже представлены временные меры, которые снижают риск. Они не заменяют обновление, но помогают, пока вы готовите миграцию. Применяйте их на уровне конфигурации сервера/пула (не через ini_set() или .user.ini).
Для CVE-2026-109618 (повреждение памяти при нехватке памяти):
- Задайте memory_limit = -1 так, чтобы приложение не могло его переопределить (через php_admin_value в пуле PHP-FPM или в конфигурации Apache). Убедитесь, что нигде не стоит конечный лимит.
- Ограничьте размер POST-запросов: post_max_size = 8M (если загрузка файлов не нужна) или 32M (если нужна). upload_max_filesize должен быть меньше post_max_size.
- По возможности ограничьте на уровне веб-сервера или прокси размер декодированного запроса, количество полей, частей multipart, заголовков и глубину вложенности. Лимиты должны работать и для запросов без корректного Content-Length.
- Используйте лимиты памяти контейнера/cgroup так, чтобы убивался только проблемный воркер. Не применяйте RLIMIT_AS / RLIMIT_DATA — они могут спровоцировать уязвимый сценарий.
Для CVE-2026-109619 (устаревшее глобальное состояние):
- Установите session.upload_progress.enabled = 0 и перезапустите все воркеры. Делайте это в php.ini, конфигурации пула FPM или сервера (до начала разбора запроса).
- На PHP 8.5 дополнительно установите fatal_error_backtraces = 0 и перезапустите воркеры.
- Уберите некорректные или устаревшие настройки, которые выдают предупреждения до инициализации. Скрытие ошибок через error_reporting, display_errors или @ не помогает.
- Устраните фатальные ошибки и таймауты, до которых может дотянуться атакующий (в коллбэках, обработке загрузок/импорта, очистке).
Дополнительно можно рассмотреть pm.max_requests = 1 в пуле FPM — это разрывает возможность переиспользования одного воркера между запросами.
Безопасность ваших проектов — наш приоритет!
