PHP2Shell: как проверить безопасность учебного портала. Пять вопросов вендору и своему ИТ
Я часто вижу, как корпоративный учебный портал годами работает без видимых проблем. Сотрудники проходят курсы, руководители смотрят результаты, HR запускает аттестации — и кажется, что раз всё открывается, значит, всё в порядке. Но у любой системы есть техническая основа, которую пользователь не видит. И иногда именно там возникает риск.
История с PHP2Shell — как раз такой случай. 21 октября 2026 года разработчики PHP выпустили экстренные исправления двух критических уязвимостей — CVE-2026-109618 и CVE-2026-109619. А 26 октября появились подтверждения успешной эксплуатации. Это уже не абстрактное предупреждение для ИТ-специалистов: вопрос касается и тех, кто отвечает за обучение сотрудников.
Я хочу объяснить, что произошло, почему это важно для HR и какие пять вопросов я бы рекомендовал задать вендору учебной платформы или своей ИТ-команде. Для этого не нужно разбираться в коде. Нужно получить конкретные ответы — с версиями, датами и ответственными.
Что случилось — простыми словами
PHP — это технология, на которой работает множество сайтов и внутренних систем: от корпоративных порталов на Битриксе до сайтов на WordPress и учебных платформ на Moodle. По данным, приведённым в исходных материалах, доля PHP среди русскоязычных сайтов особенно высока. Удобнее всего представить PHP как двигатель: снаружи мы видим сайт или учебный портал, но работает он благодаря тому, что находится «под капотом». 
21 октября разработчики PHP выпустили исправления двух серьёзных ошибок. В описании уязвимостей говорится о возможности выполнить код на сервере через специально сформированный запрос; для атаки не обязательно сначала проходить обычную форму входа в портал. Опасность оценили в 9,2 балла из 10. Отдельно сообщалось о третьей похожей уязвимости — CVE-2026-115560, для которой на момент описания исправления ещё не было.
Для меня в этой истории важны четыре обстоятельства.
Во-первых, проблема не обязательно находится в самой учебной платформе. Если уязвим слой PHP, обновление Moodle или Битрикса само по себе не решает задачу: нужно проверить и обновить PHP на сервере.
Во-вторых, попытки атак начались до публикации исправлений. В исходных материалах указано, что Amazon зафиксировала первую попытку 17 октября, а Cloudflare сообщила о миллионах попыток в первые сутки после публикации исправлений. Автоматические сканеры не выбирают цель по известности компании: они проверяют доступные серверы массово.
В-третьих, речь уже не только о попытках. 26 октября CISA внесла обе уязвимости в каталог активно эксплуатируемых, а исследователи сообщили о случаях выполнения команд на чужих серверах.
В-четвёртых, доступность исправления зависит от версии PHP. Для поддерживаемых веток 8.2–8.5 в исходнике перечислены готовые обновления; для PHP 7.4–8.1 — заплатки в исходном коде или обновления от поставщика ОС; для более старых версий исправлений нет. Именно здесь может скрываться проблема старых порталов, которые годами никто не обновлял. 
Как отреагировали разработчики и регуляторы
Реакция разных участников показывает, что откладывать проверку не стоит. По исходным материалам, 22 октября НКЦКИ рекомендовал объектам критической информационной инфраструктуры срочно обновить PHP, а если это невозможно — ограничить доступ к серверам из интернета и проверить журналы на признаки взлома.
Команда Moodle из предосторожности отключила собственные публичные сайты и призвала владельцев самостоятельных установок проверить PHP. «1С-Битрикс» отдельно пояснил, что проблема относится к PHP: обновление самого продукта через SiteUpdate не заменяет обновления PHP на сервере. Для облачных сервисов обновление обычно находится на стороне поставщика, но заказчику всё равно стоит запросить подтверждение. 
Безопасность Moodle: что проверить кроме версии самой LMS
Если обучение сотрудников организовано на Moodle, я бы начал не с вопроса «безопасна ли Moodle вообще», а с проверки конкретного портала. Одно название платформы не говорит, какие версии компонентов установлены, кто обслуживает сервер и насколько быстро команда выпускает обновления.
В таком портале важно разделять несколько уровней:
- Moodle: версия системы, срок её поддержки, установленные обновления.
- PHP и серверное окружение: используемые версии и наличие необходимых исправлений.
- Плагины и доработки: совместимость с обновлениями и наличие ответственного за сопровождение.
- Доступ и интеграции: администраторы, единый вход, обмен данными с кадровыми системами.
Для проверки рисков, связанных с PHP2Shell, особенно важен серверный уровень. Но обновлять его нужно с учётом требований конкретного выпуска Moodle и установленных расширений. Совместимость следует сверять с документацией: универсального правила «поставить самую новую версию PHP» здесь недостаточно.
Попросите обслуживающую команду подготовить короткую таблицу: 
Последняя строка особенно важна. Наличие резервной копии ещё не означает, что портал получится быстро восстановить. До обновления стоит проверить не только запуск системы, но и вход сотрудников, открытие курсов, прохождение тестов и сохранение результатов.
Сам факт использования Moodle — не основание срочно менять платформу. Сначала нужно понять, можно ли поддерживать конкретную установку в актуальном состоянии и кто будет за это отвечать.
Битрикс24 и «1С-Битрикс»: чем отличается проверка облака и коробки
Если сотрудники попадают в обучение через Битрикс24 или корпоративный портал на «1С-Битрикс», сначала уточните схему размещения. От неё зависит, кому адресовать вопросы об обновлении.
Для облачного Битрикс24 запрос направляют поставщику сервиса: затронута ли используемая инфраструктура, какие действия выполнены и требуется ли что-то от заказчика. Отдельно нужно проверить внешние приложения, сайты и учебные системы, подключённые к облаку: они могут обслуживаться другой командой.
Для коробочного Битрикс24 и сайтов на «1С-Битрикс: Управление сайтом» необходимо определить, кто отвечает за серверное окружение. Это может быть внутренняя ИТ-служба, интегратор или поставщик управляемого хостинга. Сам факт оплаты хостинга ещё не означает, что в услугу входит обновление PHP.
В сообщении «1С-Битрикс» об уязвимостях PHP отдельно указано: обновление продукта через SiteUpdate не заменяет обновления PHP на сервере.
Поэтому вместо одного вопроса «Битрикс обновили?» лучше задать два:
- Обновлены ли сам продукт, его модули и используемые расширения?
- Установлено ли необходимое исправление PHP на всех серверах, которые обслуживают портал?
Если учебная система подключена к Битриксу через единый вход или обмен данными, добавьте третий вопрос: кто проверяет эту связку целиком? Подтверждение безопасности одного компонента нельзя автоматически переносить на всю инфраструктуру обучения.
Почему это касается HR
Представьте портал, который запустили в 2015–2019 годах. Он нужен сотрудникам магазинов, складов и филиалов, поэтому доступен через интернет. Подрядчик, который его создавал, уже сменился, а у внутренней ИТ-команды есть более срочные задачи. Портал продолжает работать — и поэтому обновление легко откладывать.
Но старую платформу не всегда можно просто обновить за один вечер. В исходных материалах отмечено, что некоторые версии Moodle ограничены в выборе PHP, а свежие версии Битрикса требуют более новых веток PHP. Значит, техническая проблема может оказаться не отдельной заплаткой, а проектом обновления всей системы. Конкретную совместимость нужно проверить у поставщика вашей версии.
В учебном портале могут храниться имена сотрудников, должности, результаты тестов и аттестаций, а иногда и документы. Поэтому возможный взлом — это не просто временная недоступность обучения. Это риск для персональных данных, репутации и непрерывности работы компании.
Если вы отвечаете за обучение, не обязательно самостоятельно оценивать код или сервер. Но вы можете и должны задать вопрос: кто подтверждает, что платформа обновлена? Ниже — пять вопросов, с которых я бы начал.
Пять вопросов вендору и своей ИТ-команде
1. На чём работает наш портал и какая версия используется?
Начните с базового: попросите назвать технологию и её версию. Если вы не знаете, на чём построен портал, это нормально. Но поставщик или команда, которая его обслуживает, должны знать.
Хороший ответ звучит конкретно: «Используем PHP 8.3, исправление установлено 21 октября» или «PHP не используется, система построена на другой технологии». Для облачного сервиса поставщик должен уметь сообщить, что именно обновлено.
Тревожный сигнал — «надо уточнить у подрядчика» или «версия старая, но всё работает». Стабильная работа интерфейса ещё не доказывает, что сервер защищён.
2. Когда установили исправление и чем это подтвердить?
Фразы «у нас всё обновлено» недостаточно. Попросите дату, время, имя ответственного и подтверждение — например, запись в журнале изменений или заявку на работы. Для старых версий отдельно уточните, откуда взяли исправление: от поставщика операционной системы, из расширенной поддержки или собрали самостоятельно.
Тревожный сигнал — перенос на неопределённое «плановое окно», ожидание без срока или уверенность, что старая версия не затронута только потому, что она старая.
3. Проверяли ли, не проник ли кто-то на сервер, и за какой период?
Установка исправления закрывает известную уязвимость, но сама по себе не отвечает на вопрос, успел ли кто-то воспользоваться ею раньше. Поэтому после обновления важно проверить журналы сервера и другие признаки компрометации.
Попросите указать, за какой период проверяли журналы, какие именно проверки провели и где зафиксирован результат. В исходном материале предлагается начинать как минимум с 17 октября. Если журналы не сохранились или ответ звучит как «атак не было» без описания проверки, это повод разобраться подробнее.
4. Что будет, если исправление нельзя поставить немедленно?
Устаревшая платформа может быть несовместима с новой версией PHP, а миграция требует времени. Важно заранее понимать, как компания снижает риск в этот период. По исходным рекомендациям, если обновить систему невозможно, следует рассмотреть временное ограничение доступа к серверу из интернета, вплоть до отключения.
Хороший ответ — это понятный план: кто принимает решение, как быстро его выполняют, какие временные меры применяют и когда завершат обновление. Дополнительные меры защиты не заменяют исправление уязвимости.
5. Кто отвечает за обновления и как быстро он реагирует?
У облачного сервиса обычно отвечает поставщик. У решения, установленного на собственных серверах, ответственность должна быть закреплена в договоре и внутренних процессах. У заказной системы иногда обнаруживается неприятная пустота: разработчик уже не работает с компанией, а обновления базовых технологий никто не считает своей задачей.
Попросите назвать ответственную команду и срок реакции на критические уязвимости. В договоре сопровождения должны быть описаны не только исправления ошибок в интерфейсе, но и обновление базовых компонентов. Также стоит проверить срок поддержки используемой версии PHP и заранее запланировать переход, если поддержка заканчивается.
Отдельно я бы попросил ИТ объяснить, открыт ли портал в интернет напрямую и что стоит перед сервером. Александр Краснопрошин обращает внимание на важный принцип: доступность портала из интернета сама по себе не означает ошибку, но требует соответствующей защиты и понятного плана действий на случай, если обновление невозможно.
Порталы для распределённого персонала обычно доступны из интернета, и это нормально. Но тогда перед сервером должна стоять защита, которая отсеивает подозрительные запросы до того, как они дойдут до портала. А если обновить портал невозможно, доступ из интернета нужно временно закрыть — так и рекомендовал регулятор, даже ценой простоя.Александр Краснопрошин, руководитель программной разработки платформы Эквио
Важное уточнение: это общий ориентир для оценки инфраструктуры, а не описание защитных средств, используемых в Эквио. Ограничения частоты запросов и списки разрешённых IP-адресов сами по себе не следует считать защитой от PHP2Shell.
Если ответы не устраивают
Я бы действовал поэтапно.
Сначала попросил бы ИТ оценить необходимость временно ограничить доступ к порталу из интернета, если исправление ещё не установлено. Это решение нужно принимать с учётом рекомендаций специалистов и влияния на работу сотрудников.
Затем добился бы конкретного плана обновления: срок, ответственный, подтверждение выполнения и проверка журналов после установки исправления.
Если система настолько старая, что обновить её безопасно нельзя, вынес бы вопрос на уровень бизнеса. Сравните стоимость миграции и временной остановки обучения с потенциальными последствиями инцидента. Если никто не отвечает за обновления сегодня, проблема, скорее всего, не ограничивается PHP2Shell.
Альтернатива Moodle для компании: когда обновлять, а когда менять платформу
После новости о критической уязвимости легко принять эмоциональное решение: отказаться от текущей системы и выбрать другую. Я бы не советовал начинать с этого. Переезд сам по себе не гарантирует безопасность, а смена технологии не отменяет необходимость обновлений.
Сначала сравните два сценария: сопровождение существующего портала и переход на другую LMS. 
Если вы рассматриваете альтернативу Moodle, сравнивайте не только стоимость лицензии или подписки. В расчёт должны войти инфраструктура, сопровождение, обновления, интеграции, перенос материалов и время команды обучения.
Перед выбором новой платформы составьте перечень того, что необходимо сохранить:
- учебные материалы и исходники курсов;
- вопросы, тесты и правила оценки;
- пользователей и структуру подразделений;
- назначения и траектории обучения;
- историю прохождений, результаты аттестаций и сертификаты;
- интеграции с кадровой системой и корпоративным входом.
Не все данные переносятся автоматически. Даже если обе платформы поддерживают SCORM, это не гарантирует перенос истории обучения, всех настроек курса и результатов тестирования.
Практичный первый шаг — пилотная миграция на ограниченном наборе данных. Перенесите типовой курс, сложный тест и небольшую группу пользователей, проверьте отчётность и только после этого оценивайте сроки полного перехода.
Что сделали в Эквио
Для меня важно не просто говорить о безопасности, а показывать, как команда действует при появлении критической уязвимости. 21 октября 2026 года мы работали по следующему плану: 
Именно скорость обновления — ключевой факт, который мы можем показать по этой хронологии. Результат проверки журналов следует описывать в публикации только в пределах периода, который действительно проверила команда.
Вопросы и ответы
У нас облачная система обучения. Нужно ли что-то делать?
Запросите у поставщика ответы хотя бы на первые три вопроса: какая технология используется, когда установлено исправление и проверяли ли следы возможного взлома. Для облачного сервиса у вендора должны быть конкретные даты и понятное объяснение, что сделано.
Мы обновили Moodle или Битрикс до последней версии. Этого достаточно?
Не обязательно. PHP2Shell связана с PHP, поэтому нужно отдельно подтвердить версию PHP и установку исправления на сервере. Обновление самой платформы не следует считать автоматическим подтверждением обновления PHP.
Наш портал не использует PHP. Нас это касается?
Непосредственно эта уязвимость относится к PHP, но стоит уточнить, нет ли рядом других систем на этой технологии: корпоративного портала, форм или страниц, через которые сотрудники попадают в обучение. Также полезно понять, кто отвечает за общую инфраструктуру и реагирование на инциденты.
Можно ли обойтись настройками и не обновляться?
Временные меры могут снижать риск, но не заменяют полноценное исправление уязвимости. Если быстро обновиться нельзя, обсудите с ИТ ограничение доступа и план перехода на поддерживаемую версию.
Портал старый, обновлять его некому. Что делать?
Не оставляйте его доступным из интернета без оценки риска. Обсудите с ИТ временное ограничение доступа и план миграции. Заплатки для старых версий тоже требуют ответственного специалиста и понятного процесса сопровождения.
Главный итог
PHP2Shell напомнила мне о простой вещи: безопасность системы определяется не только тем, насколько хорошо она работает сегодня, но и тем, есть ли у неё ответственный владелец и процесс обновления. В одной компании исправление ставят в течение нескольких часов и проверяют, не было ли попыток взлома. В другой обновление может месяцами ждать своего часа, потому что за него никто не отвечает.
Если вы отвечаете за обучение, не нужно становиться специалистом по PHP. Достаточно задать пять вопросов из этой статьи и попросить конкретные ответы. Это поможет понять, кто следит за вашим учебным порталом и что произойдёт, когда появится следующая критическая уязвимость.
Если хотите разобраться, как устроены обновления и защита в Эквио, напишите нам — покажем на примере вашей инфраструктуры.
Автор: Алексей Вагин — генеральный директор компании Эквио, эксперт в области дистанционного и корпоративного обучения