Ruby on Rails выпустил исправления для критической уязвимости CVE-2026-66066 в Active Storage с оценкой 9,5 балла по CVSS. Неаутентифицированный злоумышленник может отправить специально подготовленное изображение и получить чтение произвольных файлов, доступных рабочему процессу Rails. Ошибка возникла на границе доверия между Active Storage и библиотекой обработки изображений libvips: Rails передавал недоверенное вложение операциям, которые нельзя безопасно применять к враждебным данным.
Через такую брешь могут утечь переменные окружения Rails, secret_key_base или SECRET_KEY_BASE, мастер-ключ Rails, расшифрованные учетные данные приложения, имена пользователей и пароли баз данных, ключи облачных хранилищ и сервисов Active Storage, API-токены и токены сторонних служб. Дальнейшие последствия зависят от содержимого сервера и прав найденных реквизитов. Удаленное выполнение кода, доступ к базам данных, облачным сервисам, хранилищам и другим связанным средам возможны, но не возникают автоматически после чтения файла.
Риск появляется при сочетании четырех условий: приложение использует Active Storage, обрабатывает изображения через Vips/libvips, принимает загрузки от недоверенных пользователей, а конкретная сборка libvips содержит пригодную для атаки операцию. Начиная с load_defaults 7.0 Rails выбирает Vips; более поздние наборы настроек сохраняют этот выбор. Отдельная публичная точка для изменения размера или создания миниатюр не нужна. Формулировка Rails однозначна: «Создание вариантов не является отдельным требованием». Публичный патч показывает опасную передачу вложений как в анализаторе Vips, так и в преобразователе Vips. Приложения с MiniMagick этому конкретному пути атаки не подвержены.
Исследователи Ethiack и GMO Flatt Security отнесли к затронутым версиям Rails 7.0.0–7.2.3.1, 8.0.0–8.0.5 и 8.1.0–8.1.3. Ветка Rails 6 уязвима в диапазоне 6.0.0–6.1.7.10 лишь тогда, когда Active Storage явно настроен на Vips, поскольку в Rails 6 этот процессор не использовался по умолчанию. Rails Security Team подтвердил точность указанных исследователями диапазонов. Официальное уведомление охватывает находящиеся на поддержке Rails 7.2, 8.0 и 8.1. Rails 7.1 и более ранние выпуски уже сняты с поддержки и не получат обратных исправлений; их владельцам требуется переход как минимум на Rails 7.2.3.2.
По данным Ethiack, переданным The Hacker News, необходимые библиотеки по умолчанию присутствуют в Debian, Ubuntu и создаваемых Rails средах Docker, поэтому такие конфигурации попадают в зону риска. В других дистрибутивах Linux и базовых образах контейнеров нужной библиотечной поддержки может не оказаться. Само присутствие номера Rails в уязвимом диапазоне еще не означает, что приложение можно атаковать: необходимы Vips, прием чужих изображений и доступная опасная операция в установленной сборке libvips.
libvips содержит множество загрузчиков, средств сохранения и других операций с файлами и изображениями, часть которых опирается на сторонние библиотеки. Некоторые операции помечены как «не прошедшие фаззинг» и «недоверенные», то есть их нельзя считать безопасными при разборе данных от неизвестного отправителя. Active Storage прежде не блокировал такие функции, и подготовленная загрузка могла заставить обработчик прочитать файл с правами процесса Rails. Исправление при запуске Active Storage вызывает Vips.block_untrusted(true). Защищенные выпуски: Rails 7.2.3.2, 8.0.5.1 и 8.1.3.1; дополнительно нужны libvips 8.13 или новее и, если установлен пакет ruby-vips, ruby-vips 2.2.1 или новее.
Если Rails пока обновить нельзя, при libvips 8.13+ следует задать VIPS_BLOCK_UNTRUSTED, а при ruby-vips 2.2.1+ вызвать Vips.block_untrusted(true). Старые выпуски libvips не умеют блокировать нужный класс опасных операций: библиотеку придется обновить либо удалить из приложения. Переход на MiniMagick закрывает именно Vips-зависимый путь, но не заменяет установку исправлений и проверку безопасности. После обновления необходимо сменить secret_key_base, мастер-ключ Rails, расшифрованные учетные данные, пароли баз данных, реквизиты Active Storage и облачных хранилищ, API-токены и токены интеграций. Патч не возвращает секреты, которые могли быть прочитаны раньше.
На 17:30 UTC 29 июля 2026 года Ethiack и GMO Flatt Security не публиковали доказательство эксплуатации, вредоносный формат, точную конструкцию чтения файлов или свою цепочку удаленного выполнения кода. Позднее сторонний репозиторий GitHub заявил о полной цепочке от произвольного чтения до RCE в изолированной Docker-лаборатории с доступом только через loopback. В качестве уязвимого варианта там используется Rails 8.1.3, а контрольного исправленного — Rails 8.1.3.1. По описанию, подготовленный файл MATLAB/HDF5 читает окружение процесса Rails, извлекает SECRET_KEY_BASE, подписывает встроенную полезную нагрузку Marshal и вызывает внешний обратный запрос через curl. The Hacker News независимо этот PoC не проверял. Ethiack сообщил, что знает по меньшей мере об одном PoC на GitHub, но не уточнил, похож ли он на цепочку собственных исследователей.
Rails указал на независимое обнаружение уязвимости двумя группами. От Ethiack ее нашли André Baptista, Bruno Mendes и Rafael Castilho, от GMO Flatt Security — RyotaK. Ethiack сообщил об ошибке Rails 22 июля 2026 года. Компания не раскрыла, строится ли ее RCE-цепочка целиком на секретах, добытых через чтение файлов, либо использует дополнительный примитив уязвимости. Техническая публикация Ethiack может появиться до 28 августа 2026 года; Rails также пообещал раскрыть дополнительные подробности не позднее этой даты. До установленного срока исследователи удерживают сведения о вредоносном формате, способе чтения и цепочке RCE.
Rails Security Team не располагал данными об эксплуатации или попытках эксплуатации ни до публичного раскрытия, ни после него. При этом у команды нет телеметрии, позволяющей подсчитать приложения с Active Storage и Vips, тем более установки, принимающие чужие изображения. На 17:30 UTC 29 июля 2026 года CVE-2026-66066 отсутствовала в версии 2026.07.27 каталога Known Exploited Vulnerabilities Агентства кибербезопасности и защиты инфраструктуры США, известного как CISA KEV. Отсутствие в KEV означает лишь, что уязвимость к тому моменту не внесли в каталог, а не то, что атак никогда не было. Достоверного числа уязвимых приложений, списка жертв и оценки масштаба открытых установок пока нет; оценка CVSS 9,5 описывает техническую опасность, но ничего не говорит о количестве взломанных систем. Материал был обновлен 30 июля 2026 года: добавлены комментарии Rails Security Team и Ethiack, а также сведения о стороннем PoC.
Администраторам нужно найти все приложения Active Storage с Vips и проверить, принимают ли они изображения от недоверенных пользователей; затем установить Rails 7.2.3.2, 8.0.5.1, 8.1.3.1 либо более новый поддерживаемый выпуск, libvips 8.13+ и при необходимости ruby-vips 2.2.1+. Блокировку недоверенных операций следует включить явно, а не подлежащий обновлению libvips удалить. После смены всех доступных процессу секретов стоит изучить журналы приложения, базы данных, облачные хранилища и сторонние сервисы на предмет чужих обращений. Эксплуатация требует, чтобы вредоносная операция присутствовала в сборке, а целевые файлы читались с правами Rails. Для Rails 7.1 и более старых веток ждать обратного патча бессмысленно: им требуется обновление на поддерживаемую версию.[/final]
Через такую брешь могут утечь переменные окружения Rails, secret_key_base или SECRET_KEY_BASE, мастер-ключ Rails, расшифрованные учетные данные приложения, имена пользователей и пароли баз данных, ключи облачных хранилищ и сервисов Active Storage, API-токены и токены сторонних служб. Дальнейшие последствия зависят от содержимого сервера и прав найденных реквизитов. Удаленное выполнение кода, доступ к базам данных, облачным сервисам, хранилищам и другим связанным средам возможны, но не возникают автоматически после чтения файла.
Риск появляется при сочетании четырех условий: приложение использует Active Storage, обрабатывает изображения через Vips/libvips, принимает загрузки от недоверенных пользователей, а конкретная сборка libvips содержит пригодную для атаки операцию. Начиная с load_defaults 7.0 Rails выбирает Vips; более поздние наборы настроек сохраняют этот выбор. Отдельная публичная точка для изменения размера или создания миниатюр не нужна. Формулировка Rails однозначна: «Создание вариантов не является отдельным требованием». Публичный патч показывает опасную передачу вложений как в анализаторе Vips, так и в преобразователе Vips. Приложения с MiniMagick этому конкретному пути атаки не подвержены.
Исследователи Ethiack и GMO Flatt Security отнесли к затронутым версиям Rails 7.0.0–7.2.3.1, 8.0.0–8.0.5 и 8.1.0–8.1.3. Ветка Rails 6 уязвима в диапазоне 6.0.0–6.1.7.10 лишь тогда, когда Active Storage явно настроен на Vips, поскольку в Rails 6 этот процессор не использовался по умолчанию. Rails Security Team подтвердил точность указанных исследователями диапазонов. Официальное уведомление охватывает находящиеся на поддержке Rails 7.2, 8.0 и 8.1. Rails 7.1 и более ранние выпуски уже сняты с поддержки и не получат обратных исправлений; их владельцам требуется переход как минимум на Rails 7.2.3.2.
По данным Ethiack, переданным The Hacker News, необходимые библиотеки по умолчанию присутствуют в Debian, Ubuntu и создаваемых Rails средах Docker, поэтому такие конфигурации попадают в зону риска. В других дистрибутивах Linux и базовых образах контейнеров нужной библиотечной поддержки может не оказаться. Само присутствие номера Rails в уязвимом диапазоне еще не означает, что приложение можно атаковать: необходимы Vips, прием чужих изображений и доступная опасная операция в установленной сборке libvips.
libvips содержит множество загрузчиков, средств сохранения и других операций с файлами и изображениями, часть которых опирается на сторонние библиотеки. Некоторые операции помечены как «не прошедшие фаззинг» и «недоверенные», то есть их нельзя считать безопасными при разборе данных от неизвестного отправителя. Active Storage прежде не блокировал такие функции, и подготовленная загрузка могла заставить обработчик прочитать файл с правами процесса Rails. Исправление при запуске Active Storage вызывает Vips.block_untrusted(true). Защищенные выпуски: Rails 7.2.3.2, 8.0.5.1 и 8.1.3.1; дополнительно нужны libvips 8.13 или новее и, если установлен пакет ruby-vips, ruby-vips 2.2.1 или новее.
Если Rails пока обновить нельзя, при libvips 8.13+ следует задать VIPS_BLOCK_UNTRUSTED, а при ruby-vips 2.2.1+ вызвать Vips.block_untrusted(true). Старые выпуски libvips не умеют блокировать нужный класс опасных операций: библиотеку придется обновить либо удалить из приложения. Переход на MiniMagick закрывает именно Vips-зависимый путь, но не заменяет установку исправлений и проверку безопасности. После обновления необходимо сменить secret_key_base, мастер-ключ Rails, расшифрованные учетные данные, пароли баз данных, реквизиты Active Storage и облачных хранилищ, API-токены и токены интеграций. Патч не возвращает секреты, которые могли быть прочитаны раньше.
На 17:30 UTC 29 июля 2026 года Ethiack и GMO Flatt Security не публиковали доказательство эксплуатации, вредоносный формат, точную конструкцию чтения файлов или свою цепочку удаленного выполнения кода. Позднее сторонний репозиторий GitHub заявил о полной цепочке от произвольного чтения до RCE в изолированной Docker-лаборатории с доступом только через loopback. В качестве уязвимого варианта там используется Rails 8.1.3, а контрольного исправленного — Rails 8.1.3.1. По описанию, подготовленный файл MATLAB/HDF5 читает окружение процесса Rails, извлекает SECRET_KEY_BASE, подписывает встроенную полезную нагрузку Marshal и вызывает внешний обратный запрос через curl. The Hacker News независимо этот PoC не проверял. Ethiack сообщил, что знает по меньшей мере об одном PoC на GitHub, но не уточнил, похож ли он на цепочку собственных исследователей.
Rails указал на независимое обнаружение уязвимости двумя группами. От Ethiack ее нашли André Baptista, Bruno Mendes и Rafael Castilho, от GMO Flatt Security — RyotaK. Ethiack сообщил об ошибке Rails 22 июля 2026 года. Компания не раскрыла, строится ли ее RCE-цепочка целиком на секретах, добытых через чтение файлов, либо использует дополнительный примитив уязвимости. Техническая публикация Ethiack может появиться до 28 августа 2026 года; Rails также пообещал раскрыть дополнительные подробности не позднее этой даты. До установленного срока исследователи удерживают сведения о вредоносном формате, способе чтения и цепочке RCE.
Rails Security Team не располагал данными об эксплуатации или попытках эксплуатации ни до публичного раскрытия, ни после него. При этом у команды нет телеметрии, позволяющей подсчитать приложения с Active Storage и Vips, тем более установки, принимающие чужие изображения. На 17:30 UTC 29 июля 2026 года CVE-2026-66066 отсутствовала в версии 2026.07.27 каталога Known Exploited Vulnerabilities Агентства кибербезопасности и защиты инфраструктуры США, известного как CISA KEV. Отсутствие в KEV означает лишь, что уязвимость к тому моменту не внесли в каталог, а не то, что атак никогда не было. Достоверного числа уязвимых приложений, списка жертв и оценки масштаба открытых установок пока нет; оценка CVSS 9,5 описывает техническую опасность, но ничего не говорит о количестве взломанных систем. Материал был обновлен 30 июля 2026 года: добавлены комментарии Rails Security Team и Ethiack, а также сведения о стороннем PoC.
Администраторам нужно найти все приложения Active Storage с Vips и проверить, принимают ли они изображения от недоверенных пользователей; затем установить Rails 7.2.3.2, 8.0.5.1, 8.1.3.1 либо более новый поддерживаемый выпуск, libvips 8.13+ и при необходимости ruby-vips 2.2.1+. Блокировку недоверенных операций следует включить явно, а не подлежащий обновлению libvips удалить. После смены всех доступных процессу секретов стоит изучить журналы приложения, базы данных, облачные хранилища и сторонние сервисы на предмет чужих обращений. Эксплуатация требует, чтобы вредоносная операция присутствовала в сборке, а целевые файлы читались с правами Rails. Для Rails 7.1 и более старых веток ждать обратного патча бессмысленно: им требуется обновление на поддерживаемую версию.[/final]