CVE-2026-103977

Обзор

В версиях FileRise до 3.23.0 неудачные попытки проверки TOTP сохранялись в состоянии PHP-сессии. Счётчик ограничивал попытки в рамках одной сессии, но не сохранялся при создании новых сессий.

Злоумышленник, уже обладающий действующими первичными учётными данными целевой учётной записи, мог перезапустить процесс входа, получить новую сессию с ожидающим входом и восстановить лимит попыток TOTP. Повторение этого процесса позволяло продолжать онлайн-подбор TOTP сверх предусмотренного лимита в пять попыток.

Подробности

Процесс проверки TOTP хранил счётчик неудач в $_SESSION. После пяти неудачных попыток дальнейшие попытки в этой сессии возвращали HTTP 429.

Однако успешное прохождение первичной аутентификации в новой сессии создавало новое состояние ожидающего входа с новым счётчиком неудач TOTP. Таким образом, неудачи TOTP предыдущей учётной записи не переносились.

Проблема также затрагивала другой обработчик TOTP для ожидающего входа, который не применял тот же устойчивый лимит. Поэтому исправление было применено централизованно для всех путей проверки TOTP при ожидающем входе.

Эта проблема классифицируется как CWE-307: Ненадлежащее ограничение чрезмерного числа попыток аутентификации.

Влияние

Для эксплуатации требуется наличие действующих первичных учётных данных целевой учётной записи, например пароля, полученного путём повторного использования учётных данных, фишинга или иной компрометации.

Уязвимость не раскрывает учётные данные и не позволяет немедленно обойти TOTP. Она позволяет продолжать автоматизированный подбор TOTP без устойчивого ограничения на уровне учётной записи. Успешный подбор завершает аутентификацию с привилегиями затронутой учётной записи, потенциально включая привилегии администратора.

Учётные записи без включённого TOTP не затронуты этой конкретной проблемой ограничения частоты второго фактора.

Исправление

FileRise 3.23.0 вводит централизованное постоянное ограничение попыток TOTP:

• Каждая учётная запись ограничена пятью попытками проверки TOTP в течение 15-минутного окна.
• Лимит учётной записи сохраняется между PHP-сессиями и изменениями адреса клиента.
• Более высокий общий лимит по источнику ограничивает попытки, распределённые между учётными записями.
• Попытки резервируются до проверки с использованием заблокированного постоянного состояния.
• Все пути проверки TOTP при ожидающем входе используют один и тот же ограничитель.
• Успешная проверка TOTP очищает бюджет попыток учётной записи.
• Аутентификация по паролю или через поставщика удостоверений не сбрасывает неудачи TOTP.

Существующие учётные записи, секреты TOTP, сессии, установки Docker и конфигурация развёртывания не требуют миграции.

Пользователям следует обновиться до FileRise 3.23.0 или более поздней версии.

Ответ сопровождающего

Спасибо за ответственное раскрытие и подробные шаги воспроизведения.

Мы рассмотрели процесс проверки TOTP и подтвердили основную проблему. Неудачные попытки TOTP ограничивались только счётчиком PHP-сессии в основном фронтенд-эндпоинте проверки. Поэтому повторение успешного шага первичной аутентификации в новой сессии могло восстановить бюджет попыток второго фактора. В ходе проверки мы также выявили другой обработчик TOTP для ожидающего входа, который не применял тот же счётчик попыток, поэтому исправление было применено централизованно для всех путей проверки, а не только для указанного эндпоинта.

Исправление реализовано для FileRise v3.23.0:

• Синтаксически корректные попытки TOTP теперь резервируют попытку из постоянного бюджета на уровне учётной записи до проверки.
• Бюджет учётной записи не зависит от PHP-сессии и адреса клиента, поэтому замена сессии или смена исходных адресов не восстанавливает попытки.
• Более высокий постоянный бюджет на уровне источника ограничивает попытки, распределённые между учётными записями.
• Оба обработчика TOTP для ожидающего входа используют один и тот же ограничитель, охватывая сессии ожидающего входа, созданные через форму, Basic Auth и OIDC.
• Успешная аутентификация по паролю или через поставщика удостоверений больше не сбрасывает бюджет неудач второго фактора.
• Успешная проверка TOTP очищает бюджет учётной записи и удаляет успешный резерв из бюджета источника, поэтому обычные успешные пользователи в общих сетях не накапливают неудачи.
• Состояние попыток использует хешированные идентификаторы учётной записи/источника, блокируемые обновления, атомарную замену файлов, автоматическое истечение срока и обработку с отказом в закрытом режиме, если хранилище ограничителя недоступно или повреждено.
• Успешное использование кода восстановления очищает состояние попыток TOTP учётной записи.

Лимит учётной записи — пять попыток в 15-минутном окне. Общий лимит по источнику намеренно выше — 50 попыток в том же окне, чтобы уменьшить ложные срабатывания для общих сетей. Существующие учётные записи, секреты TOTP, сессии, установки Docker и конфигурация развёртывания не требуют миграции.

---

Credit: Pervin Zahidli (@ech0void ) Ref : https://github.com/error311/FileRise/security/advisories/GHSA-4hfj-6478-5cv7