Немножко про container-specific OS и облачных провайдеров.

- У Google Cloud Platform (GCP) есть Container-Optimized OS (COS), которая разработана на базе Chromium OS.
- У Amazon Web Services (AWS) есть AWS Bottlerocket, которая является разработкой с 0 на Rust.
- У Azure теперь есть Azure Container Linux (ACL), которая спроектирована как downstream-версия Flatcar Linux, разработчика которого (Kinvolk) Microsoft купила в 2021 году.

Начиная с июня 2026 года, AKS прекратил поддержку оригинального Flatcar Container Linux. Microsoft официально рекомендует пользователям мигрировать на Azure Container Linux (ACL), который стал его полноценной заменой в экосистеме управляемого Kubernetes от Azure.

Но ранее в 2024 дистрибутив Flatcar Container Linux был полностью передан независимому фонду Cloud Native Computing Foundation (CNCF) для сохранения его нейтральности и открытости. По идее в рамках этого уже без участия Microsoft проект должен развиваться сам.

Исследователи из Synacktiv обнаружили неаутентифицированную RCE в компоненте repo-server Argo CD. Уязвимость нашли с помощью CodeQL: стандартные проверки ничего не давали, поэтому исследователи написали собственный model pack, помечающий второй параметр API-методов как источник недоверенных данных, и вышли на command injection в обработке kustomize.

Суть эксплуатации в том, что gRPC-сервер repo-server не требует аутентификации, а через поле KustomizeOptions можно подсунуть параметры --enable-helm --helm-command, чтобы выполнить произвольную команду и, например, украсть пароль от Redis. Дальше через незащищённый Redis подменяются кэшированные манифесты и git-refs, что при включённом Auto Sync приводит к развёртыванию вредоносного манифеста и полному захвату кластера — причём без опции selfHeal, в отличие от прежней находки Cycode.

Уязвимость зарепортили мейнтейнерам ещё в январе 2025 года, но она до сих пор не исправлена. Сетевые политики, поставялемые в инсталяции Argo CD защитили бы от атаки, но при установке через Helm они по умолчанию не применяются.

P.S – для эксплуатации необходимо использовать часть библиотек Argo CD. Нам удалось успешно воспроизвести уязвимость.

Возможно вы помните как мы писали, что рабочая группа в рамках Kubernetes работала и успешно разработала новые типы сетевых политик. И что к NetworkPolicy присоединились еще BaselineAdminNetworkPolicy и AdminNetworkPolicy.

Кто-нибудь работал с ними?!
А если нет, то теперь и не поработаете, так как им на смену сделали ClusterNetworkPolicy =)

Обо всех этих хитросплетениях можно подробнее узнать из статьи "API update for v1alpha2: ClusterNetworkPolicy replaces AdminNetworkPolicy and BaselineAdminNetworkPolicy" и на странице Network Policy API Working Group.

P.S. На последней странице еще угрожающе маячит "DeveloperNetworkPolicy - Possible APIs to be created in the future" ...

Исследователь под ником bikini опубликовал на GitHub целый набор из 23 эксплойтов для популярных проектов, включая FFmpeg, VLC, Firefox, Docker, PHP, OpenVPN, nmap, libssh2 и 7-Zip. Часть уязвимостей относится к категории 0-day, а сам код был создан с помощью fuzzing-инструментов в связке с AI-моделью.

Отдельно хотим отметить уязвимость в Docker. Команда docker cp при копировании файлов из контейнера на хост может обрабатывать символические ссылки таким образом, что позволяет вырваться за пределы указанного каталога и записать данные в произвольное место на хост-системе. То есть недоверенный контейнер потенциально способен перезаписать чужие файлы на машине, где выполняется копирование.

CVE идентификаторы для большинства находок пока не назначены, а публикация рабочих эксплойтов до исправления вызвала споры в сообществе о допустимости такого раскрытия.

О том, что NIST не справляется с наплывом уязвимостей и меняет свой подход по работе с CVE думаю видели и читали все.

Почти с аналогичным посылом в своем блоге выступила и команда GitHub в посте "Inside the Advisory Database and what happens when vulnerability volume breaks records".

Что и как делать в таких реалиях мы рассказывали в рамках доклада «Уязвимости в контейнерах и Kubernetes: правим, а не страдаем» c CISO ФОРУМ 2026.

Марафон LPE уязвимостей в Linux продолжается. Команда Nebula Security раскрыла GhostLock (CVE-2026-43499), stack-use-after-free в подсистеме rtmutex ядра, который был внесён ещё в Linux 2.6.39 и просуществовал более 15 лет. Корень бага в том, что на proxy-пути функция remove_waiter() очищает pi_blocked_on не у той задачи, оставляя висячий указатель на освобождённый фрейм стека ядра. Затронуты практически все дистрибутивы без патча (диапазон от v2.6.39-rc1 до v7.1-rc1), причём триггер не требует ни привилегий, ни user namespaces, ни специальной конфигурации ядра.

