Rails выпустил экстренные обновления для критической уязвимости в Active Storage: при неудачной конфигурации злоумышленник мог читать произвольные файлы на сервере через обработку загруженных изображений. Проблема опасна не только утечкой файлов: из переменных окружения и конфигурации можно вытащить secret_key_base, ключи облачных хранилищ и другие секреты, а дальше уже добраться и до удалённого выполнения кода.
Речь идёт об advisory GHSA-xr9x-r78c-5hrm от 29 июля 2026 года. На странице advisory Rails указывает оценку 9,5 по CVSS v4. Публичный CVE в advisory не указан, поэтому прежний номер CVE-2026-66066 из текста нужно убрать: он не относится к этой истории.
Какие версии затронуты
Под угрозой приложения на Active Storage, если они используют libvips для обработки изображений и принимают загрузки от недоверенных пользователей. Затронуты версии activestorage ниже 7.2.3.2, ветка 8.0.x до 8.0.5.1 и ветка 8.1.x до 8.1.3.1.
Здесь важная деталь: проблема связана не с «ручным» ресайзом по запросу администратора, а с самой логикой обработки вариантов изображений. Rails поясняет, что отдельный вызов генерации вариантов не нужен: если приложение показывает такие варианты, этого уже достаточно для атаки.
Почему баг оказался таким неприятным
Корень проблемы в том, что Active Storage не отключал в libvips так называемые unfuzzed operations — небезопасные обработчики форматов, которые не рассчитаны на недоверенный ввод. Если атакующий загружал специально подготовленный файл и заставлял приложение его обработать, он мог получить содержимое произвольных файлов, доступных процессу Rails.
А это уже не абстрактная «утечка данных». В окружении Rails часто лежат ключи к S3-совместимым хранилищам, доступ к базе, токены внешних сервисов и мастер-ключи. Один удачный запрос — и инцидент быстро превращается из бага в полноценный компромисс инфраструктуры.
Что нужно сделать администраторам
Базовый шаг один: обновиться до 7.2.3.2, 8.0.5.1 или 8.1.3.1. Одновременно Rails рекомендует поднять libvips как минимум до версии 8.13. Для систем с более старым libvips нормального обходного пути нет: проект прямо пишет, что в такой конфигурации безопасно закрыть проблему нельзя без отказа от зависимости.
После обновления работа не заканчивается. Если приложение могло быть уязвимо, стоит менять secret_key_base, RAILS_MASTER_KEY, содержимое credentials.yml.enc, ключи облачных хранилищ, пароли к базе и токены внешних сервисов. Патч закрывает дыру, но не отменяет уже украденные секреты.
Что это значит для рынка
Для команд в России и СНГ история вполне прикладная. Rails давно живёт не только в стартапах, но и во внутренних кабинетах, маркетплейсах, CRM и сервисах с личными данными. Если проект принимает пользовательские изображения и использует :vips, откладывать обновление не стоит: здесь цена промедления измеряется не баг-репортом, а ротацией всей секретной обвязки приложения.
Следующий шаг очевиден: обновить стек, проверить использование libvips и поднять ревизию всех секретов, к которым у процесса Rails был доступ.
Источник: advisory Rails на GitHub.