В большую подборку собрали инциденты, на которые стоит обратить внимание.
Компрометация библиотеки LiteLLM в PyPI: выпущены вредоносные версии 1.82.7 и 1.82.8.
Разработчики Python-библиотеки LiteLLM сообщили о компрометации проекта. Атакующие перехватили учётные данные сопровождающего LiteLLM и опубликовали в PyPI два вредоносных выпуска (1.82.7 и 1.82.8), содержащих код для кражи ключей и паролей. Вредоносные версии удалены из PyPI, проект временно заморожен.
Токен доступа к учётной записи LiteLLM в PyPI был получен через компрометацию проекта Trivy (атакующие воспользовались уязвимостью в обработчике pull_request_target). 24 марта в 11:30 (MSK) перехваченные учётные данные использовали для прямой публикации вредоносных релизов в PyPI в обход официального GitHub CI/CD. Репозиторий на GitHub не пострадал.
В версии 1.82.7 вредоносный код встроен в litellm/proxy/proxy_server.py, активируется при импорте litellm.proxy. В версии 1.82.8 добавлен файл site-packages/litellm_init.pth и в proxy_server.py добавлен обработчик в base64, активируемый при любом запуске.
Вредоносный код сканирует систему: ключи SSH и SSL/TLS, переменные окружения, учётные данные AWS, GCP, Azure, K8s, ключи криптокошельков, пароли СУБД, историю команд, файлы конфигурации Git, CI/CD, пакетных менеджеров, Docker.
Найденные данные шифруются (AES-256-CBC + RSA-4096) и отправляются POST-запросом на https://models.litellm.cloud/ (домен зарегистрирован за несколько часов до публикации).
Как защититься:
- Убедиться, что в каталоге site-packages нет файла litellm_init.pth.
- В случае установки версий 1.82.7 или 1.82.8 обновить все ключи и учётные данные.
- Закрепить конкретные версии LiteLLM в параметрах загрузки зависимостей.
- Сверить используемые выпуски LiteLLM с кодом релизов на GitHub.
Уязвимости в snapd и Rust Coreutils, позволяющие получить root-привилегии в Ubuntu
Компания Qualys выявила сразу две уязвимости, позволяющие получить root-привилегии в Ubuntu.
В snapd (CVE-2026-3888) — проблема в связке snap-confine и systemd-tmpfiles. Атакующий ждёт периодической очистки /tmp (раз в 10–30 дней), после удаления каталога /tmp/.snap подменяет его и размещает изменённые библиотеки. При формировании sandbox-окружения snap-confine эти библиотеки монтируются с правами root. Затем внутри sandbox-окружения копируется /bin/bash в каталог snap с установкой suid-бита (04755) — запуск этого файла из основной системы даёт полный root-доступ.
В uutils coreutils (Rust Coreutils) — состояние гонки в утилите rm. При рекурсивном удалении она сначала проверяет каталоги, затем удаляет их в обратном порядке. Атакующий подменяет родительский каталог на символическую ссылку после проверки, но до вызова rmdir(), что позволяет удалить любой каталог в системе (например, /tmp/snap-private-tmp/.../.snap). Далее используется тот же метод получения root, что и в первой уязвимости.
Как защититься:
- Для snapd: установить обновление пакета snapd версии 2.75 (исправление уже доступно).
- Для uutils coreutils: обновиться до версии 0.3.0; в Ubuntu 25.10 проблема временно обойдена поставкой /usr/bin/gnurm вместо uutils rm.
Масштабная атака на цепочку поставок GlassWorm: скомпрометировано более 400 репозиториев и расширений на GitHub, npm и Open VSX
Исследователи обнаружили 433 скомпрометированных компонента: 200 Python‑репозиториев и 151 JS/TS‑репозиторий на GitHub, 72 расширения для VS Code и Open VSX, 10 npm‑пакетов. Конечная цель — распространение инфостилера на JavaScript для кражи криптовалютных кошельков, учётных данных, SSH‑ключей и токенов.
Впервые червь был обнаружен в октябре 2025 года. В первой волне использовались невидимые Unicode‑символы (Private Use Areas), которые скрывали вредоносный код: небольшой декодер извлекал байты и передавал в eval(). Впоследствие были обнаружены ещё несколько атак.
В новой волне злоумышленники злоупотребляют полями extensionPack и extensionDependencies в манифесте расширений Open VSX: публикуется безобидное расширение, затем в обновлении добавляется зависимость от вредоносного, и редактор автоматически устанавливает его.
Также применяется компрометация через украденные токены GitHub: в Python‑репозитории делается force‑push вредоносных коммитов (например, в setup.py или main.py) с сохранением оригинальной даты и сообщения, что позволяет скрыть следы взлома.
Вся малварь использует общую инфраструктуру — один адрес кошелька Solana, который опрашивается каждые пять секунд для получения инструкций. Кроме кражи данных, GlassWorm может разворачивать SOCKS‑прокси и скрытые VNC‑серверы, давая операторам удалённый доступ.
Разработчикам рекомендуется:
- Проверять кодовую базу на наличие переменной lzcdrtfxyqiplpd, файла ~/init.json (используется для закрепления в системе), подозрительных установок Node.js в домашней директории.
- Искать файлы i.js в недавно клонированных проектах.
- Просматривать историю коммитов Git на предмет аномалий.
Критическая уязвимость в патче GSSAPI для OpenSSH позволяет атаковать серверы до аутентификации
Во многих дистрибутивах Linux используется патч gssapi.patch, добавляющий в OpenSSH поддержку обмена ключами на базе GSSAPI. В этом патче исследователи выявили критическую уязвимость (CVE-2026-3497).
Ошибка приводит к разыменованию указателя, повреждению памяти и может эксплуатироваться удалённо на стадии до аутентификации. Исследователь, обнаруживший уязвимость, продемонстрировал аварийное завершение процесса через отправку одного модифицированного пакета. Однако нельзя исключать и более опасную эксплуатацию. На данный момент проблема подтверждена в Debian и Ubuntu, другие дистрибутивы проверяются.
Причина появления уязвимости — ошибка в функции sshpkt_disconnect(), из-за которой процесс не завершается после поступления disconnect-сообщения. Атакующий на стадии согласования ключей отправляет непредусмотренный тип GSSAPI-сообщения. Сервер помещает его в очередь, не инициализируя переменные соединения. Затем в цикле обработки программа читает неинициализированную структуру recv_tok из стека (фактически, данные от прошлых вызовов), отправляет её через IPC и передаёт в gss_release_buffer(), которая вызывает free() для случайного указателя, что приводит к повреждению памяти.
CrackArmor: серия уязвимостей в AppArmor позволяет получить root-права и выйти из контейнеров
Компания Qualys выявила 9 уязвимостей в системе мандатного управления доступом AppArmor (кодовое имя CrackArmor), присутствующих в ядре Linux с версии 4.11 (2017 год). Наиболее опасные из них позволяют локальному непривилегированному пользователю получить root-права, выйти из изолированных контейнеров и обойти ограничения AppArmor. Успешная эксплуатация продемонстрирована в Ubuntu 24.04 и Debian 13.
Проблемы вызваны фундаментальной уязвимостью класса «обманутый посредник» (confused-deputy). Она позволяет непривилегированным пользователям загружать, менять и удалять произвольные профили AppArmor через запись в псевдофайлы /sys/kernel/security/apparmor/.
Атака для получения root-привилегий строится так:
- Злоумышленник заменяет профиль для утилиты sudo на новый, который блокирует системный вызов setuid (CAP_SETUID).
- При возникновении ошибки sudo пытается отправить письмо администратору через /usr/sbin/sendmail.
- Из-за заблокированного setuid sendmail запускается с правами root.
- Через переменную окружения MAIL_CONFIG атакующий подменяет конфигурацию почты, заставляя систему выполнить свой вредоносный скрипт postdrop с правами root.
Также упоминаются уязвимости на уровне ядра: двойное освобождение памяти (double free) и обращение к освобожденной области (use-after-free) в коде загрузки профилей, что потенциально позволяет перезаписать содержимое /etc/passwd.
Патчи с устранением уязвимостей переданы разработчикам ядра Linux и будут предложены пользователям в ближайшие дни в составе обновлений ядра (версии 6.18.18, 6.19.8, 6.12.77, 6.6.130, 6.1.167, 5.15.203 и 5.10.253). Исправление уже включено в обновления пакетов с ядром для Ubuntu. Кроме того, для Ubuntu выпущены обновления пакетов sudo, sudo-ldap и util-linux, устраняющие недоработки, позволявшие эксплуатировать уязвимость в AppArmor. В Debian обновление находится в процессе подготовки.
В SQLite обнаружена и исправлена редкая ошибка «WAL-reset bug», приводящая к повреждению БД
Хотим напомнить: 13 марта вышел корректирующий выпуск СУБД SQLite 3.51.3, в котором устранена ошибка, приводящая к повреждению базы данных («WAL-reset bug»). Из-за проблем с обратной совместимостью предыдущая версия 3.52.0 была отозвана. Ошибка присутствует во всех версиях начиная с 3.7.0 (июль 2010 года) и до 3.51.2 включительно. Также выпущены исправления для более ранних версий 3.44.6 и 3.50.7.
Предыстория: 3 марта один из разработчиков SQLite обнаружил и устранил ошибку, которая в редких случаях могла приводить к повреждению базы данных. Эта ошибка возникала только в базах данных, работающих в режиме WAL (Write-Ahead Logging), при одновременном доступе двух и более подключений в разных потоках или процессах, пытающихся выполнить запись или создать контрольную точку.
Разработчикам не удалось воспроизвести ошибку в естественных условиях — для проверки исправления им пришлось добавлять в SQLite специальную тестирующую логику, искусственно создающую условия для сбоя.
Для защиты советуем обновить SQLite до версии 3.51.3, 3.50.7 или 3.44.6 в зависимости от используемой ветки.
Возможно, вам будет интересно
