Rails закрыл критическую уязвимость в Active Storage: баг с идентификатором CVE-2026-66066 позволял без авторизации читать произвольные файлы на сервере. Дальше цепочка становилась заметно неприятнее: утечка secret_key_base, ключей к облачным сервисам и других секретов могла открыть дорогу к удалённому выполнению кода или боковому перемещению по инфраструктуре.
Для команд, у которых Rails-приложение принимает изображения от внешних пользователей, это не абстрактный CVE из рассылки, а срочная задача на проверку версий, обновление и ротацию секретов. Особенно если приложение работает на libvips и использует стандартные настройки Rails 7+.
Что именно сломалось в связке Rails и libvips
Проблема затронула обработку вариантов изображений в Active Storage. По данным Rails Security Advisory, Active Storage не отключал в libvips операции, которые сама библиотека помечает как небезопасные для недоверенного содержимого. Если приложение принимало изображение от пользователя и потом строило из него вариант, атакующий мог подсунуть специально подготовленный файл и добиться чтения произвольных данных из файловой системы.
Критичный нюанс в том, что для атаки не нужен отдельный этап с логином. Достаточно, чтобы сервис принимал загрузку картинок от недоверенного пользователя. В advisory Rails отдельно пишет, что под удар попадали и переменные окружения процесса, а это уже прямой путь к secret_key_base, ключам S3, токенам внешних сервисов и учётным данным к базе.
Именно поэтому в официальном описании фигурирует не только чтение файлов, но и риск RCE. Сам баг даёт доступ к секретам, а уже украденные секреты могут стать следующей ступенью для захвата приложения или соседних систем.
Какие версии затронуты и где уже есть патч
Исправления вышли в версиях 7.2.3.2, 8.0.5.1 и 8.1.3.1. Уязвимыми считались ветки до 7.2.3.2, 8.0.x до 8.0.5.1 и 8.1.x до 8.1.3.1.
С Rails 6 ситуация чуть лучше, но не настолько, чтобы расслабиться. По данным исследователей Ethiack, ветки 6.0.0-6.1.7.10 затрагивались только при нестандартной настройке Active Storage: обычная конфигурация Rails 6 этой атаке не подвержена. Но для старых внутренних систем это всё равно повод проверить, не включали ли libvips вручную несколько лет назад и не забыли ли об этом в документации.
Отдельно стоит помнить, что в группу риска попадали приложения, где для Active Storage был выбран variant_processor = :vips. Пользователи ImageMagick этим конкретным вектором не затронуты.
Почему одного обновления мало
Rails рекомендует не ограничиваться установкой патча. Если приложение могло быть уязвимо, все секреты, доступные процессу, нужно считать потенциально скомпрометированными. В первую очередь это касается secret_key_base, мастер-ключа Rails, содержимого credentials.yml.enc, ключей Active Storage, доступа к базе и токенов сторонних сервисов.
Это неприятная, но логичная часть инцидента. Патч закрывает дыру на будущее, но не отменяет уже возможную утечку. Проще говоря: заменить код и оставить старые ключи — всё равно что сменить замок, но не отозвать потерянный пропуск.
Есть и временная мера, если система уже работает на libvips 8.13+, а обновить Rails прямо сейчас нельзя. Rails советует включить переменную окружения VIPS_BLOCK_UNTRUSTED или вызвать Vips.block_untrusted(true) при использовании ruby-vips 2.2.1+. Но это именно отсрочка, а не полноценная замена обновлению. Для libvips ниже 8.13 такого обходного пути нет.
Раскрытие деталей ускорили публичные PoC
Первый advisory Rails опубликовал 29 июля 2026 года и тогда сознательно не раскрыл технические детали атаки. Изначально команда планировала сделать это не позднее 28 августа 2026 года. Но уже 31 июля 2026 года Rails выпустил отдельный разбор атаки и инструменты для форензики: исследователи успели быстро разобрать вектор и опубликовать proof-of-concept.
Это важная правка по фактам: окно тишины уже закрылось. На момент публикации деталей админам предлагали не только ставить патч, но и проверять, была ли система уязвима, а также искать следы эксплуатации в данных Active Storage и объектном хранилище.
Что это меняет для рынка
Для русскоязычных команд вывод довольно приземлённый: пользовательская загрузка файлов снова оказалась одной из самых дорогих по риску зон в веб-разработке. Если сервис на Rails принимает аватары, превью, вложения или любые изображения извне, нужно проверить не только версию фреймворка, но и весь контур вокруг обработки медиа: библиотеку, секреты процесса, изоляцию воркеров и журналирование. Для продуктовых команд и аутсорса это ещё один аргумент не держать обработку изображений в одном доверенном контуре с ключами от базы и облака.
Следующий логичный шаг для рынка — не только ставить патч, но и выносить обработку медиа в более жёстко изолированные процессы, потому что история с CVE-2026-66066 бьёт не по экзотике, а по довольно типовой конфигурации Rails-приложения.
Оригинал: advisory Rails на GitHub. Детали атаки и инструменты для форензики: Rails Security Announcements.