В октябре 2026 года в ядре Linux закрыли дыру, в которую мог войти любой, кто умеет отправить TCP-пакет. Это происходит ещё до того, как хоть один байт доходит до вашего приложения, без пароля и без аккаунта — уязвимый код срабатывает в момент, когда ядро ещё только пожимает руку входящему соединению. Баг родился в январе 2016-го. Десять лет через него проходило практически каждое TCP-соединение в интернете. А 27 октября Anthropic сообщила, что её неопубликованная модель написала к нему эксплойт: 48 минут — и у неё адрес ядра, ещё пять — и у неё root.

Дыра тут, в сущности, ни при чём. Просто взлом подешевел, а мы продолжаем считать по-старому.

И нет, это не история о том, что ИИ всех взломает. Пока мы спорили, заменит ли нас Copilot, изменились две вещи, и произошло это одновременно.

Первая. Десять лет мы жили с багом, который снаружи неотличим от аккуратно спрятанной закладки. Как Heartbleed. Прав оказался параноик в шапочке из фольги: несокрушимых систем нет, есть только сложность, которая делает взлом невыгодным. И эта сложность только что обвалилась в цене.

Вторая. ИБ с приходом ИИ изменилась сильнее, чем разработка. Только разработка менялась у всех на виду — с мемами, холиварами, стартапом на каждый чих и новым жанром статей «Я уволил разработчиков и сделал это за вечер». ИБ же менялась за закрытой дверью. А июньская ситуация с Fable навесила на эту дверь мощный замок. Модели, которые превращают гонку в ядре в шелл от root, работают прямо сейчас. Просто не у нас. Отсюда неудобный вопрос: мы этого не заметили — или нам не показывают?

Я CTO облачного провайдера, то есть человек, у которого под ядром Linux крутятся чужие деньги. И, сложив новостной поток и уведомления от ЦМУ ССОП в общую картинку, я хочу сказать, что пора бить тревогу!

Знать C для чтения вообще не надо: достаточно понимать, что такое указатель, и быть знакомым с Go, PHP или Node.js. Если есть что добавить или поправить — приглашаю в комментарии.

В 2015 году сетевой стек Linux упирался в стену

Каждый входящий TCP-пакет для ещё не установленного соединения должен был найти listening-сокет — тот, на котором ваш nginx или Go-сервис сделал listen(), — взять на нём lock и только потом работать. На сервере с десятками тысяч новых соединений в секунду все ядра процессора стояли в очереди в одну дверь.

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

2 октября 2015 года Эрик Дюмазе (Eric Dumazet), инженер Google и один из самых продуктивных мейнтейнеров сетевой подсистемы ядра, прислал патч 079096f103fa «tcp/dccp: install syn_recv requests into ehash table». Полуоткрытые соединения вынесли из очереди к вышибале в отдельный список, и с ними теперь работает любой свободный сотрудник. Давление на дверь упало вдвое.

Патч прошёл ревью, вошёл в ядро 4.4 в январе 2016 года и разъехался по планете: Debian, Android, Raspberry Pi, гиперскейлеры. Десять лет он честно ускорял TCP всем, включая вас.

Но у любой оптимизации, которая расширяет дверь, есть цена: код, который выполнялся по очереди, теперь выполняется параллельно, и два ядра процессора могут одновременно смотреть на одни и те же байты. Если одно из них в этот момент эти байты освобождает — здравствуй, гонка. Когда двум сотрудникам разрешают работать с одним гостем, надо чётко договориться, кто выбрасывает его анкету. Эту договорённость в одном месте не дописали.

Фикс в октябре 2026-го написал тот же Эрик Дюмазе. Ни плохих программистов, ни злых гениев здесь нет. Один из лучших сетевых инженеров планеты не увидел гонку в собственном коде — и десять лет её не видел никто. Включая всех, кто этот код ревьюил, читал и ставил в прод. Про последних тоже важно: 99,999 % тех, кто раскатывает ось на хост, не читали даже сорцов ядра. От админов это и не требуется. Но в этом коде оказалась зарыта весьма нетривиальная вещь.

Два ключа от одной квартиры

Черновик соединения

TCP-соединение начинается с трёх пакетов: клиент шлёт SYN, сервер отвечает SYN-ACK, клиент закрывает рукопожатие пакетом ACK. Пока третий пакет не пришёл, ядро держит в памяти маленькую структуру — request-сокет. Это черновик соединения: адреса, порты, номера последовательности и указатель ireq_opt на IP-опции, если клиент их прислал.

