Уязвимости ядра Linux Copy Fail и Dirty Frag раскрыты задолго до 90-дневного срока: эмбарго Dirty Frag было сорвано в течение нескольких часов
ИИ-ассистенты находят одни и те же баги почти одновременно — триаж-команды фиксируют волны дубликатов отчётов в течение нескольких дней
Исследователь Химаншу Ананд утверждает, что превратил публичный патч-дифф React в рабочий эксплойт за 30 минут с помощью LLM
Сопровождающие ядра Linux предложили механизм аварийного killswitch — функцию можно «выключить», пока готовится патч
90-дневное окно ответственного раскрытия больше не защищает пользователей: атакующие читают git log быстрее, чем релизные циклы
Если вы пропустили последние новости в сфере кибербезопасности, вот краткое резюме: обнаружение и эксплуатация громких уязвимостей в программном обеспечении происходят быстрее, чем когда-либо, во многом благодаря инструментам анализа кода на базе ИИ. В апреле и мае 2026 года все основные дистрибутивы Linux столкнулись с двумя уязвимостями повышения локальных привилегий — Copy Fail и Dirty Frag. Обе позволяют непривилегированному локальному пользователю получить права root детерминированно, на каждом крупном дистрибутиве. И обе вышли в публичное поле задолго до классического 90-дневного срока ответственного раскрытия.
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. Пост Ананда стоит прочитать целиком — он весьма поучителен.
