Критическая уязвимость в GitLab уже под атакой, Forgejo выполнял чужой код из шаблона репозитория, а шифрование памяти Intel и AMD пробивают устройством за $200 без надежды на патч.
GitLab: критическая уязвимость позволяет читать файлы сервера без пароля
GitLab выпустила патчи для CVE-2026-85706 — уязвимости с максимальной оценкой 10 баллов по шкале CVSS. Она позволяет атакующему без аутентификации читать произвольные файлы на сервере. Злоумышленники ждать не стали: по данным специалистов по безопасности, попытки эксплуатации начались вскоре после публичного раскрытия.
Уязвимость относится к классу path traversal (выход за пределы разрешённого каталога) и находится в API коммитов репозитория. Как объясняют в GitLab, сработали сразу две ошибки: пути к файлам ограничиваются некорректно, а проверки аутентификации там нет вовсе. Учётные данные атакующему не нужны, достаточно, чтобы на уязвимом инстансе был хотя бы один публичный проект. Так злоумышленник добирается до логов и конфигурационных файлов GitLab, а в них часто лежат доступы, токены, секреты и другая чувствительная информация.
Проблема затрагивает Community Edition (CE) и Enterprise Edition (EE): все версии с 18.7 по 19.1.7 включительно, а также ветки 19.2 — до 19.2.5 и 19.3 — до 19.3.1. Уязвимые серверы ищут с 11 сентября, а первые атаки начались через несколько часов после раскрытия. Эксперты ждут, что скоро они станут массовыми.
Одновременно GitLab закрыла ещё одну критическую уязвимость — CVE-2026-87719 с оценкой 9,9 балла. Она касается только Enterprise Edition: обработчик GraphQL-подписок небезопасно десериализует данные. Аутентифицированный пользователь с доступом к Duo Chat может передать специально подготовленный аргумент и получить настройки Advanced Search вместе с учётными данными.
Что делать: обновиться до 19.3.2, 19.2.6 или 19.1.8 — в этих версиях закрыты обе уязвимости. На GitLab.com исправленная версия уже работает, от пользователей GitLab Dedicated действий не требуется. Администраторам self-managed-инстансов, особенно доступных из интернета, стоит обновиться как можно скорее. Если сделать это сразу не получается, ограничьте публичный доступ к инстансу и проверьте логи: о попытках эксплуатации могут говорить подозрительные POST-запросы к /api/v4/projects/{id}/repository/commits/ с параметрами file.path.
Forgejo: шаблон репозитория, который запускает код на сервере
Для платформы совместной разработки Forgejo вышли корректирующие выпуски 16.0.4 и 15.0.8. Они закрывают критическую уязвимость CVE-2026-89094, через которую удалённый атакующий мог выполнить свой код на сервере.
Проблема связана с созданием репозитория из шаблона. Чтобы через шаблон нельзя было передать серверу собственные команды, платформа удаляет из него служебный подкаталог .git/ и только после этого инициализирует git-репозиторий. Слабым местом оказался порядок операций. Файлы в директории .forgejo/template поддерживают подстановку переменных, и она выполнялась уже после чистки. Подставив в путь к файлу, например, “../../.git/hooks”, атакующий заново создавал подкаталог .git/ — уже со своим содержимым. При инициализации Git подхватывал оттуда настройки, а среди них могли оказаться операции, запускающие произвольные процессы.
В исправленных версиях .git/ удаляется не до раскрытия переменных, а непосредственно перед запуском git init, когда подложить что-то в каталог уже не выйдет. Похожую уязвимость, CVE-2026-25718, ещё в феврале закрыли в Gitea 1.25.5.
Что делать: срочно обновить Forgejo до 16.0.4 или 15.0.8 и проверить сервер на следы компрометации: не появлялись ли репозитории из незнакомых шаблонов, нет ли посторонних процессов и изменений в системе. Тем, кто работает с Gitea, стоит убедиться, что установлена версия не ниже 1.25.5.
DDRop: устройство за $200 обходит шифрование памяти Intel TDX и AMD SEV-SNP
Международная группа исследователей описала атаку DDRop на аппаратное шифрование оперативной памяти. Она пробивает защиту Intel TDX, Scalable SGX и AMD SEV-SNP — технологий, на которых строятся доверенные среды выполнения (TEE). Для атаки нужен физический доступ к машине.
Масштабируемые системы шифрования памяти не проверяют криптографическую «свежесть» данных, то есть не могут надёжно определить, актуальна ли версия, которая сейчас лежит в памяти. Поэтому туда можно вернуть устаревшее содержимое, и оно корректно расшифруется. Корень проблемы — в компромиссе: чтобы шифровать большие объёмы памяти, производители отказались от части механизмов, гарантирующих уникальность и актуальность каждой версии данных.
На этом и построена атака. Исследователи собрали аппаратный модуль-посредник, который подключается между процессором и оперативной памятью и незаметно блокирует запись в зашифрованные области на шине DDR5. Защищённая виртуальная машина продолжает работать со старыми данными и не замечает подмены, а скорость шины при этом не страдает.
Дальше, по словам авторов, всё зависит от того, какие данные подменить. Специально подготовленные записи в таблице страниц переводят любую защищённую ВМ в режим отладки — и её закрытую память можно прочитать открытым текстом. Запись в служебные структуры метаданных TDX позволяет подделывать отчёты об аттестации: ВМ с бэкдором в глазах удалённого пользователя по-прежнему выглядит надёжной. Исследователи подчёркивают, что DDRop — первая атака, которая компрометирует доверенный интерфейс управления TDX без эксплуатации программных уязвимостей.
Раз без физического доступа не обойтись, находка важна прежде всего для сценариев, в которых облачные провайдеры гарантируют клиентам конфиденциальность вычислений на аппаратном уровне. Простого решения для актуальных систем нет — ни аппаратного, ни программного. Intel и AMD признали проблему, но отнесли её к сценариям за пределами своих моделей угроз для облачных вычислений. AMD никаких мер принимать не намерена, а Intel изучает способы обнаруживать такие атаки и архитектурно усилить будущие платформы.
Что делать: патча не будет, поэтому остаётся пересмотреть модель угроз. Шифрование памяти в процессорах Intel и AMD больше не защищает данные от того, кто может физически добраться до сервера, — это стоит учитывать при оценке рисков. Поэтому физический доступ к серверам по-прежнему нужно надёжно ограничивать.