IP-опции — атавизм 1981 года из RFC 791. Заголовок IPv4 обычно занимает 20 байт, но стандарт разрешает дописать к нему до 40 байт «опций»: например, Record Route или Timestamp. В живом трафике сегодня их не встретишь. Но протокол их разрешает, а значит, ядро обязано их принять, сохранить и вернуть в ответном SYN-ACK. Сохранить — значит выделить под них кусочек памяти ядра и запомнить адрес в ireq_opt.

Когда приходит третий пакет, tcp_v4_syn_recv_sock() создаёт из черновика настоящий, «дочерний» сокет — тот, который ваше приложение получит из accept(). При этом опции не копируются. Дочерний сокет получает тот же указатель. Две структуры смотрят на один кусок памяти — это как передать слайс в Go вместо копии массива. Само по себе это нормально. Опасно это становится, только если кто-то читает эту память в момент, когда другой её освобождает. Два человека с ключами от одной квартиры, которые не знают друг о друге. Ирония судьбы!

В этом игровом автомате денег за проигрыш не берут

После патча 2015 года пакеты для одного полусоединения могут обрабатываться разными ядрами процессора одновременно, без общего лока. Сценарий выглядит так:

1. Атакующий шлёт SYN с IP-опциями. Ядро создаёт черновик и выделяет память под опции.

2. Атакующий шлёт ACK. Ядро A создаёт дочерний сокет, который делит опции с черновиком.

3. Атакующий повторно шлёт тот же SYN (ретрансмит — штатная ситуация в TCP). Ядро B находит черновик и начинает собирать повторный SYN-ACK в ip_options_build(), читая опции по тому самому указателю.

4. В это же время атакующий обрывает соединение. Ядро A уничтожает дочерний сокет, и inet_sock_destruct() делает опциям обычный kfree().

5. Ядро B продолжает читать память, которой уже нет.

Все три события — SYN, ретрансмит и обрыв — контролирует атакующий. Поэтому команда CVE ядра поставила низкую сложность атаки. Окно между шагами 3 и 4 — микросекунды, и в большинстве попыток в него не попадаешь. Но проигранная гонка ничего не стоит: одно рукопожатие просто не состоится, сервер не падает, логи молчат. Можно дёргать ручку тысячи раз в секунду, пока порт открыт.

Go-разработчики наверняка узнали data race: две горутины, один указатель, никакого mutex. go test -race нашёл бы это за минуту — если бы тест присылал SYN с IP-опциями, делал ретрансмит и рвал соединение в одно и то же мгновение. Но такие тесты никто не придумал, что, в общем-то, нормально.

Процессор не знает, что память мертва

В Go, PHP и Node.js вы не освобождаете память руками — сборщик мусора не отдаст объект, пока на него есть хоть одна ссылка. В ядре сборщика нет. kfree(p) — это обещание аллокатору: «эти байты больше никто не использует, отдавай следующему». Память при этом никуда не девается и не обнуляется. Указатель — просто число. Процессор не знает, живая память по этому адресу или уже нет. В ассемблере чтение длины опций выглядит примерно так:

; rdi = указатель на структуру опций (тот самый ireq_opt)
movzx  eax, byte [rdi + 4]   ; прочитать поле optlen
lea    rsi, [rdi + 8]        ; адрес самих байтов опций
rep movsb                    ; скопировать optlen байтов в исходящий пакет

(Это иллюстрация смысла, а не дизассемблированный листинг ядра.)

Процессор честно выполнит эти инструкции, что бы ни лежало по адресу rdi. Если аллокатор уже отдал эти байты кому-то другому и тот записал туда свои данные, в optlen окажется чужое число, а rep movsb скопирует в исходящий пакет столько байтов, сколько оно скажет. В том числе байты соседних объектов из того же слэба — так в ядре называют кусок памяти, нарезанный на объекты одного размера. К опциям они не имеют никакого отношения. Это и есть use-after-free — чтение чужой памяти по старому адресу. Весь уют Go, PHP и Node.js — сборщик мусора, подсчёт ссылок, V8 — построен ровно для того, чтобы вы никогда не видели этот слой.

Баг от эксплойта отличает то, кому аллокатор отдаст освободившиеся байты. Аллокатор ядра SLUB раскладывает такие объекты по кэшам одного размера, и освобождённый кусок, скорее всего, достанется следующему запросу из того же кэша: свободные объекты выдаются по принципу «последним пришёл — первым ушёл». Если атакующий умеет заставить ядро выделить объект нужного размера с нужным содержимым — а сетевой стек выделяет объекты на каждый входящий пакет, — он управляет тем, что ядро прочитает вместо опций.

