Разработчики Ruby on Rails закрыли критическую уязвимость CVE-2026-66066 с оценкой 9,5 балла по CVSS. Ошибка жила в Active Storage и позволяла неаутентифицированному атакующему загрузить специально подготовленное изображение, а затем прочитать файлы и секреты, доступные процессу приложения.

Какую проблему решаем

Речь идёт не просто о сбое обработки картинки. Уязвимость открывала путь к утечке переменных окружения, secret_key_base, мастер-ключа Rails, паролей баз данных, токенов облачных хранилищ и API-ключей.

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

Что подготовить

Проверьте, использует ли приложение Active Storage вместе с libvips для обработки изображений и принимает ли загрузки от недоверенных пользователей. Если у вас стоит MiniMagick, эта конкретная проблема вас не затрагивает.

Также посмотрите версии Ruby on Rails. Под ударом оказались ветки 7.0.0–7.2.3.1, 8.0.0–8.0.5 и 8.1.0–8.1.3, а также Rails 6.x, если администратор вручную выбрал Vips как процессор изображений.

Если вам регулярно нужно проверять уязвимости в цепочке поставки и серверных компонентах, держите под рукой и внутренний разбор про как ломают защиту веб-приложений — принцип там один: слабое место часто сидит не в основном коде, а в связке библиотек и настроек.

Пошаговые действия

  1. Обновите Ruby on Rails до 7.2.3.2, 8.0.5.1 или 8.1.3.1.
  2. Проверьте, установлен ли libvips версии 8.13 или новее.
  3. Если используете ruby-vips, поставьте версию не ниже 2.2.1.
  4. Пересмотрите все загрузки изображений от внешних пользователей и временно ограничьте их, если это возможно по бизнес-логике.
  5. Считайте скомпрометированными все секреты, которые мог прочитать процесс приложения.
  6. Замените secret_key_base, мастер-ключ, пароли баз данных, ключи Active Storage и сторонние токены.

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

Как проверить себя

Сначала сверьте версии зависимостей в Gemfile.lock и на сервере. Затем проверьте, какой обработчик изображений реально задействован в продакшене: именно тут у многих и возникает ложное чувство безопасности.

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

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

Что делать, если не получилось

Если обновиться сразу нельзя, разработчики и исследователи советуют включить VIPS_BLOCK_UNTRUSTED или вызвать Vips.block_untrusted(true). Это не отменяет риск полностью, но снижает шанс, что обработчик примет опасный контейнер за обычную картинку.

И всё же это временная мера. После неё всё равно нужно поставить исправления, сменить секреты и проверить журналы на подозрительные загрузки.

Чек-лист

  • Проверить, использует ли проект Active Storage и libvips
  • Сверить версии Rails, libvips и ruby-vips
  • Обновить Ruby on Rails до исправленных релизов
  • Сменить secret_key_base, мастер-ключ и пароли БД
  • Отозвать старые токены и ключи интеграций
  • Ограничить загрузку файлов от внешних пользователей
  • Временно включить VIPS_BLOCK_UNTRUSTED, если обновление откладывается
  • Протестировать обработку изображений после патча
Поделиться: