Если вы пропустили последние новости в сфере кибербезопасности, вот краткое резюме: обнаружение и эксплуатация громких уязвимостей в программном обеспечении происходят быстрее, чем когда-либо, во многом благодаря инструментам анализа кода на базе ИИ. В апреле и мае 2026 года все основные дистрибутивы Linux столкнулись с двумя уязвимостями повышения локальных привилегий — Copy Fail и Dirty Frag. Обе позволяют непривилегированному локальному пользователю получить права root детерминированно, на каждом крупном дистрибутиве. И обе вышли в публичное поле задолго до классического 90-дневного срока ответственного раскрытия.

(Image credit: Getty Images) (Image credit: Getty Images)

Copy Fail и Dirty Frag: одна школа уязвимостей

Copy Fail (CVE-2026-31431) был обнаружен командой исследователей Theori. По их таймлайну: отчёт в команду безопасности ядра ушёл 23 марта 2026 года, подтверждение пришло на следующий день, патчи были предложены и проверены к 25 марта, коммит в mainline-ветку появился 1 апреля, CVE присвоен 22 апреля, а публичное раскрытие состоялось 29 апреля. Дистрибутивы начали выкатывать обновления в последующие дни, но уязвимость почти сразу попала в каталог активно эксплуатируемых уязвимостей CISA KEV.

Через неделю Хёну Ким (Hyunwoo Kim, @v4bel) опубликовал Dirty Frag — связку из двух уязвимостей CVE-2026-43284 и CVE-2026-43500. Это, по сути, тот же класс багов, что у Copy Fail, но через другие подсистемы ядра:

  • CVE-2026-43284 — запись в page cache через xfrm-ESP (модули esp4/esp6 подсистемы IPsec). Корневая ошибка восходит к коммиту ядра от января 2017 года, то есть жила в коде около девяти лет.
  • CVE-2026-43500 — запись в page cache через RxRPC. Этот баг моложе и появился в 2023 году.
  • Обходит митигацию Copy Fail. Если администраторы заблокировали модуль algif_aead как защиту от Copy Fail, Dirty Frag всё равно сработает — он идёт другим путём к тому же результату.
  • Список затронутых систем: Ubuntu, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream, AlmaLinux, Fedora 44 — фактически весь корпоративный сегмент.

Технически оба эксплойта относятся к классу page-cache-write — записи в страничный кэш ядра в обход проверок целостности. Это «семейство» уже знакомо администраторам по Dirty Cow (CVE-2016-5195) и Dirty Pipe (CVE-2022-0847). Но если Dirty Cow зависел от выигранного состояния гонки и срабатывал ненадёжно, а у Dirty Pipe были жёсткие ограничения по тому, где и как можно перезаписывать данные, то Copy Fail и Dirty Frag работают стабильно и предсказуемо.

Эмбарго, сорванное за несколько часов

Главное, что показала история с Dirty Frag, — это полный провал классической модели координированного раскрытия. Ким сообщил о баге в linux-distros 7 мая 2026 года с согласованным эмбарго на 5 дней. В тот же день, всего через несколько часов, никак не связанная третья сторона независимо опубликовала детальную информацию об уязвимости в ESP-подсистеме, фактически взломав эмбарго. Подобную же ситуацию наблюдатели предполагают и в случае Copy Fail — по словам исследователей, путь от ИИ-сканирования до публичного PoC и до использования в арсенале госуровневых группировок занял буквально дни.

В качестве временной защиты Ким предложил выключить уязвимые модули esp4, esp6 и rxrpc и сбросить page cache. Совет рабочий — на большинстве серверов IPsec-модули не используются — но «выключите часть ядра и надейтесь на лучшее» обычно не та инструкция, которую системные администраторы любят получать.

«30 минут от патча до эксплойта»: тезисы Ананда

Подробный разбор того, почему всё это сломалось, написал Химаншу Ананд (Himanshu Anand) — исследователь безопасности из Cloudflare. Его пост от 9 мая 2026 года называется без обиняков: «The 90 day disclosure policy is dead». Суть аргументации сводится к тому, что бот не обязательно умнее человека в программировании или поиске уязвимостей — но LLM способен работать в полную интеллектуальную мощность круглосуточно и чрезвычайно эффективен в распознавании шаблонов. А большинство эксплойтов базируется именно на типовых плохих привычках программирования.

Чтобы проиллюстрировать тезис, Ананд приводит свой реальный кейс: он нашёл и сообщил о неисправленной уязвимости в торговой площадке, которая позволяла получать товары фактически даром. К его удивлению, в ответе сообщалось, что 10 других исследователей уже уведомили об этой проблеме за шесть недель. Друг из команды BlueWater CTF подтвердил, что давно наблюдает ту же закономерность: «охотники с LLM-поддержкой сходятся на одних и тех же ошибках почти одновременно, причём через совершенно не связанные между собой воркфлоу».

Тезис подтверждает и инженер-триажер с ником @d0rsky:

  • «Как только обнаруживается новая уязвимость — особенно через какой-нибудь LLM-промпт, скилл или автоматизацию — мы начинаем получать волну дубликатов отчётов в течение нескольких дней. Одна и та же корневая причина, лишь слегка разные формулировки».
  • «Что меня беспокоит сильнее: если исследователи могут так быстро воспроизводить эти находки, что мешает чёрным шляпам сделать то же самое до того, как баг исправят?»
  • «Окно между „первой находкой" и „массовой осведомлённостью" опасно сокращается».

В качестве ещё более жёсткой иллюстрации Ананд описывает свой эксперимент с патчами безопасности React: 24 апреля 2026 года Meta выкатила пачку CVE для фреймворка (CVE-2026-23870, CVE-2026-44574, CVE-2026-44575, CVE-2026-44578, CVE-2026-44579). По его словам, по уже опубликованному и исправленному патч-диффу он с помощью LLM-инструментов собрал рабочий эксплойт за 30 минут.

Побочная проблема — деморализация исследователей

Ананд обращает внимание ещё на один аспект, который часто упускают в дискуссии. Когда об одном и том же баге сообщают 10 человек, CVE-кредит и багбаунти получает только один — первый. Остальные девять не получают ничего. Сколько из них фрустрируются, и сколько в следующий раз решат не сообщать, а продать находку? А ещё ведь существуют те, кто и не отправлял отчёт — те уже работают вне любых тикающих часов. По логике Ананда, 90-дневное окно сегодня не защищает пользователей, а даёт всем, кто уже нашёл баг, фору в 90 дней.

Реакция Linux: аварийный killswitch для ядра

Сопровождающие ядра Linux отреагировали на «неделю, когда Linux загорелся», предложением встроить в ядро механизм аварийного killswitch. Идея простая: если эксплойт-код начинает расходиться раньше, чем готов патч, целевую функцию можно временно «выключить» — все вызовы будут немедленно падать с ошибкой, не доходя до уязвимого кода. Один из инициаторов предложения, Саша Левин, формулирует это так: «Когда проблема безопасности становится публичной, флоты остаются уязвимыми до тех пор, пока не будет собрано, распространено и перезагружено пропатченное ядро. Для многих таких проблем простейшая митигация — перестать вызывать сбойную функцию. Killswitch как раз это и даёт».

Что Ананд предлагает индустрии

В заключении пост Ананда не выбирает выражений:

  • 90-дневное окно мертво. Не «нуждается в реформе», а именно мертво. Оно было спроектировано под мир, в котором находить баги было редкостью, а написание эксплойта занимало много времени.
  • Ежемесячные циклы патчей тоже мертвы. «30-дневный интервал между уязвимостью и исправлением подразумевает, что атакующие медленнее релизного цикла». Это давно не так.
  • Любая критическая проблема безопасности — это P0. Не «следующий спринт», не «следующий патч-вторник», а немедленный инцидент с предположением, что уязвимость уже активно эксплуатируется.
  • Защитникам нужно интегрировать LLM в CI/CD прямо сейчас. Атакующие уже это сделали.

Пафосная реплика в самом конце подчёркивает позицию: «Если вы читаете описания CVE, пока атакующие читают git log --diff-filter=M, вы уже отстали».

Ирония open-source

По иронии судьбы, открытое ПО раньше опережало других по безопасности именно благодаря открытому исходному коду — он доступен для проверки и быстрых исправлений. Сегодня LLM превращают эту характеристику в палку о двух концах: тот же открытый код одинаково доступен и защитникам, и атакующим, и анализаторам с обеих сторон. С другой стороны, в мире OSS патч действительно может быть создан и распространён за несколько часов, а не недель.

Что касается закрытого ПО, неутомимые боты справляются с декомпиляцией и сетевым сканированием ничуть не хуже, чем с анализом исходного кода. Вполне вероятно, что Microsoft, Apple или Google рано или поздно переживут собственную минуту Copy Fail. Пост Ананда стоит прочитать целиком — он весьма поучителен.