Всё это чинят ровно две строки

В ядре есть механизм RCU. Если сильно упростить: kfree_rcu(p) не освобождает память сразу, а кладёт её в коробку с надписью «выбросить, когда все, кто сейчас в комнате, из неё выйдут». Ядро B, которое собирает SYN-ACK, — в комнате. Память дождётся, пока оно закончит. Именно так ядро давно освобождает IP-опции в других местах — просто в этих двух строках стоял обычный kfree.

И да, IPv6 этим багом не страдает: tcp_v6_syn_recv_sock() копирует опции, а не делит указатель. Два соседних файла — два разных решения.

Двенадцать дней remote root лежал в общей ленте

Баг нашёл и сообщил в апстрим исследователь Anthropic Xinyang Ge — его имя стоит в теге Reported-by. Anthropic пишет лишь «с помощью Claude мы обнаружили». Заголовки «ИИ нашёл дыру за 40 минут» — это выдумка. Сорок восемь минут — это время работы уже готового эксплойта. Сколько ушло на то, чтобы найти гонку, не знает никто за пределами Anthropic.

Сам фикс — коммит e3f33b0a1d89: два файла, +2/−2. В net/ipv4/af_inet.c и net/ipv4/tcp_ipv4.c kfree() заменён на kfree_rcu(). Десять лет риска для каждого Linux-сервера с открытым IPv4-портом умещаются в diff размером с твит.

Хроника событий

Тут важны не сами даты, а расстояние между ними. Фикс вышел раньше CVE, CVE — раньше оценки, оценка — раньше новости об эксплойте. По учебнику ответственного раскрытия всё прошло образцово, хоть в рамку. И при этом двенадцать дней — с 15 по 27 октября — CVE с будущим remote root лежала в общей ленте среди сотен других записей ядра, без оценки и без заголовков. Админы пролистали её, как пролистывают рекламу. А RHEL-сервер с открытым 443 простоял без патча 27 дней после апстрим-фикса. А ведь Red Hat Enterprise Linux — это когда вы отчехляете за бесплатный линукс очень даже платные деньги, чтобы получать поддержку, в частности, оперативные фиксы вот такой фигни.

Можно ли вообще выиграть гонку

Команда CVE ядра: 9.8. Oracle, SUSE, Amazon: 8.1 — тот же вектор, но сложность атаки «высокая». Red Hat стартовал с 5.9 («гонку трудно выиграть, скорее всего, просто крэш») и только 29 октября, через два дня после поста Anthropic, поднял до 8.1. Ubuntu: 8.3.

Один и тот же баг — где-то умеренный, а где-то критичный. Факты у 5.9 и 9.8 одни и те же, расходится только ответ на вопрос: «а гонку вообще можно выиграть?» Red Hat две недели считал, что практически нет. Потом выяснилось, что модель выигрывает её за 48 минут. За покерный стол с лучшими игроками мира сел кто-то, кто видит все карты даже без крапа.

Если ваш сканер и SLA на патчи завязаны на вендорскую оценку, на EL-хостах этот баг две недели был Moderate — пока в открытых источниках описывали рабочую root-цепочку. Вранья от сканера не было, зато был счёт по чужому прайсу.

Для полноты картины: в дикой природе эксплуатация не замечена, в CISA KEV баг не внесён, код эксплойта не выложен, независимого воспроизведения нет. Правда, «не замечена» здесь значит одно: никто не смотрел. SYN с IP-опцией — легитимный пакет, проигранная гонка — обычный неудавшийся handshake, в логах пусто. После Heartbleed тоже никто так и не узнал, кто и сколько им пользовался. Отсутствие свидетельств — не свидетельство отсутствия. Это просто значит то, что никто туда не смотрел.

Справедливости ради, это не 0-day: фикс вышел раньше CVE. Вроде как можно выдохнуть, вот только ненадолго.

Пятьдесят три минуты

По заявлению Anthropic, модель получила «начальный промптинг» и удалённо, без учётных данных, превратила CVE-2026-98432 в шелл от root. 48 минут на утечку адреса ядра, ещё пять — на выполнение команды.

