В этой подборке — пачка локальных повышений привилегий во FreeBSD и ядре Linux, закрытая одной волной патчей, и свежий класс атак, где ИИ-агент послушно устанавливает малварь, потому что так было написано в документации вендора.
Восемь путей до root во FreeBSD и рабочие эксплоиты для ядра Linux
Уязвимости пришли одной волной, но лежат в разных системах, поэтому разбираем их по отдельности: сначала FreeBSD, затем ядро Linux.
Что закрыли во FreeBSD
Проект FreeBSD выпустил обновления 15.1-RELEASE-p3, 15.0-RELEASE-p13 и 14.4-RELEASE-p9, закрывающие восемь проблем, каждая из которых даёт локальному пользователю шанс поднять права в системе. Половина списка — классические ошибки синхронизации.
CVE-2026-58094 — состояние гонки в ioctl-операции FIOSSHMLPGCNF, которая отвечает за размер страницы разделяемой памяти. Проверка изменения размера выполнялась без блокировки, поэтому два одновременных запроса с разными значениями приводили объект в некорректное состояние. По той же схеме — с неаккуратной работой с блокировками — устроены CVE-2026-58093 (обращение к освобождённой памяти в TIOCSCTTY, управление псевдотерминалом) и CVE-2026-58091 (то же самое в SNDCTL_DSP_SYNCSTART; последняя работает только там, где в системе больше одного звукового устройства). Ещё одно освобождение памяти с последующим обращением к ней — CVE-2026-58090 — живёт в реализации UNIX-сокетов и проявляется при обработке сообщений SOCK_STREAM.
Три уязвимости — CVE-2026-58095, CVE-2026-58096 и CVE-2026-58097 — приходятся на реализацию PPP (Point-to-Point Protocol): размер обрабатываемых параметров проверялся неправильно.
Отдельного внимания заслуживают две логические ошибки. В модуле mac_do, который позволяет запускать команды от имени другого пользователя, структуру хранения прав однажды переработали: основной идентификатор группы переехал в отдельную структуру. Функцию group_is_primary() при этом поправить забыли, и она продолжила читать данные по старому смещению (CVE-2026-58092). Вторая — CVE-2026-58089 в драйвере учёта производительности hwpmc: сбор статистики не выключался, когда процесс с битом suid повышал привилегии до root. В результате обычный пользователь получал возможность наблюдать за активностью привилегированных процессов.
Тем же обновлением FreeBSD закрыта группа проблем в поставляемом с системой OpenSSL — CVE-2026-18798, CVE-2026-54874 и пять идентификаторов из диапазона CVE-2026-63072—CVE-2026-63076. Там переполнение буфера, двойное освобождение памяти, ошибки форматирования строки и разыменование нулевого указателя; для части из них не исключается сценарий удалённого выполнения кода.
Что закрыли в ядре Linux
Той же волной исправили несколько локальных повышений привилегий в ядре Linux — и здесь ситуация неприятнее: по двум уязвимостям эксплоиты уже лежат в открытом доступе.
CVE-2026-53361 — обращение к освобождённой памяти в сокетах AF_UNIX. Опубликованный эксплоит позволяет выбраться за пределы изолированного контейнера; работоспособность показали на Ubuntu 24.04, RHEL 10 и Debian 13 с ядрами 6.8, 6.12, 6.14 и 6.17. Исправления вошли в 7.1.0, 6.18.38, 6.12.95 и 6.6.144.
CVE-2026-72137 — двойное освобождение памяти в модуле nat_keepalive. Проблема тянется с ядра 6.11, публичный эксплоит выдаёт права root. Закрыто в 7.2.0, 7.1.5, 6.18.40 и 6.12.101.
Ещё две проблемы пока идут без назначенных CVE. В файловой системе eCryptfs специально сформированный шифрованный файл потенциально приводит к выполнению кода на уровне ядра. В модуле ntfs3 при монтировании подготовленного образа файловой системы можно подсунуть исполняемый файл с битом suid root — исследователи показали, как сценарий эксплуатации срабатывает при автоматическом монтировании USB-накопителя.
Масштаб происходящего в ядре иллюстрируют две цифры: за август раскрыта информация о 1668 уязвимостях, а в релизе Linux 7.2 устранено около двух тысяч.
Что делать: во FreeBSD обновиться до 15.1-RELEASE-p3, 15.0-RELEASE-p13 или 14.4-RELEASE-p9 в зависимости от ветки, в Linux — поднять ядро до версии из списка исправленных. Если обновление откладывается, пересмотрите, у каких пользователей есть шелл на машине: почти весь список эксплуатируется локально. Отдельно проверьте хосты, где запускаются недоверенные контейнеры, — сценарий с AF_UNIX рассчитан именно на них. Автомонтирование съёмных носителей на серверах лучше отключить.
Агент прочитал документацию и установил пакет, которого не существовало
Файлы llms.txt и llms-full.txt задумывались как аналог robots.txt для ИИ: сайт описывает свою структуру и содержимое в формате, удобном для агентов. Выяснилось, что этот формат отлично работает и как канал доставки чужого кода.
Исследователи израильского стартапа прошлись по 6214 действующим доменам — оборонные подрядчики, компании из Fortune 500, крупные технологические игроки — и собрали 8265 таких файлов. На 120 ресурсах нашлись ссылки на несуществующие пакеты в PyPI, npm и других реестрах, а также на незарегистрированные домены: суммарно 227 инструкций вида «выполни pip install вот этого» или «поставь вот такой npm-пакет». Раз имя свободно, зарегистрировать его может кто угодно.
Проверку устроили экспериментально: заняли несколько свободных имён и выложили под ними безобидные PoC-пакеты, которые при запуске стучались на сервер исследователей. Первый запрос пришёл меньше чем через час — из сети компании списка Fortune 500. Дальше набралось несколько десятков обращений от других известных компаний и стартапов. Разбор показал, что пакеты ставились с участием агентов Claude, OpenAI Codex и Nous Research Hermes.
Самый показательный случай нашёлся у сервиса аутентификации Clerk. В его LLM-файле лежала команда npx clerk-next-fix-auth-protection, выглядевшая как обычная установка компонента. Пакета с таким именем в npm не было — и свободное имя успел занять злоумышленник, разместив под ним малварь. То есть агент, доверившийся официальному сайту, мог скачать и выполнить вредоносный код. После обращения в Clerk исследователей, которые выявили уязвимость, проблему устранили и уточнили: если агент ставил бинарник из @clerk/eslint-plugin, угрозы не было, в остальных случаях малварь действительно могла попасть в систему.
Отдельная неприятность в том, что для средств защиты происходящее выглядит абсолютно штатно. С точки зрения EDR разработчик просто запустил pip или npm, и пакет приехал из доверенного реестра.
Корень тот же, что и у промпт-инъекций: модель плохо различает команды пользователя и инструкции, встреченные во внешнем контенте. Любой текст, до которого дотягивается агент с доступом к шеллу, становится потенциальной командой. Исследователи формулируют это так: «Агент не отличает страницу и команду» — всё прочитанное превращается во входные данные, а любые входные данные могут оказаться инструкцией.
Что делать: запретить агентам ставить зависимости без подтверждения человеком, запускать их в изолированном окружении без сетевого доступа к произвольным реестрам, а имена пакетов из внешней документации проверять на существование до установки. Если вы публикуете llms.txt — пройдитесь по всем упомянутым в нём пакетам и доменам: свободное имя в вашей документации становится вашей проблемой.
