Исследователь Малькольм Стэгг показал на Black Hat USA 2026, что атаки NatJack позволяют перехватывать активные TCP-сессии, подменять DNS-ответы и даже выбивать из строя таблицы NAT. Для русскоязычных IT-команд это неприятный сигнал: NAT, который многие привыкли считать скучной сетевой прослойкой, сам оказался точкой атаки, если рядом живут доверенные и недоверенные системы.
За работой стоят независимые исследования Стэгга в рамках SODIUM-24, и, как сообщает The Hacker News, проблема не упирается в один вендор или один стек. Затронуто поведение в отдельно разработанных реализациях NAT, включая Windows и Linux. Для двух конкретных ошибок уже выпущены CVE-2026-56181 с оценкой 8,3 по CVSS для Windows NAT в Hyper-V и CVE-2026-63913 с оценкой 8,2 для Linux Netfilter conntrack. Неприятная часть не в самих номерах. Неприятно то, что единого патча для всего класса атак нет, потому что NatJack бьет в само допущение, на котором давно живет множество NAT-реализаций. Именно это делает историю системной, а не еще одним частным багом в одном драйвере или одном домашнем роутере.
Это допущение простое: хосты за одним NAT как будто не должны вмешиваться в состояние соединений друг друга. Стэгг показал, что злоумышленник, который контролирует систему по ту же сторону NAT, при определенных условиях может трогать чужие записи conntrack. Дальше начинается неприятная математика состояний: можно заменить mapping и увести трафик уже активной TCP-сессии на себя, можно сорвать DNS-запрос жертвы так, чтобы настоящий ответ ушел атакующему, а обратно прилетел поддельный, можно вытащить наружу сведения о внешне отображенных портах, а можно просто забить таблицу NAT поддельными потоками и лишить легитимных клиентов новых соединений. По сути, исследователь показывает, что stateful-логика внутри транслятора адресов иногда доверчива больше, чем стоило бы.
Сценарий важный, но не магический. Для NatJack обычно нужен привилегированный доступ к системе, которая уже находится за тем же NAT, что и жертва. Это снижает драматизм заголовка, но не делает риск академическим. Виртуальные машины на одном хосте, смешанные сегменты с доверенными и недоверенными рабочими нагрузками, внутренние сервисы без шифрования, лабораторные и тестовые контуры: именно там модель доверия чаще всего держится на предположении, что внутри периметра никто не будет ковырять чужой сетевой state. Если в одном контуре рядом сидят подрядчик, агент мониторинга, тестовая VM и чувствительный сервис, одного успешного закрепления уже достаточно, чтобы превратить внутреннюю сеть в удобный плацдарм для подмены. На 7 августа 2026 года публичных данных об эксплуатации NatJack в реальных атаках не было, но для инфраструктурных команд это слабое утешение.
С Linux картина довольно предметная. По данным записи CNA на kernel.org, специально собранная связка из SYN и RST-пакета с некорректным sequence number может преждевременно перевести активную запись Netfilter NAT в закрытое состояние, потому что логика conntrack некорректно проверяла направление пакета. Исправления уже попали в стабильные ветки 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12 и 7.1. Но сам Стэгг отдельно оговаривает неприятный нюанс: патч закрывает конкретную ошибку в коде, а более широкий прием с downstream-spoofing не убирает полностью, лишь повышает сложность атаки. То есть обновление обязательно, особенно для долгоживущих LTS-веток, но после него сеть не стоит считать автоматически безопасной только потому, что нужный пакет уже приехал.
У Microsoft описание не менее прямое: ошибка проверки источника позволяет подмену трафика из соседней сети. Под обновление подпали Windows 11 24H2 до сборки 26100.8875, 25H2 до 26200.8875, 26H1 до 28000.2525 и Windows Server 2025 до 26100.33158. Рекомендации тоже без фокусов: ставить доступные обновления для Windows и Linux, не держать доверенные системы рядом с недоверенными на одном NAT, шифровать трафик даже внутри внутренней сети и, где это применимо, включать IP Source Guard. Synack добавляет еще одну неприятную деталь: техники тестировали на десятках реальных сетевых продуктов от разных вендоров и показали proof-of-concept в контролируемой среде. Полной открытой матрицы по продуктам пока нет, так что проверять свою инфраструктуру придется старым способом, руками и через собственные стенды. Для ИБ и DevOps это скорее чек-лист на пересборку внутренней гигиены, чем история в духе патч накатили и забыли.
Контекст у NatJack тоже не из ниоткуда. В исследовании NDSS 2024 уже показывали, что манипуляции с NAT-состоянием позволяют захватывать TCP-трафик, и тогда уязвимыми оказались 52 из 67 протестированных роутеров, а итогом стали десять CVE. NatJack развивает ту же линию и делает вывод еще неприятнее: stateful-сетевой слой уже нельзя считать нейтральной сантехникой, особенно когда на одном периметре живут гипервизоры, контейнеры, внутренний DNS и сервисы с разным уровнем доверия. Для разработчиков и платформенных команд это значит ровно одно: атаки NatJack добивают старую идею, что внутри сети можно жить на голом доверии. Если приложение до сих пор полагается на нешифрованный внутренний трафик, слабую сегментацию или логику типа «у нас же все за NAT», повод пересмотреть архитектуру стал заметно конкретнее. Для бизнеса это еще и вопрос размещения нагрузок: экономия на общей NAT-инфраструктуре может неожиданно превратиться в лишний класс внутренних рисков и более дорогую сегментацию постфактум.
Теперь главный вопрос не в том, появятся ли новые CVE для отдельных реализаций NAT. Вопрос в том, сколько еще сетевого кода строится на молчаливом допущении, что соседи за одним адресным транслятором ведут себя прилично. По мере того как инфраструктура смешивает VM, контейнеры и сервисы разного доверия, проверять придется уже не только открытые порты, но и поведение самого NAT под враждебным трафиком; отправной точкой может быть публикация .