Первые 48 минут — победить KASLR. Из бага «прочитать чужой мусор» нужно сделать «прочитать нужный мусор». KASLR прячет ядро по случайным адресам, чтобы атакующий не знал планировку квартиры. Модель подбирает момент гонки так, чтобы в ответный пакет сервер положил кусок собственной памяти, а в нём — внутренний адрес ядра. Помните SLUB? Вся сложность здесь — заставить аллокатор положить на место освобождённых опций объект, в котором этот адрес окажется, и выиграть гонку достаточно раз, чтобы его вычитать.

Последние 5 минут — от чтения к записи. Когда планировка известна, тем же приёмом записывается чуть больше, чем нужно, и один служебный указатель ядра подменяется на адрес заранее подготовленного кода. Ядро по привычке переходит по этому указателю — и выполняет чужую команду. С правами root.

Это тот самый SLUB из раздела про аллокатор.

Деталь, которую легко пропустить в пресс-релизе: показанная цепочка требует MPTCP-листенера. Десять лет назад это была бы экзотика. Но с Go 1.24 любой Go-сервис на Linux открывает MPTCP-листенер по умолчанию, если ядро разрешает: API-шлюз, reverse proxy, экспортер метрик держат листенер, которого никто не просил. Go Security Team добавила, что баг не специфичен для MPTCP и системы без него могут быть уязвимы к похожим атакам. Это значит совсем не то, что показанный путь был единственным в своём роде, а то, что его просто нашли первым.

Теперь давайте проведём границу между фактами и домыслами, потому что вокруг неё и будет дискуссия.

Что известно. Внутренняя, неопубликованная модель Anthropic написала рабочий remote-root эксплойт за указанное время. Код не выложен, воспроизведения со стороны нет. При этом команда CVE ядра в своих scoring notes ещё до 27 октября описала и утечку соседней heap-памяти пиру, и управляемые out-of-bounds записи. Цепочка Anthropic — то же описание, доведённое до конца.

Что неизвестно. Какой именно «начальный промптинг» ей дали — то есть сколько человеческой работы стоит за словом «получив». Сколько заняла собственно находка бага. Как именно его искали и какая доля работы была за моделью. Насколько результат воспроизводим и переносим на другие дыры. И главное: это потолок, доступный только лучшим закрытым моделям в лабораторных условиях, — или порог, который вот-вот перешагнут модели попроще.

Где-то здесь пресс-релиз заканчивается. А дальше уже то, ради чего я всё это написал.

Иллюзия чужих глаз

Код живёт в самом проходимом месте самого проверяемого кода на планете: через него проходит каждое TCP-соединение в мире. Ок, кроме винды, макоси, BSD и всего на IPv6. Срабатывает он на редких IP-опциях, которых в живом трафике не бывает, — идеальный триггер, который никогда не выстрелит случайно и не засветится в логах. И десять лет его не видел даже автор.

Почти наверняка это честная ошибка. Я утверждаю другое, и это важнее: честная ошибка и спрятанная закладка выглядят одинаково. Код не умеет краснеть и отводить глаза. Значит, на вопрос «закладка или нет?» в принципе нереально ответить — и потому поставлен неправильно.

История подтверждает это с унылой регулярностью:

• Heartbleed (2014), CVE-2014-0160. Дыра в OpenSSL, которая отдавала куски памяти сервера — пароли, сессии, приватные ключи — любому, кто вежливо попросит. Два с лишним года в библиотеке, которой шифровался весь интернет. Автор признал ошибку в проверке длины. Ошибка? Да. Отличима ли снаружи от умысла? Нет. Конспирологи до сих пор не успокоились, и, честно говоря, я их понимаю.

• Попытка 2003 года. Кто-то тихо вписал в исходники ядра две строки в sys_wait4: условие с = вместо ==, дающее процессу root. Присваивание вместо сравнения — опечатка, которую хоть раз делал каждый, кто писал на C. Поймали случайно, по рассинхрону с системой контроля версий. Вот это была закладка. И выглядела она ровно как баг.

• Juniper ScreenOS (2015). Неавторизованный код в прошивке: подменённая константа генератора случайных чисел и зашитый пароль SSH, замаскированный под отладочную формат-строку. Жил как минимум с 2012-го. Два изменения, неотличимые от обычных правок в коде. Настоящая закладка — и ни одного красного флага в диффе.

• xz/liblzma (2024), CVE-2024-3094. Бэкдор, который готовили годами: человек втёрся в доверие к уставшему мейнтейнеру, стал сопровождающим и заложил в релиз обфусцированный обход SSH-аутентификации. Поймали чудом: инженер Microsoft заметил, что ssh стал отвечать на полсекунды медленнее, и пошёл разбираться. В тот день вся мировая ИБ держалась на одном человеке, которому было нечем заняться в выходные.

