Уязвимость Linux с идентификатором CVE-2026-46331 позволяет непривилегированному локальному пользователю подняться до root, не меняя файл на диске и не ломая проверку целостности. Для админов, DevOps и тех, кто держит shared-хосты, CI/CD-раннеры и Kubernetes-ноды, это неприятный сценарий: бинарник выглядит чистым, а root-shell уже открыт.
Проблема получила неофициальное имя pedit COW, и, как пишет The Hacker News, рабочий публичный эксплойт появился уже через сутки после присвоения CVE 16 июня. Ошибка находится в подсистеме traffic control ядра Linux, точнее в механизме packet editing через действие act_pedit. Red Hat оценила баг как important, что в переводе с вендорского языка обычно означает: откладывать патч до следующего квартала не стоит.
Технически это out-of-bounds write в функции, которая правит сетевые пакеты на лету. Логика должна была работать по обычному для ядра сценарию copy-on-write: сначала сделать приватную копию данных, потом уже менять байты. Но проверка диапазона записи происходит слишком рано, еще до того, как для части ключей становится известен финальный offset. В результате запись может уйти за пределы приватной копии и попасть в общую страницу page cache. Если в этом кеше лежит, например, setuid-бинарник /bin/su, эксплойт подмешивает в его образ небольшой payload, после чего запускает уже отравленную копию с root-правами. Сам файл на диске при этом остается нетронутым.
Это важный нюанс не только для специалистов по безопасности, но и для тех, кто привык полагаться на file integrity monitoring. Здесь проверка контрольных сумм не спасает, потому что компрометация происходит в памяти, а не в файловой системе. Сброс page cache очищает отравленную копию, но не отменяет факт взлома: если атакующий уже получил shell, машину нужно считать скомпрометированной. Иными словами, история не про «почистили кэш и поехали дальше», а про нормальный incident response со всеми вытекающими.
Для эксплуатации нужны два условия. Первое: модуль act_pedit должен быть доступен для загрузки. Второе: в системе должны быть разрешены непривилегированные user namespaces, чтобы локальный пользователь получил namespace-local capability CAP_NET_ADMIN, необходимую для запуска цепочки через tc. На протестированных целях оба условия сошлись. Автор PoC сообщил об успешной эксплуатации с переходом от непривилегированного пользователя к root на RHEL 10 и Debian 13 trixie, где unprivileged user namespaces включены по умолчанию. Ubuntu 24.04 тоже можно было атаковать, но с обходом через AppArmor-профили, которые еще допускают user namespaces. А вот Ubuntu 26.04 по умолчанию режет этот путь на уровне AppArmor, хотя само ядро, по данным публикации, остается уязвимым.
Список затронутых систем выглядит неприятно приземленно. Debian уже выпустила исправление для trixie через security-канал, но Debian 11 и 12 на момент публикации еще числились уязвимыми. Ubuntu помечает как затронутые поддерживаемые релизы с 18.04 по 26.04 по состоянию на 25 июня. Red Hat указывает RHEL 8, 9 и 10; RHEL 7 в бюллетене не фигурирует. Для бизнеса это означает простую вещь: риск выше всего там, где «локальный пользователь» не равен «доверенный сотрудник». Многоарендные серверы, build-воркеры, лабораторные машины, университетские кластеры, self-hosted CI и ноды с rootless-контейнерами здесь в первой очереди на обновление.
Контекст тоже показательный. pedit COW продолжает уже знакомую линейку багов, где быстрый путь в ядре пишет в страницу, которой не владеет эксклюзивно, и в итоге страдает page cache. В публикации вспоминаются Dirty Pipe, Copy Fail, DirtyClone и Dirty Frag. Новый тут не сам паттерн, а входная точка: эксплуатация завязана на сетевой traffic control и на то, что user namespace открывает локальному пользователю нужные привилегии внутри собственного пространства имен. Для kernel security это неприятный урок: патч, который внешне выглядел как рядовое исправление corruption bug и лежал в публичной рассылке netdev с конца мая, неделями не воспринимался как security-событие. CVE присвоили только после слияния фикса 16 июня, а оружейный PoC подъехал почти сразу.
Практические меры вполне конкретны. Первая и главная: ставить исправленное ядро и перезагружать хосты, потому что без reboot такие истории не заканчиваются. Если немедленный патч невозможен, остаются два временных варианта. Можно заблокировать загрузку act_pedit, предварительно проверив, используется ли модуль вообще. Либо отключить непривилегированные user namespaces через user.max_user_namespaces=0 на RHEL или kernel.unprivileged_userns_clone=0 на Debian и Ubuntu. Но тут начинается обычная операционная арифметика: вместе с атакой вы легко убьете rootless-контейнеры, часть CI-песочниц и некоторые браузерные sandbox-механизмы. Так что тестировать придется не только безопасность, но и собственную инфраструктурную совместимость.
Во всей истории больше всего раздражает разрыв между «локальная уязвимость» и реальным уровнем риска. В 2026 году локальный пользователь на shared-системе, раннере или k8s-ноде часто оказывается всего в одном шаге от всей платформы. Поэтому такие баги уже давно нельзя складывать в папку «не internet-facing, значит подождет». В случае с pedit COW проблема не только в конкретной , а в повторяющемся сценарии: детали фикса появляются публично раньше, чем рынок успевает осознать, что перед ним не просто corruption bug, а готовая дорожка к root.