Ruby on Rails виправила CVE-2026-66066 — критичну вразливість Active Storage, яка може дати неавтентифікованому зловмиснику змогу читати файли, доступні процесу застосунку, а потім використати розкриті секрети для віддаленого виконання коду або переходу до інших систем. Підтверджений ризик виникає, коли застосунок обробляє зображення Active Storage через libvips і приймає їх від ненадійних користувачів. Оновіть Active Storage до виправленої версії, використовуйте libvips 8.13 або новішу та змініть секрети, які міг прочитати процес.
Rails опублікувала advisory 29 липня 2026 року та оцінила вразливість у 9,5 бала за CVSS 4.0. 31 липня команда достроково розкрила деталі атаки й офіційні форензичні інструменти, оскільки дослідники вже опублікували proof-of-concept. Наявність PoC підвищує терміновість, але Rails не стверджує, що кожен застосунок уразливий, і не підтверджує масову кампанію експлуатації.
Чи уражений ваш Rails-застосунок?
| Що перевірити | Як тлумачити |
|---|---|
| Версія Active Storage | Уражені випуски до 7.2.3.2, гілка 8.0 до 8.0.5.1 та гілка 8.1 до 8.1.3.1. Для старіших застосунків також потрібна перевірка конфігурації, бо вирішальним є обраний обробник. |
| Обробник варіантів | Підтверджений шлях потребує config.active_storage.variant_processor = :vips. Застосунки з ImageMagick замість libvips не уражені саме цим вектором. |
| Хто завантажує зображення | Застосунок має приймати зображення від ненадійного користувача. Самостійно створений обліковий запис також є ненадійним джерелом, навіть якщо потрібна реєстрація. |
| Active Storage не використовується або джерела повністю довірені | Документований ланцюжок не застосовується, однак перевірте фактично розгорнутий код і середовище, а не стару схему архітектури. |
Rails 7 змінила типовий обробник варіантів на libvips через load_defaults 7.0. Тривало підтримуваний застосунок може зберігати власні налаштування, а контейнер — містити іншу версію libvips, ніж ноутбук розробника. Зіставте Gemfile lock, конфігурацію Rails, бібліотеку обробки зображень і маршрут завантаження саме в розгорнутому середовищі.
Як читання файла може перейти у виконання коду
libvips підтримує багато loader і saver операцій, зокрема для форматів, які не є звичайними вебзображеннями. Частину операцій позначено небезпечними для ненадійного вмісту. Active Storage не блокувала їх, тому спеціально створене завантаження могло змусити обробник прочитати інший файл, доступний процесу Rails. Окремий явний запит на створення варіанта, за даними advisory, не є додатковою умовою.
Файли й змінні середовища Rails-процесу часто містять secret_key_base, master key, облікові дані бази й object storage та токени зовнішніх сервісів. Тому читання файла — не кінцева межа. Викрадений ключ підпису або сервісний токен може дозволити підробляти сесії, звертатися до інших систем або знайти шлях до виконання коду. Схожий принцип «патч не повертає секретність уже прочитаного файла» діє і для критичних вебуразливостей на кшталт wp2shell у WordPress, хоча компоненти й техніка атаки тут інші.
Виправлені версії та тимчасове зниження ризику
| Гілка | Виправлений випуск |
|---|---|
| Rails / Active Storage 7.2 | 7.2.3.2 або новіша |
| Rails / Active Storage 8.0 | 8.0.5.1 або новіша |
| Rails / Active Storage 8.1 | 8.1.3.1 або новіша |
Виправлена Active Storage також потребує libvips 8.13 або новішої. Якщо libvips 8.13+ вже встановлена, але Rails неможливо негайно оновити, адміністратор може тимчасово задати VIPS_BLOCK_UNTRUSTED до ініціалізації бібліотеки. Із ruby-vips 2.2.1 або новішою можна викликати Vips.block_untrusted(true) в initializer. Версії libvips до 8.13 не вміють блокувати небезпечні операції, тому задокументований запасний варіант — прибрати залежність або цей обробник.
WAF може зменшити кількість очевидних exploit-запитів, але не доводить, що спеціально створений файл було заблоковано, і не відкликає вже скопійований секрет. Це тимчасовий додатковий шар, а не заміна оновленню Rails і libvips.
Чому одного патча недостатньо
Оновлення закриває вразливий шлях, але не робить уже скопійований секрет знову приватним. Rails радить змінити всі секрети, які міг читати процес застосунку:
secret_key_baseі Rails master key;- усі значення, розшифровані з
config/credentials.yml.enc; - ключі S3, Google Cloud Storage, Azure або іншого Active Storage;
- облікові дані бази;
- API-токени, webhook secrets, SMTP-облікові дані та ключі зовнішніх сервісів.
Зміна secret_key_base завершує активні сесії та впливає на зашифровані й підписані cookies, signed Global IDs і підписані Active Storage URL. Заплануйте цей вплив на користувачів, але не залишайте старе значення як fallback: тоді викрадений ключ продовжить працювати.
Як перевірити ознаки експлуатації CVE-2026-66066
Команда Rails опублікувала окремий форензичний репозиторій із двома напрямами: перший визначає, чи був застосунок уразливим і протягом якого періоду; другий шукає спеціально створені файли в даних Active Storage й установлює, який файл було прочитано, якщо артефакт знайдено. Перевірка використовує записи бази застосунку та object storage, а не лише HTTP access logs.
Відсутність артефакту в доступному наборі даних корисна, але не є універсальним доказом відсутності компрометації. На результат впливають строки зберігання, видалені objects, репліки, staging-середовища й альтернативні маршрути завантаження. Перед очищенням збережіть snapshot, перегляньте офіційний код та інструкції до запуску в production і розширте розслідування, якщо було прочитано чутливий файл або використано пов’язаний credential.
Порядок реагування для відкритого застосунку
- Підтвердьте фактичну експозицію. Зафіксуйте версію Active Storage, libvips, обробник варіантів, маршрути завантаження та найранішу дату, коли всі умови ризику виконувалися.
- Збережіть докази. Зробіть snapshot потрібних баз, метаданих object storage, журналів застосунку, історії розгортань і поточної конфігурації до видалення підозрілих uploads.
- Оновіть Active Storage і libvips. Розгорніть виправлений Rails із libvips 8.13+ та перевірте production, workers, staging і review environments.
- Змініть доступні процесу секрети. Почніть із ключів підпису й master key, потім змініть облікові дані бази, storage та сторонні токени. Видаліть старі значення.
- Завершіть сесії та відкличте підписані артефакти. Перевірте, чи жоден сервіс не приймає старі cookies, tokens або signed URLs.
- Запустіть офіційні форензичні перевірки. Шукайте задокументовані артефакти в базі й object storage, а потім зіставте їх із журналами доступу, cloud, database та identity.
- Перевірте подальше використання. Шукайте нові сесії, нетипові запити до бази й storage, використання токенів, зміни конфігурації та lateral movement у період експозиції.
- Розділіть рівні доказів. «Був уразливим», «артефакт знайдено», «файл прочитано» і «credential використано» — різні стани, які не можна автоматично називати одним фактом зламу.
Таке ж розділення умов ризику важливе для Fastjson CVE-2026-16723: наявність уразливої версії ще не доводить виконання повного ланцюжка, але підтверджена експозиція вимагає негайного виправлення й перевірки наслідків.
Джерела
- Rails Security Team. «Possible arbitrary file read and remote code execution in Active Storage variant processing». Rails project GitHub Security Advisory GHSA-xr9x-r78c-5hrm, опубліковано 29 липня 2026 року, дата звернення: 1 серпня 2026 року. офіційний advisory.
- Mike Dalessio, Rails Security Team. «[CVE-2026-66066] Attack details, and tools to perform a forensic investigation». Rails Security Announcements, опубліковано 31 липня 2026 року, дата звернення: 1 серпня 2026 року. офіційне повідомлення про форензичні інструменти.
- Rails Security Team. «rails-forensics-CVE-2026-66066». GitHub repository, дата звернення: 1 серпня 2026 року. офіційний форензичний репозиторій.