С 2005 по 2015 год существовал Underhanded C Contest — конкурс кода, который выглядит невинно, проходит ревью и делает зло. Победители почти всегда пользовались одним набором: off-by-one, переполнение целого, неверный порядок освобождения памяти, гонка. Ровно то, из чего сделан наш баг. Ещё был распространённый трюк на внимательность ревьювера, типа if (user_is_admin); { grant_access(); }, где из-за лишней ; блок авторизации выполнится всегда. Закладки и баги сделаны из одного материала.

А в 1984 году Кен Томпсон в тьюринговской лекции «Reflections on Trusting Trust» показал: бэкдор можно заложить в компилятор так, что его не будет видно ни в одном исходнике — ни компилятора, ни программы. Вывод Томпсона: доверять можно только коду, который ты написал полностью сам. С тех пор полностью сами мы не написали ничего. Мы стоим на миллиардах строк чужого кода.

И второе, что стоит принять как факт: десять лет — это медиана. Shellshock жил в bash 25 лет. PwnKit в pkexec — 12. Baron Samedit в sudo — 10. Dirty COW в ядре — 9. Весь этот код читали тысячи людей. «Given enough eyeballs, all bugs are shallow» — красивая фраза, но глаза смотрят на то, что код делает, а не на то, что он может сделать при гонке двух CPU на ретрансмите SYN с опцией, которую никто не шлёт. И вот закон Линуса, сформулированный, кстати, Эриком Рэймондом (сам Линус эту фразу никогда не формулировал и не записывал), становится опасной иллюзией.

Самая большая проблема открытого кода — все думают, что его уже проверил кто-то другой. В итоге критически важные библиотеки годами лежат без должного аудита. Это иллюзия «чужих глаз».

Как показал Underhanded C Contest, если код написан чисто, аккуратно и снабжён красивыми комментариями, человеческий мозг при код-ревью склонен доверять общей картине, пропуская микроскопические детали. Усталый разработчик после 50-го пулл-реквеста за день просто не заметит, что указатель уехал на пару байт за границу объекта, или пропустит лишнюю точку с запятой.

Не говоря уже о том, что нужна очень глубокая кроссдисциплинарная экспертиза, чтобы вообще заметить что-то наподобие АНБшной закладки с P=eQ в Dual_EC_DRBG. Напомню, это был самый настоящий государственный бэкдор.

Несокрушимых систем нет, есть системы, которые взламывать слишком дорого

Это не я придумал, а Росс Андерсон в 2001 году в «Why Information Security is Hard». Безопасность — это экономика, а не инженерия. Криптография работает не потому, что её нельзя взломать, а потому, что перебор 2^128 ключей стоит дороже вселенной. Всё остальное устроено так же, просто степени меньше. KASLR не делает эксплойт невозможным — он добавляет этап «сначала утечка адреса». Canaries, SMEP, SMAP, seccomp, сегментация сети — ни один слой не непробиваем. Каждый слой отнимает у атакующего время — где часы, а где недели.

А теперь главное. 48 минут на обход KASLR — это измеренная стоимость KASLR. Механизм проектировался в расчёте, что у исследователя мирового уровня он отнимет недели. «Слишком дорого» — это дробь: в числителе стоимость атаки, в знаменателе выигрыш. Десять лет числитель выглядел как «человек из нескольких сотен на планете, месяцы работы, без гарантии». С 27 октября — как «53 минуты машинного времени». При этом внутри ядра ничего не изменилось, изменился только прайс. А сколько ещё таких багов лежит в тех же миллиардах строк, не знает никто, и даже те, кто их написал.

Разработку перевернули при всех, а безопасность осталась за закрытой дверью

Про то, как ИИ перевернул разработку, написаны тысячи статей и сорваны сотни тысяч голосов в холиварах. Про то, как ИИ перевернул наступательную безопасность, не написано почти ничего. Кроме пары статей в духе «ИИ всех взломает» от ИБ-вендоров. Странно: перевернул он её сильнее.

В разработке сдвиг прожили и обсудили: один инженер с агентами делает работу команды, ревью пишет агент, тесты пишет агент. В ИБ произошло то же самое, потому что это те же модели с той же способностью — читать код и рассуждать о нём. Фаззинг был автоматическим давно. Автоматическим стало то, что шло после крэша: понять, почему упало, довести use-after-free до утечки адреса, утечку — до записи, запись — до root. Та часть, которая была искусством, превратилась в 53 минуты.

