Ровно перед майскими праздниками выстрелила и сильно прошумела CVE-2026-31431. Уязвимость в ядре позволяет проэксплуатировать LPE (Local Privilege Escalation) на почти всех дистрибутивах с 2017 года. Все говорят об LPE, но мало кто отмечает, что эту же уязвимость можно использовать для побега из контейнера в Kubernetes.

Во-первых, об этом заявляют сами исследователи, которые обнаружили уязвимость. Обещают выпустить статью в блоге на этот счет (пока ещё не выпустили).

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

В качестве PoC советуем ознакомиться с репозиторием – Copy Fail (CVE-2026-31431) — Kubernetes Container Escape PoC.

P.S. Мы также подтверждаем применимость этого в реальных условиях: в рамках аудита Kubernetes кластера нам удалось успешно использовать эксплойт. Демонстрацию можно увидеть на видео из нашего тестового окружения.

Для любителей Wazuh в их блог посте в этом году появилось 3 статья о его использовании при обеспечении безопасности Kubernetes:
- "Detecting Kubernetes attacks with Wazuh"
- "Detecting Kubernetes misconfigurations with KubeLinter and Wazuh"
- "Auditing Kubernetes with Wazuh"

На своей практике Wazuh мы не встречаем, но как бы то ни было в подобных статья всегда можно что-то подсмотреть под себя и переложить на вой стек, подход.

Всем, привет!

Подготовка к нашей конференции БеКон 2026 идет полным ходом:
- доклады опубликованы,
- расписание верстается,
- партнеры подписываются,
- первый мерч готовится,
- стикерпак печатается!

Как всегда мы вложили душу в наш оригинальный стикерпак и ждет всех посетителей конференции.

До 2 июня уже не так-то и много времени осталось ;)

В Kubernetes v1.36 появилась новая альфа фича — manifest-based admission control, которая переносит конфигурацию admission-политик из etcd в манифесты на стороне API сервера. Это решает архитектурную проблему, когда система безопасности хранилась в том же месте, которое она защищает.

Политики загружаются с диска ещё до старта API сервера, а не после. Это закрывает “startup gap”, когда кластер мог принимать запросы без применённых правил, а также снижает риск их удаления злоумышленником или проблем при падении etcd.

Более подробней об этом подходе и как он работает можно узнать из заметки "Kubernetes v1.36: Admission Policies That Can't Be Deleted".

Всем, привет!

Нам нужно исправить одно недоразумение ... Мы до сих пор не разыграли билет(ы) на нашу конференцию БеКон 2026. Давайте это исправим ;)

Конкурс: "Что было дальше?".
Ситуация: Закрытый контур. Сертифицированная ОС, сертифицированный Kubernetes.
Задание: Придумайте почему и из-за чего там произошел серьезный инцидент информационной безопасности в кластере Kubernetes.
Критерий оценки :
- Реалистичность ситуации
- Оригинальность сюжета
- Технические детали инцидента
Итоги: 14 мая.

Всем хороших выходных!

Продолжая освещать возможность эксплуатации CVE-2026-31431 (Copy Fail) для побега из контейнера, нельзя не упомянуть что и свежая CVE-2026-43284 (Dirty Frag) также открывает возможности для container escape.

На канале мы уже отмечали инструмент ctrsploit. В свежем обновлении там добавилось два новых модуля, позволяющих проэксплуатировать CVE-2026-31431 и CVE-2026-43284 в контексте container escape.

Всем, привет!

