Специалистам, обслуживающим сайт компании, нужно немедленно проверить среду PHP и установить исправления безопасности. В сообщении от 21 октября, 23:00 по латвийскому времени, CERT.LV указала примерно 6000 потенциально затронутых ресурсов Латвии и автоматизированные попытки атак. На тот момент сообщений об успешных атаках не было; речь не идёт о количестве взломанных сайтов.
В чём проблема и каких компаний она касается?
Техническое предупреждение касается CVE-2026-109618 и CVE-2026-109619 с оценкой CVSS 9,2. При определённых условиях они позволяют выполнять код на сервере без аутентификации. Проверить нужно сайты, интернет-магазины и клиентские порталы на PHP, в том числе обслуживаемые внешними подрядчиками.
Одна проблема связана с обработкой исчерпания памяти, другая — с сохранением некорректного внутреннего состояния между запросами. Для Apache mod_php продемонстрирована атака до выполнения кода приложения. PHP-FPM также нельзя считать безопасным исключением: конкретная возможность эксплуатации зависит от конфигурации и приложения.
В каких версиях PHP есть исправления?
Разработчики PHP выпустили 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Необходимо установить подходящее для среды исправление. Ветки PHP 8.1 и более ранние не получают регулярную поддержку проекта; отдельные поставщики предоставляют перенесённые исправления. Поэтому более старый отображаемый номер версии нужно проверять вместе с уведомлением поставщика о безопасности.
Пять вопросов специалистам, обслуживающим сайт
Практический список редакции помогает превратить общий ответ «всё в порядке» в проверяемый результат:
- Какие наши системы проверены? Перечислите основной сайт, магазин, поддомены и клиентский портал. Проверка одного сайта не заменяет учёт остальных.
- Что подтверждает устранение обеих CVE? Запросите версию пакета PHP, ссылку на исправление поставщика и время установки. Подтверждения обновления только плагинов CMS недостаточно.
- Действует ли исправление во всей обслуживающей среде? Запросите подтверждение по процессам обработки веб-запросов и всем серверам. Одна проверка в командной строке может не отражать состояние всей серверной среды.
- Работает ли сайт после изменений? Проверьте вход, контактную форму, создание заказа и загрузку файлов, если она предусмотрена. Зафиксируйте исполнителя и время проверки.
- Кто проверяет признаки возможного инцидента? Определите, кто анализирует подозрительные события и кому сообщает результаты. Неясное распределение ответственности между программистом и хостингом не должно оставлять эту работу невыполненной.
Почему обновление не заменяет проверку возможного инцидента?
Команда безопасности Amazon сообщила о попытке эксплуатации, замеченной в её серверах-ловушках 17 октября. Это обосновывает проверку и более раннего периода. Специалистам следует изучить журналы, неожиданные изменения файлов и активность процессов; установка исправления сама по себе не доказывает отсутствие предшествующих событий.
Руководитель может запросить короткую итоговую запись: проверенные системы, установленное исправление, ответственный, результат проверки и оставшаяся работа. Она поможет и при следующем предупреждении, поскольку не придётся заново искать ответственного за каждую систему.
Что делать, если старая система не поддерживает обновление?
Нужно согласовать временное ограничение доступа и конкретный срок исправления либо миграции. Изменение конфигурации и фильтрация не заменяют полноценного исправления. Важны и защита, и план обслуживания заказов и обращений клиентов во время ограничений.
При оценке внешних подрядчиков можно изучить деловые объявления, а для административных задач — услуги для бизнеса. Компетенцию конкретного IT-подрядчика и объём его работ необходимо проверять отдельно.
Комментарии
Комментариев пока нет. Ваш мог бы стать первым!
Добавить комментарий