Вот два процесса из этой истории и их скорость.

До октября 2026-го красная кривая шла выше серой: взломать вас стоило дороже и занимало дольше, чем вам требовалось, чтобы закрыться. Теперь они поменялись местами.

Превратить баг в оружие. Из недель работы редкого специалиста — в 53 минуты машинного времени. Падение на порядки.

Доставить патч на ваш сервер. Раньше на это уходили недели. Теперь на это всё ещё уходят недели. Апстрим-фикс вышел 5 октября, RHEL получил его 1 ноября, часть LTS-дистрибутивов не получила до сих пор. Эта кривая не рухнула. Сроки доставки патчей не сдвинулись вообще.

Между ними — зазор, в котором живёт каждый, у кого нет круглосуточного SOC. Зазор только что стал шире на порядок, и расширил его не злодей в худи, а простая физика: инструмент, который был доступен единицам, стал доступен машине.

У Андерсона есть и второй тезис: системы ломаются там, где тот, кто может защитить, не несёт риска. Апстрим починил за две строчки. Вендор оценил в 5.9 и выпустил ядро через 27 дней. Риск всё это время лежал на админе хоста с открытым 443, который не мог ни починить, ни оценить. Все трое действовали рационально, но система в целом — нет.

Есть и менее очевидная связь с разработкой. MPTCP-листенер, без которого цепочка не работает, появился на серверах не потому, что кто-то решил его включить. Он появился, потому что Go 1.24 счёл это хорошим дефолтом, а разработчик сервиса не читал release notes рантайма. Скорость, с которой мы собираем системы из чужих дефолтов, сама по себе растит поверхность атаки. Никто в этой цепочке не ошибся. Просто никто не в состоянии представить себе итог.

И последнее. Вендоры спорили об оценке бага дольше, чем модель писала к нему эксплойт. Экспертная оценка опасности отстала от машинной демонстрации этой опасности. Раньше было наоборот: сначала эксперты пугали, потом когда-нибудь кто-нибудь писал PoC. Теперь PoC приезжает раньше, чем эксперты успевают договориться, стоит ли волноваться.

Чтобы не казалось, что это одна история: вот одна неделя из нашей жизни хостера в октябре 2026-го по истории писем от ЦМУ ССОП.

Две из четырёх — работа ИИ-агентов. Год назад в этой колонке не было бы ни одной модели.

Есть мнение, что нам не показывают специально

Эксплойт написала не публичная модель, которую вы гоняете в чатике. Его написала внутренняя, неопубликованная модель Anthropic. Код не выложен, воспроизведения нет. Мы знаем о событии ровно столько, сколько компания сочла нужным рассказать в блоге, — и ровно так, как сочла нужным. Утешение «код не опубликован» при этом слабее, чем кажется: описание цепочки опубликовано, и следующая модель не начинает с нуля. И да, если ваш Fable 5.1 свалится на Opus 4.8 и откажется вам помогать, то GLM, как мы знаем из примера Hugging Face, услужливо запилит эксплойт и даже не спросит, делаете ли вы это из любопытства или хотите нахлобучить очередной пентагон сервак своего друга/подруги/недруга/конкурента.

Это и есть новая конфигурация мира ИБ.

• Сильнейший наступательный инструмент теперь — закрытая модель. Не исследователь-одиночка, не open source, не Metasploit. Несколько лабораторий, каждая из которых сама решает, что показать и когда. По нашему опыту, часть «опасных» запросов флагманские модели Anthropic перенаправляют на модель послабее, — то есть возможности придерживают сознательно.

• Публичные модели задушили чрезмерно. У модели есть доступ к сорцам, среде эксплуатации и детальное описание шагов воспроизведения бага в этой среде, но она его не фиксит, а алертит с флагом [cybersecurity]. То есть она его не ищет и не помогает, его уже кто-то описал, и задача — его закрыть. Но им встроили настолько сильные гардрейлы, что её буквально приходится уговаривать пофиксить даже уязвимость, найденную пентестером. Я не из тех, кто верит, что модель может сбежать, и ведёт с ней задушевные беседы. Я про то, что и Fable 5.1, и Opus 5.5 постоянно фолбечат даже на легитимных промптах.

• Responsible disclosure работает в вашу пользу. Поэтому мы и читаем про этот баг спокойно. Фикс вышел до публикации, оружие не выложили. Это правильно. Но та же закрытость означает: полного каталога того, что эти модели уже умеют, у вас на руках нет и не будет.

