Уязвимость ядра Linux с идентификатором CVE-2026-46333 затронула сразу несколько LTS-веток, начиная с 5.10, и позволяла локальному непривилегированному пользователю читать файлы, которые обычно доступны только root. Для администраторов, DevOps-команд и компаний с многопользовательскими Linux-серверами это не академическая неприятность, а вполне прикладной риск: из машины можно было вытянуть SSH-ключи, пароли и другие чувствительные данные без sudo и без красивой легенды про сложную APT-атаку.
Об инциденте сообщает The Register. Речь идет о локальной уязвимости: злоумышленнику нужен доступ к учетной записи на целевой машине, но дальше сценарий уже неприятный. По описанию Qualys и демонстрации с GitHub, проблема позволяла читать закрытые файлы, включая root-only секреты. Эксплойт даже получил рабочее имя ssh-keysign-pwn, и это тот случай, когда шутка у сообщества получилась быстрее, чем у многих команд — процесс обновления.
Что сломалось и кого это касается
По данным публикации, баг затрагивал LTS-ядра 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 и 7.0. То есть список получился почти образцово неудобным: именно на LTS-линиях живут продакшн-серверы, корпоративные дистрибутивы и инфраструктура, где «обновим потом» легко превращается в «почему у нас утекли ключи». Формально уязвимость локальная, но это слабое утешение для машин с shared-доступом, CI-воркеров, bastion-host, исследовательских кластеров, учебных стендов и любых сред, где на одном хосте живут несколько пользователей или сервисных учеток.
Суть бага — в механике, которая дала непривилегированному пользователю возможность читать то, что он читать не должен. В публикации The Register упоминается коммит Линуса Торвальдса 31e62c2 с описанием "ptrace: slightly saner 'get_dumpable()' logic" — именно он закрывает проблему. Само название исправления выглядит почти буднично, но такие будничные строки в changelog потом нередко оказываются намного важнее очередной громкой функции в релиз-нотах. Для практиков здесь вывод простой: если у вас ядро из затронутых веток и на машине есть локальные пользователи, вопрос уже не в том, «насколько это теоретично», а в том, поставлен ли патч.
Отдельно показателен таймлайн. Qualys сообщила о проблеме в списке рассылки oss-security в пятницу, на что обратил внимание Брэд Спенглер из grsecurity. Но в той же дискуссии Алтан Байг напомнил: корневая причина поднималась Яном Хорном в Linux Kernel Mailing List еще в 2020 году. Это, пожалуй, самый неприятный фрагмент истории. Не потому, что в ядре нашли баг — это случается. А потому, что сигнал был давно, а до полноценной развязки дошло только после появления уязвимости с понятным impact и готовым эксплойтом. Для индустрии это уже не баг в коде, а баг в маршрутизации безопасности: заметили, обсудили, не дожали.
Почему история шире одной CVE
The Register привязывает этот случай к более широкому тренду, который в Metabase когда-то метко назвали эпохой «strip-mining» open source security — когда исследователи и атакующие методично просеивают зрелые open source-проекты в поисках старых, тихо лежащих проблем. В последние месяцы у Linux и смежной экосистемы действительно выдался нервный сезон: новые названия багов появляются быстрее, чем у команд заканчиваются окна на патчинг. На этом фоне CVE-2026-46333 выглядит не исключением, а очередным напоминанием, что у зрелости open source есть обратная сторона: код старый, распространенный, критичный и слишком интересный для всех, кто умеет читать diff не хуже пресс-релиза.
На том же фоне в статье вспоминают ModuleJail — утилиту Джаспера Нюйенса, которая предлагает уменьшать поверхность атаки через автоматический blacklist неиспользуемых модулей ядра. Подход радикальный, но не без логики. Скрипт на POSIX shell смотрит, какие модули реально задействованы на хосте, оставляет базовый минимум и административный whitelist, а остальное заносит в modprobe.d как запрещенное к загрузке. Иными словами, если модуль системе не нужен, лучше сделать так, чтобы он вообще не смог внезапно понадобиться злоумышленнику.
Идея blacklist не нова: отключать ненужные модули советовали и раньше, в том числе в корпоративной документации и hardening-гайдах. Новизна ModuleJail в автоматизации. Для серверов с понятным, предсказуемым профилем железа и ролей это может быть вполне рабочей мерой. Для ноутбуков, рабочих станций и всего, куда админ сегодня воткнул USB-гарнитуру, а завтра сетевой адаптер, подход уже менее дружелюбен. Linux модульный именно затем, чтобы не перекомпилировать ядро под каждый новый сценарий жизни пользователя. Но у этой гибкости есть цена: все лишнее в ядре или рядом с ним потенциально расширяет поле для неприятных сюрпризов.
Здесь важен не только сам ModuleJail, сколько направление мысли. Чем меньше в продакшн-системе доступных, но неиспользуемых компонентов, тем уже пространство для эксплуатации подобных ошибок. Для бизнеса это означает довольно земной список действий: быстрее обновлять ядро, отделять многопользовательские машины от чувствительных контуров, минимизировать набор модулей и не хранить лишние секреты на хостах, где у локальных пользователей вообще есть шанс что-то запускать. Для разработчиков и платформенных команд вывод не менее прозаичен: модель «доверяем локальному пользователю, потому что он уже внутри VPN» продолжает стареть хуже, чем старые LTS-ядра.
Главный вопрос после этой истории не в том, будет ли еще одна похожая ошибка, а в том, сколько инфраструктуры по-прежнему строится на предположении, что локальный доступ без привилегий — это уже почти безопасно. Linux давно перестал быть системой только для одиночных админов с терпением к перекомпиляции ядра по выходным. Он управляет облаками, CI, контейнерными нодами и внутренними платформами, где один лишний баг в правах доступа быстро становится проблемой не одного сервера, а целого контура. Подробности первоисточника и контекст по ModuleJail собраны в материале .