Ключевая опасность в том, что уязвимость превращается в container escape, локальный непривилегированный атакующий из контейнера может подняться до root на хосте. Авторы довели эксплойт до 97% стабильности через forge поддельного rt_mutex_waiter, перезапись inet6_protos[IPPROTO_UDP] и трюк с CPU entry area, за что получили 92 337 долларов в Google kernelCTF.

Полностью рабочий эксплойт и PoC уже открыто выложены в репозитории CyberMeowfia на GitHub.

Стала доступна запись эфира "Как развитие контейнеров влияет на информационную безопасность", где мы (Luntry) с коллегами из K2 вопросы специфики безопасности контейнерных окружений! Эфир получился очень интересным и задорным (особенно его вторая половина) - рекомендуем всем к ознакомлению ;)

Несправедливо мало внимания оказано шикарной уязвимости Januscape/CVE-2026-53359.

- Guest-to-Host Escape в KVM/x86
- Уязвимости 16 лет ( с 2.6.39)
- Уязвимы Intel и AMD (благодаря уязвимости в общем коде подсистемы ShadowMMU)
- Класс уязвимости `use-after-free
- Исправление вышло 19 июня
- Уязвимы версии ядра Linux до: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260
- Для операторов виртуализации это риск компрометации всех VM на хосте
- Не первый известный guest-to-host эксплоит для KVM, но первый который одновременно работает на Intel и AMD
- Большинство старых и «привычных» уязвимостей класса VM Escape происходили не в самом KVM, а в QEMU
- Нашел исследователь Хенву Ким (Hyunwoo Kim), получив за нее премию в $250 000 от Google в рамках программы kvmCTF
- Для митигейшена рекомендуют отключить функцию вложенной виртуализации (Nested Virtualization) на хосте

Подробнее: отчет исследователя, пост на openwall, NVD

Awesome Docker Sandboxes — курируемая подборка ресурсов для запуска AI-агентов в Docker Sandboxes (sbx), о котором мы недавно уже писали. Это CLI-инструмент, который запускает AI-кодинг-агентов (Claude Code, Copilot, Gemini, OpenCode и др.) внутри изолированных microVM: с собственным ядром, Docker-демоном и сетевым стеком. Агент получает полную свободу действий, но не может навредить хост-системе.

Репозиторий awesome-docker-sbx собирает всё, что появляется вокруг этой технологии:

- официальные доки и квикстарты
- обёртки, CLI и декларативные YAML-киты
- шаблоны и базовые образы окружений
- GUI и дашборды для управления песочницами
- разборы модели угроз и security-демо

Интересная деталь: список пополняется автоматически — Docker-агент по расписанию в GitHub Actions ищет новые репозитории и статьи про sbx, проверяет их на релевантность и предлагает в очередь на ручную модерацию.

Проект молодой, но тема запуска автономных AI-агентов без риска для машины сейчас одна из самых горячих — стоит добавить в закладки.

Kelos - AI-агенты как нативные ресурсы Kubernetes

Все привыкли запускать кодинг-агентов локально: открыл терминал, набрал claude или codex, посидел рядом, посмотрел. Проект Kelos предлагает другой взгляд: а что, если агенты — это не одноразовые локальные команды, а декларативные ресурсы в кластере, как Deployment или CronJob?

Kelos добавляет в K8s набор CRD, которые превращают работу AI-агентов в часть control plane:
- Task — одиночный запуск агента с промптом (выполняется в эфемерном поде);
- Session — долгоживущий диалог на StatefulSet, к которому можно подключаться из веба или терминала;
- TaskSpawner — автоматическое порождение задач из GitHub Issues и PR, вебхуков, Jira или по расписанию;
- Workspace — описание git-репозитория с аутентификацией;
- AgentConfig — переиспользуемые наборы инструкций, плагинов и MCP-серверов.

Под капотом поддерживаются Claude Code, OpenAI Codex, Gemini, OpenCode, Cursor и произвольные контейнерные образы. Задачи можно связывать в цепочки через dependsOn с передачей результатов между этапами — получается полноценная оркестрация: один агент скаффолдит сервис, второй пишет тесты, третий готовит PR.

Что это даёт на практике:
1. GitOps для агентов. Промпты, конфигурации и workflow версионируются в git и раскатываются через kubectl/Helm — как любая другая инфраструктура.
2. Изоляция. Каждый агент живёт в своём поде без доступа к хосту и соседям, с RBAC, лимитами maxConcurrency и activeDeadlineSeconds.
3. Автономные пайплайны. Классический пример из README: TaskSpawner ловит issues с меткой bug и автоматически поднимает агента на исправление.

Недавно мы задались вопросом: Сколько CVE из официального Kubernetes feeds можно закрыть политиками PolicyEngine (Kyverno/Gatekeeper)?

И после нехитрого исследования получили следующие цифры.

1. Митигируется политиками (32 CVE)
1.1. Инъекции конфигурации ingress-nginx через объект Ingress (16 CVE)
1.2. Вектор — поля Pod/PV/Service/EndpointSlice спеки (16 CVE)

2. Частично митигируется (21 CVE)
Политика снижает вероятность/последствия, но не закрывает уязвимость: либо режет только часть векторов, либо требует хрупкой кастомной эвристики, либо «лечит» ценой отключения легитимной функциональности.

3. Не митигируется admission-политиками (38 CVE)
3.1. Баг в обработке запроса apiserver — срабатывает до/вне admission (8 CVE)
3.2. Протокольные/сетевые баги kubelet, kube-proxy, apiserver-прокси (7 CVE)
3.3. Уязвим сам admission-вебхук ingress-nginx (3 CVE)
3.4. Утечки секретов/токенов в логи control-plane (6 CVE)
3.5. Клиентские инструменты и библиотеки (4 CVE)
3.6. Инфраструктура вне кластера: Image Builder, ОС нод, сторонние UI (6 CVE)
3.7. Поведение рантайма/контроллеров, не выражаемое в admission-объектах (4 CVE)

PolicyEngine — не патч-менеджмент, а срез одного слоя. Но этот слой закрывает треть фида «малой кровью». Остальное — только обновления, RBAC, NetworkPolicy и контроль логов.

BTV K8s Sandbox — Kubernetes полигон для Blue Team

Blue Team Village к DEF CON 34 (Project Obsidian) выкатили self-contained Kubernetes-песочницу для CTF: поднимаешь локально, без общей инфраструктуры, и тренируешь defensive-скиллы на реальной малвари — но в изолированной инертной среде.

Под капотом:
- Minikube — кластер
- Tetragon — eBPF-телеметрия ядра
- Cilium — сеть и network policies
- Kyverno — admission control

Челленджи — два класса:
1) Standalone — форензика реальной Linux-малвари (21 шт.)
Малварь уже «подорвана», ты разбираешь следы в /forensics/tetragon-events.json и опознаёшь семейство по kernel-повадкам.
2) Converged Frontier — investigation-сценарии (10 × 2 трека)
Многоэтапные расследования с вводной и евиденсами в /challenge/. Каждый в двух уровнях: beginner и pro.

По сути — мини-SOC с kernel-level телеметрией, чтобы разбирать TTP атак форензик-методами, а не на проде ;)
Работает через Docker/colima (macOS) или Docker Desktop + WSL2.

Про то, что LLM-агенты умеют искать и эксплуатировать мисконфиги в Kubernetes и облаках, говорят уже все. А вот как честно измерить, насколько хорошо они это делают, — вопрос куда более скучный и куда более важный.

Попытка ответа — CNAB, Cloud-Native Autonomous-attack Benchmark: полностью офлайновый детерминированный бенчмарк для оценки агентов на задачах chaining'а мисконфигураций (и на защите от них). Идея простая: любой может развернуть у себя ту же среду одной командой, подключить свою модель/своего агента (Claude, OpenAI, Gemini или локальные через LM Studio) и получить сравнимые цифры.

Внутри — 16 сценариев по Kubernetes (RBAC, NetworkPolicy), serverless (Lambda) и облачному IAM (AWS/Azure/GCP): от plaintext-кредов и IMDS/SSRF до оверпермишенов, с таксономией «фаза × домен × тип мисконфига» и уровнями сложности L1–L4.

Проект совсем свежий и пока безвестный, но направление правильное: рынок «агентных пентестеров» растет быстрее, чем способность заказчика проверить их маркетинговые заявления. И обратите внимание, что тут же встроена оценка синтеза защит — то есть бенчмарк одинаково полезен и тем, кто атакует, и тем, кто потом закрывает дыры =)

В официальном блоге Kubernetes есть статья «The Invisible Rewrite of the Kubernetes Image Promoter», и это отличный повод поговорить про безопасность цепочки поставок с непривычной стороны.

Все любят обсуждать её на уровне cosign и SLSA, но мало кто задумывается, через какой именно код физически проходит каждый официальный образ k8s. А проходит он через kpromo — image promoter, который тащит образы из staging в registry.k8s.io, подписывает их через cosign, раскатывает подписи по 20+ региональным зеркалам и генерит SLSA -provenance. Если он падает — не выходит ни один релиз Kubernetes. То есть это буквально корень доверия для всего дистрибутива образов.

И вот эту критичную штуку по-тихому переписали. За плечами у promo-tools 7 лет наслоений: монолитная логика промоушена, дубли, боль с тестами, регулярные rate limit-падения и 30+ минут на прод-джобу.

Как итог: −20% кода, заметное ускорение, и всё это с нулевым даунтаймом — никто ничего не заметил =) Отдельно приятно, что тут же живут SBOM и vulnerability scanning, то есть весь supply-chain обвес.