Ну что начнем представлять и немного рассказывать про доклады БеКон 2026! начнем эту серию с докладов нового трека ("Рецепты"), который посвящён выстраиванию процессов и работе с людьми, командами. Этот трек в первую очередь будет интересен и полезен для С-level, `Leads,
которые продумывают и выстраивают все в компании.

В итоге мы отобрали следующие доклады:
- "Зачем бизнесу нужна отдельная команда защиты Kubernetes?", Николай Панченко
- "SecK8S: от хаоса к системе", Черток Александр (Альфа-Банк)
- "Фреймворк JCSF: zero to hero в контейнерах", Селезнев Дмитрий (Инфосистемы Джет)
- "ФСТЭК и контейнеры: от заявки до сертификата", Андрей Слепых и Анатолий Карпенко (Фобос-НТ и Luntry)
- "Как не убить кластер и безопасность исключениями", Кунавин Валерий (Озон Банк)

На нашем сайте Luntry стали доступны материалы с выступления «Уязвимости в контейнерах и Kubernetes: правим, а не страдаем» (слайды, видео) с конференции CISO FORUM 2026 (Трек B. Когда атака — вопрос времен).

В рамках презентации были рассмотрены реактивный и проактивный подход по работе с уязвимостями. И все это на актуальной волне с гигантским количеством уязвимостей, их качеством описания, полнотой (проблемы с NIST NVD), приоритезацией и тем что AI (проекты типа XBOW, Claude Mythos) значительно ускоряют атакующего (как разработку 1day эксплоита по патчу, так и в нахождении 0day и автоматизации самой атаки).

Еще одним аргументом про изменение работы с уязвимостями (теперь как раньше уже не будет никогда) является последняя новость с легендарного соревнования pwn2own, где исследователи представляют свои 0day цепочки в самом популярном и желанном ПО. Новость в том что они просто не могут принять всех желающих на соревнование и отправляют отказы с просьбой самостоятельно с вендором разбираться в уязвимостях. В общем, buffer overflow по количеству 0day ....

P.S.Среди уязвимостей можно увидеть и уязвимости в стеке контейнеризации ...

Череда уязвимостей в ядре, приводящих к LPE и container escape продолжается.

На этот раз – fragnesia. Это новая LPE уязвимость из семейства Dirty Frag/Dirty Pipe, позволяющая локальному пользователю получить root через corruption page cache в подсистеме XFRM ESP-in-TCP. Эксплойт не требует race condition и работает как deterministic logic bug, что делает эксплуатацию особенно стабильной и опасной.

Интересно, что fragnesia появилась как побочный эффект одного из патчей для Dirty Frag. CVE пока не назначена, а фикс пока только в виде небольшого patchset, который ещё не успел попасть во все mainstream kernel releases.

P.S. Сегодня последний день подать свой вариант на конкурс и выиграть билет на нашу конференцию БеКон 2026.

Постоянные и давние читатели нашего канала наверняка помнят наш доклад "Безопасность контейнеров и Kubernetes" c True Tech Day 2022 года и вебинар "Patch management не поможет, фиксики не спасут" в 2023, где мы рассказывали о том что vulnerability management все больше и больше теряет так сказать свою значимость для реальной защиты (не путать тем что он не нужен).

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

И вот недавно вышла еще одна очень любопытная заметка "The 90 day disclosure policy is dead" в которой еще ряд хороших аргументов и кейсов.

Такими темпами скоро требование/задача защиты от 0,5day и 0day будет уже не чем то заоблачным, только для избранных, а в порядке вещей для всех.

А как вы смотрите на это работу с уязвимостями в текущий реалиях 2026 года ?

Всем, привет!

Мы подводим итоги конкурса с призами в виде билетов на БеКон 2026! И так призы уходят к:

- @gecube
- @al_mark_work
- @iv_k4v
- @popepiusXIII

Каждый сценарий по своему интересен, уникален и подсвечивает разные проблемы. Поэтому мнения жюри сильно расходились и было решено сделать 4 победителя.

Всем, хороших выходных!

P.S. С победителями отдельно свяжемся и все передадим ;)

Небольшое, но важное изменение в Kubernetes 1.36: поле Service.spec.externalIPs официально объявлено deprecated. Эта функция существовала с первых версий Kubernetes и позволяла “привязывать” внешний IP к сервису, но все эти годы считалась небезопасной из-за риска MITM-атак и CVE-2020-8554.

Команда Kubernetes прямо говорит, что externalIPs — это “insecure by default”. В будущих релизах поддержку уберут полностью из kube-proxy, а пользователям предлагают мигрировать на LoadBalancer, NodePort или Gateway API.

Если вы не используете externalIPs, переживать не о чем. Но если используете — пора планировать миграцию: начиная с 1.36 – deprecated, а полное удаление ожидается примерно к версии 1.43.

Всем, привет!

Мы продолжаем вам рассказывать про доклады с предстоящей конференции БеКон 2026! В этом году в техническом треке будет сразу 2 доклада про атаки и инциденты. Это:

1) "Истории Kubernetes пентестов: путь через мисконфигурации", Сергей Канибор (Luntry)
2) "Контейнеры против майнеров или история по криптоджекинг в Kubernetes", Князев Максим (К2 Кибербезопасность)

Напоминаем, что до конференции осталось всего 2 недели.

RBAC в Kubernetes часто становится последней линией защиты между скомпрометированным workload и полным захватом кластера. В докладе “RBAC Atlas: Mapping Real-World Kubernetes Permissions and Exposing Risky Projects” разбирается, насколько опасными могут быть избыточные permissions в популярных Kubernetes проектах.

Автор представил RBAC Atlas — каталог identities и overly permissive RBAC политик, найденных в реальных open source проектах. Доклад хорошо показывает, как даже небольшие ошибки в настройке прав доступа могут привести к повышению привилегий и компрометации всего кластера.

Продолжаем делиться интересными докладами по теме Kubernetes Security с прошедшей недавно конференции BSidesSF 2026. Доклад “Sandboxes, Seccomp, and Syscalls: Chasing Isolation in Kubernetes” от Mark Manning посвящён одной из самых сложных тем в Kubernetes — изоляции контейнеров и реальной безопасности sandbox-окружений.

Автор подробно разбирает, почему контейнеры сами по себе не являются полноценной границей безопасности, какие ограничения есть у seccomp и где проходит граница между виртуализацией и изоляцией. Особенно интересно, что в докладе рассматриваются не только способы защиты workload’ов, но и реальные сценарии обхода sandbox-механизмов.

Доклад будет полезен всем, кто работает с multi-tenant Kubernetes-кластерами и хочет лучше понимать риски container isolation.

Всем, привет!

Мы всей нашей командой с нетерпением ждем 2 июня, чтобы провести БеКон 2026 и порадовать вас морем интересных и полезных докладов, занимательных стендов наших партнеров и, конечно, же классного мерча, общения и знакомств на площадке! В этом году будет вот такая limited edition новинка ;)

Времени осталось меньше двух недель, так что успейте заполучить свой заветный тикет!

Kubesplaining — CLI-инструмент для анализа безопасности Kubernetes, написанный на Go. Он позиционируется как «Cloudsplaining для Kubernetes».

В отличие от большинства сканеров (Kubescape, Trivy, Polaris), которые ищут отдельные misconfigurations, данный инструмент строит граф privilege escalation и показывает реальные многошаговые цепочки атаки от любого непривилегированного субъекта до критических:
- cluster-admin / system:masters
- node-escape (привилегированные поды + hostPath)
- доступ к секретам в kube-system

Он использует BFS поиск по RBAC + состоянию подов и выдаёт полную цепочку с объяснениями, evidence и remediation.

Ключевые возможности:
- Модули (всего ~45 правил): RBAC (wildcard, impersonation, bind/escalate и т.д.), Pod Security, NetworkPolicy, Admission Webhooks, Secrets, ServiceAccounts, Least-Privilege (на основе audit logs).
- Поддержка живого кластера, snapshot (JSON) и отдельных манифестов.
- Отличные отчёты: интерактивный HTML, JSON, CSV, SARIF (для GitHub Code Scanning).
- CI-friendly: --baseline, --ci-mode, delta-анализ.
- Полностью offline-анализ после скачивания snapshot'а.
- Хорошая документация, примеры remediation (kubectl patch, Kyverno/Gatekeeper).

Здесь можно посмотреть демо отчет.

Всем, привет!

Мы продолжаем (1,2) вам рассказывать про доклады с предстоящей конференции БеКон 2026! В этом году в техническом треке будет 2 доклада связанных с Policy Engines:

1) "Validating Admission Policy замена Policy Engine?", Александр Алёхин (Ecom Tech)
2) "GitOps: мозг для политик безопасности", Андрей Орехов (Swordfish)

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

CVE-2021-25740 — уязвимость в Kubernetes, которую фактически невозможно полностью исправить патчем (unpatchable), потому что проблема заложена в самой архитектуре Kubernetes. Атакующий с правами на изменение Endpoints или EndpointSlices может перенаправлять трафик туда, куда у него обычно нет доступа.

Главная опасность в том, что уязвимость позволяет обходить сетевые ограничения и использовать ingress/load balancer как “confused deputy” — доверенный компонент, который выполняет действия от имени злоумышленника. Это превращает даже ограниченные RBAC-права в потенциальный путь к lateral movement внутри кластера.

Авторы статьи делают акцент на том, что защититься можно только организационными мерами: жёстким RBAC, admission controllers и мониторингом изменений Endpoints/Services. Очередной хороший пример того, как некоторые проблемы Kubernetes нельзя «закрыть обновлением» — их приходится учитывать как часть threat model всей платформы.