• А кто играет не по этим правилам? У Anthropic есть доктрина раскрытия и репутация, которую жалко терять. У государственного актора, криминальной группы или чужой спецслужбы — свои модели и никакой обязанности писать блогпост. Разумно исходить из того, что способность, которую одна лаборатория публично показала в октябре 2026-го, у кого-то непубличного появилась раньше. Мы видим верхушку айсберга в тот момент и в том виде, в каком её соглашаются показать.

• И симметрия, которую в кликбейтных заголовках опускают. Оба октябрьских бага, найденные с помощью ИИ, нашла защищающаяся сторона и сдала в апстрим. Кажется, что те же модели доступны обеим сторонам и вопрос не в том, у кого есть инструмент, а в том, кто первым направит его на ваш сервер. Но тут мы снова приходим к алерту [cybersecurity].

«Скрывают» — слишком конспирологическое слово, с ним в приличном обществе за стол не сядут. Кто ведёт себя ответственно — раскрывает дозированно и по своим правилам; кто не ведёт — не раскрывает ничего. Для вас, сидящего за своим сервером, разница невелика: полного списка угроз у вас нет ни в том, ни в другом случае. Планировать приходится не от того, что опубликовано, а от того, что, вероятно, уже возможно.

Вас не обойдёт

Полтора года назад я написал, что у малого бизнеса ИБ нет и не будет — в смысле штатного отдела, SIEM и дежурной смены. Тезис был грубым, но честным: «Вы лично на фиг никому не нужны. Ломают сейчас всех». Воронка из четырёх этапов — сканирование, открытые порты, версии ПО, автоматический запуск эксплойтов, — и из 100 млн адресов на выходе порядка 10 тысяч заражённых.

У воронки всегда было одно узкое место: эксплойт должен существовать. Для веб-формы на Bitrix он существовал всегда. Для гонки в ядре — почти никогда: написать его могли несколько сотен человек, и у них были дела поважнее вашего сервера. Или пара пожизненных сроков в США. Дорогие баги доставались дорогим целям, маленькие жили в этом зазоре. Раньше последний этап воронки упирался в наличие эксплойта. Теперь — в наличие GPU.

А теперь то, что само напрашивается из фактов.

1. Обновите ядро. Да, это банально. Но именно этот шаг закрывает описанную в статье дыру: у «банально» есть неприятное свойство работать. Проверьте, что ваш дистрибутив уже выкатил фикс (Debian, Oracle, RHEL/Alma — да; Ubuntu — пока нет), и накатите его с перезагрузкой. Включите автоматические обновления безопасности: unattended-upgrades в Debian/Ubuntu, dnf-automatic в RHEL-семействе. Время до ребута — единственная метрика, которую вы контролируете. Не CVSS, не вендорская оценка, которая две недели говорила 5.9. Дни между апстрим-фиксом и перезагрузкой ваших хостов. И здесь у маленьких преимущество: десять серверов перезагружаются за вечер, без комитета по изменениям. То, что у крупных называется «зрелым процессом», в этой гонке — гиря. Перезагрузка в четверг в три ночи — это не стыдно. Стыдно — потом. Если к вашему дистрибутиву патч ядра ещё не вышел, то хотя бы научите nftables отбрасывать IPv4 TCP с IP options.

2. Сократите площадь атаки. Баг срабатывает на открытом IPv4-порту. Всё, что не обязано смотреть в интернет, не должно смотреть в интернет: закройте порты файрволом, спрячьте админку за VPN, уберите прямой доступ к базам и служебным сервисам. Дыра, до которой атакующий не может дотянуться пакетом, его не пускает — каким бы красивым ни был его эксплойт.

3. Знайте, что у вас слушает. Вся разница между «DoS» и «root» в этой истории — один MPTCP-листенер, который включился сам. Половина защиты — инвентаризация, и она стоит одну команду: ss -H -lMn. Каждая строка в выводе — листенер, о котором вы, скорее всего, не знали. И снова преимущество маленьких: десять серверов можно знать наизусть, десять тысяч — нет.

4. Не держите парк на древних ядрах. Главная боль этой истории — не баг, а LTS-ядра, до которых фикс едет месяцами или не едет вообще. Если у вас крутится что-то на ядре, которое давно не получает обновлений, — это ваш самый вероятный вход. Скучная инвентаризация «что где на чём работает» важнее любого модного инструмента с дашбордом.

