У Docker Engine знайшли вразливість, яка дозволяла обійти AuthZ-плагіни та отримати доступ до хоста

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

У Docker Engine виявили серйозну вразливість CVE-2026-34040 з оцінкою 8,8 за CVSS, яку вже виправили. За певних умов вона дозволяла зловмиснику обійти плагіни авторизації AuthZ та створити привілейований контейнер з доступом до файлової системи хоста.

Проблема виникла через неповне виправлення попередньої вразливості CVE-2024-41110. Як пояснили мейнтейнери Docker Engine, спеціально сформований API-запит міг потрапити до плагіна авторизації без тіла запиту. Через це плагін міг пропустити запит, який за нормальних умов мав би заблокувати.

Причина вразливості пов’язана з некоректною обробкою надто великих тіл HTTP-запитів. У такому сценарії один HTTP-запит зі штучно збільшеним тілом може призвести до створення привілейованого контейнера з доступом до файлової системи хоста.

Як виглядає можлива атака

Зловмисник уже має доступ до Docker API, але його дії обмежені AuthZ-плагіном. Він надсилає запит на створення контейнера з тілом понад 1 МБ. У результаті плагін отримує запит без тіла та не бачить підстав для блокування, тоді як сам Docker daemon обробляє повний запит. Це дає змогу створити привілейований контейнер із root-доступом до хоста, а разом із ним отримати доступ до облікових даних AWS, SSH-ключів, конфігурацій Kubernetes та інших чутливих даних.

Окремо дослідники звернули увагу на ризики для середовищ, де AI-агенти для програмування працюють у sandbox-оточенні на базі Docker. Зокрема, такого агента можна змусити виконати шкідливу інструкцію, приховану в спеціально підготовленому GitHub-репозиторії. Крім того, агент може самостійно дійти до цього способу обходу, якщо під час звичайного завдання з налагодження отримає помилку доступу до файлів на кшталт kubeconfig.

Після успішної експлуатації вразливості зловмисник може отримати облікові дані до хмарних сервісів, захопити контроль над кластерами Kubernetes або отримати SSH-доступ до продакшн-серверів.

Які рекомендації

Проблему виправили у Docker Engine 29.3.1, тому базова порада проста: оновити Docker Engine. Якщо швидко оновитися неможливо, фахівці радять не покладатися на AuthZ-плагіни, які ухвалюють рішення на основі тіла запиту, обмежити доступ до Docker API за принципом найменших привілеїв (least privilege), а також використовувати rootless mode або —userns-remap, якщо повний перехід на rootless-режим неможливий.

Чи використовуєте ви у своїх середовищах AuthZ-плагіни для Docker, та наскільки довіряєте такому рівню захисту?