Две уязвимости в Moodle позволяют выкачивать данные из базы платформы и скрывать чужой вход в учётную запись. Исправления вышли 22 сентября 2026 года. Moodle - система управления обучением, на которой держатся школьные, вузовские и корпоративные учебные порталы. Закрытые сборки получили ветки 5.2.3, 5.1.7, 5.0.10 и 4.5.14. Всё, что старше, включая неподдерживаемые выпуски, остаётся без исправлений.
Детали уязвимостей
Первую уязвимость нашли в проверке условий доступности профиля. Этот механизм решает, кто из участников курса видит профиль человека и какие его поля остаются открытыми. Входные данные проверяются недостаточно строго, поэтому в запрос к базе можно подставить собственный SQL-код. Внедрение SQL-кода (SQL-инъекция) здесь слепое. Результат запроса на странице не появляется, так что атакующий задаёт базе вопросы по одному и читает ответы по косвенным признакам: по задержке отклика или по разнице в поведении формы. Извлекать данные приходится медленно, символ за символом. Зато такой способ не оставляет следов в виде выведенного на экран текста, а значит, его труднее заметить при беглом просмотре журналов.
Права на такую атаку есть не у всякого. Проверку доступности профиля сервер выполняет для всех ролей, но воспользоваться слабым местом может преподаватель, администратор и другой привилегированный пользователь. Для учебной организации это означает риск внутренних злоупотреблений. Одновременно растёт ущерб от кражи одной учительской учётной записи. Курсы ведут внешние преподаватели и приглашённые специалисты, а их доступы часто создают массово и отзывают с задержкой. Через инъекцию можно добраться до хешей паролей, личных данных студентов, внутренней переписки и оценок. Возможности записи и удаления записей зависят от прав учётной записи и настроек самой базы данных. Находку передал исследователь Винсент Шнайдер, разработчики отнесли проблему к серьёзному уровню риска.
Вторая уязвимость обходит механизм уведомлений о входе. Платформа рассылает пользователю письмо, когда в его аккаунт входят с нового устройства или из нового места, и указывает время, браузер и адрес. Обход отключает это оповещение, поэтому владелец ничего не замечает. Действующие имя пользователя и пароль при этом всё равно требуются. Сам по себе этот промах незначителен. В связке с первой уязвимостью он заметно снижает шансы обнаружить вторжение. Злоумышленник, добывший учётные данные через фишинг, атаку полным перебором или утечку с другого сайта, входит в аккаунт и не оставляет явного сигнала для его хозяина. Нашёл проблему Брендан Хейвуд.
Обе уязвимости затрагивают четыре ветки Moodle: 5.0 до 5.0.9, 5.1 до 5.1.6, 5.2 до 5.2.2 и все выпуски вплоть до 4.5.13. Идентификаторы CVE (единый реестр уязвимостей) на момент публикации бюллетеней ещё не присвоены. Сведений об эксплуатации в реальных атаках разработчики не приводят. Между тем Moodle часто разворачивают на собственных серверах, а обновляют такие установки неспешно. Администраторы вузов и колледжей нередко откладывают работы до конца семестра или до каникул. Из-за этого окно между выходом исправления и его установкой растягивается на недели и месяцы. Число преподавателей на крупной платформе измеряется сотнями, и каждая такая учётная запись становится возможной точкой входа. Для хостинговых поставщиков, которые держат Moodle для десятков клиентов, картина сложнее: там одна ошибка в общей конфигурации отзывается сразу на всех арендаторах.
Исправленные сборки - 5.2.3, 5.1.7, 5.0.10 и 4.5.14. Владельцам более старых выпусков разработчики предлагают перейти на поддерживаемую ветку, поскольку исправлений для них не будет. Если обновление приходится отложить, разумно сократить число учётных записей с расширенными правами и просмотреть журналы входов за последние месяцы. Помогает подробное журналирование обращений к базе данных: слепая инъекция выдаёт себя повторяющимися запросами с нарастающей задержкой. Ещё одна мера - ограничить сетевой доступ к базе, чтобы подключиться к ней могли только серверы приложения. Отдельно стоит подумать о двухфакторной аутентификации для преподавателей и администраторов. Тогда одного украденного пароля для входа не хватит, а обход уведомлений потеряет часть своей ценности. Если есть подозрения, что чужие руки уже добрались до аккаунта, пароли привилегированных пользователей лучше сменить и заодно проверить, какие расширения установлены на платформе.
Образовательные платформы хранят много персональных данных, но редко попадают в поле зрения служб защиты. Роли здесь устроены так, что преподаватель распоряжается чужими профилями и получает больше прав, чем обычный пользователь. Поэтому недостаточно строгая проверка на одном участке кода превращается в доступ к хранилищу данных целой организации. Разработчики Moodle закрыли обе уязвимости до появления сообщений о реальных атаках, и у администраторов есть время на спокойное обновление. Держать старые ветки ради экономии ресурсов в такой ситуации неразумно. Устаревшие выпуски остаются без исправлений, а вместе с ними под ударом оказываются оценки, переписка и личные данные тысяч студентов.
Ссылки