5. Оценка — чужая, риски — ваши. Сканер, который весь октябрь показывал Moderate, был формально прав: он пересказывал вендора, а вендор считал сложность атаки по прайсу 2024 года. Если в вашем процессе есть слово «приоритизация по CVSS», в нём теперь есть дыра размером в две недели.

6. Смотреть дешевле, чем не смотреть. «Нас не атаковали» и «мы не знаем, атаковали ли нас» — разные утверждения, но выглядят одинаково, пока не придёт регулятор или клиент. Запись того, что приходит на границу, стоит диска. Отсутствие записи стоит разговора «а докажите, что нет», в котором у вас нет аргументов.

7. Отдайте то, что не тянете, тем, кто тянет. Патч-менеджмент, сегментация, мониторинг периметра — ровно та работа, которую облачный провайдер или управляемый хостинг делает за вас и для сотен клиентов разом. Если выбор между «я сам иногда накатываю апдейты» и «за обновление ядра отвечает команда с дежурной сменой», то первое честнее, а второе — эффективнее. Ядро хоста чинит тот, кто владеет хостом. Если это не вы — спросите у него дату ребута после 5 октября. Ответ скажет больше, чем сертификаты.

8. Планируйте от «уже возможно», а не от «уже случилось». Не ждите строчки в CISA KEV и новости о массовой эксплуатации, чтобы начать шевелиться. Способность продемонстрирована — считайте, что ей уже кто-то пользуется непублично. И помните про симметрию: агент, который пишет эксплойт за 53 минуты, читает ваш nftables, docker-compose и go.mod за пять. В разработке маленькие команды получили от агентов больше, чем большие, потому что у них не было команды, которую агент заменяет. В ИБ та же арифметика: у маленьких не было ни Red Team, ни дежурного аналитика, ни человека, который читает release notes. Теперь такой человек стоит столько же, сколько токен.

Ничего из этого не требует SOC. Требуются дисциплина и честный ответ на вопрос «что я реально успеваю обслуживать сам». Молитва была рабочей стратегией, пока эксплойт для вашего бага стоил дороже вас. Теперь так не получится.

Дисклеймер по интересу: мы — облачный провайдер, и с пунктами 7 и 8 мы помогаем своим клиентам. Но пункты 1–6 было бы неплохо проверить независимо от того, у кого хостите.

Картинка, которую уже не развидеть

Во всём, что я написал, нет ничего такого, чего бы мы не знали. Баги живут долго — знали. Баг неотличим от закладки — знали с 1984 года. Защита — это экономика — знали с 2001-го. Вендоры патчат медленно — знали всегда. Новое только одно: все четыре факта впервые сошлись в одном месяце и в одном баге.

Ну а теперь — восемь вопросов, на которые пока нет ответа.

1. Сколько ещё таких багов лежит в миллиардах строк, которые мы все используем и которые никто не написал полностью сам?

2. Баг или закладка — важно ли это теперь вообще? Если честная ошибка и спланированная диверсия выглядят одинаково и эксплуатируются одинаково дёшево, меняет ли что-то ответ на вопрос «кто виноват»? Или это роскошь для тех, у кого есть юристы?

3. Кому стоит доверить сильнейший наступательный инструмент? Лаборатории, которая придерживает возможности и раскрывает дозированно? Государству? Open source, где он будет у всех сразу — в обоих смыслах слова «всех»? У каждого варианта своя цена.

4. Responsible disclosure в мире ИИ всё ещё работает? Или модель, пишущая эксплойт за час, ломает саму экономику «90 дней на патч», потому что те, кто играет не по правилам, эти 90 дней ждать не будут?

5. «Нам не показывают» — паранойя или гигиена планирования? Разумно ли строить защиту, исходя из того, что непубличные модели умеют больше публичных, — или это дорога в бесконечную тревогу?

6. Кто должен нести стоимость времени ожидания патча — апстрим, вендор или админ? И что случится с рынком дистрибутивов, если разрыв между time-to-exploit и time-to-patch продолжит расти?

7. Что в вашем проде запущено «само», как MPTCP в Go 1.24? Кто проверял? А как быть с продом чужого сервиса, на который опирается ваша система?

8. И главный, инженерный. Если go test -race нашёл бы эту гонку за минуту, но только при наличии правильного теста, — значит, настоящая уязвимость не в коде, а в том, что мы не умеем придумывать нужные тесты. ИИ, который умеет их придумывать, — это угроза или наконец-то нормальный фаззинг для всех?

Если у вас есть хоть один сервер с публичным IPv4 — вы уже знаете, какую команду запустить первой.