КИБЕРБЕЗОПАСНОСТЬ

В 7-Zip закрыли уязвимость с запуском кода через XZ-архивы

В 7-Zip 26.02 закрыли CVE-2026-14266: специально собранный XZ-архив мог привести к выполнению кода при распаковке.

✍️ Редакция iTech News | 21.07.2026 | ⏱ 4 мин | Источник: The Hacker News

В 7-Zip закрыли опасную уязвимость 7-Zip, из-за которой специально подготовленный XZ-архив мог привести к выполнению кода на машине пользователя при распаковке. Для тех, кто в компаниях по привычке считает архиватор «безобидной утилитой с рабочего стола», новость неприятная: патч уже вышел, но сам 7-Zip не обновляется тихо в фоне, а значит часть рабочих станций почти наверняка осталась на старых версиях.

Как пишет The Hacker News, речь идет о CVE-2026-14266. Проблема затрагивает обработку XZ-данных в 7-Zip: это heap-based buffer overflow, то есть переполнение буфера в куче. Детали 15 июля опубликовала Trend Micro Zero Day Initiative, а исправление разработчики 7-Zip выпустили еще 25 июня в версии 26.02. Исследователь Landon Peng из Lunbun LLC сообщил о баге 5 июня. По оценке ZDI, уязвимость получила 7,0 балла по CVSS 3.0 и статус High, а не Critical, как успели написать некоторые пересказы.

Это важная оговорка. Формулировка про remote code execution здесь легко звучит громче, чем есть на самом деле. Вектор атаки у CVE-2026-14266 локальный: жертва должна открыть подготовленный архив, присланный по почте, скачанный с сайта или подложенный иным способом. Никакого «само заразилось от просмотра страницы» в материале нет. Более того, уязвимость помечена высокой сложностью эксплуатации. По состоянию на 20 июля 2026 года публичного PoC и подтвержденных случаев эксплуатации в реальных атаках The Hacker News не нашел.

Технически баг выглядит довольно приземленно, а потому и неприятно. В функции MixCoder_Code декодера XZ архиватор при определенных условиях передавал обработчику не оставшийся размер выходного буфера, а полный размер буфера на каждом проходе. Если до этого часть данных уже была записана, декодер получал больше места, чем реально оставалось. Отсюда и out-of-bounds write. В версии 26.02 логику поправили: теперь учитываются уже записанные байты, а при выходе за допустимый предел выполнение останавливается. Никакой магии, просто классическая memory-safety история, которая в 2026 году все еще ломает вполне бытовой софт.

Отдельно стоит понимать, в каком контексте запустится вредоносный код. По данным advisory, он выполняется с правами текущего процесса 7-Zip и не получает привилегий сам по себе. На Windows это обычно означает ограниченный стандартный токен пользователя даже в том случае, если человек вошел под учетной записью администратора. Проще говоря, по умолчанию ущерб ограничен контекстом самого 7-Zip. Но если архиватор кто-то запускал с повышенными правами, сценарий становится заметно хуже. Для корпоративной среды это уже не академическая деталь: привычка «запустить от администратора, чтобы точно сработало» до сих пор встречается слишком часто.

История неприятна еще и потому, что это не одиночный сбой, а продолжение серии проблем в обработчиках архивов 7-Zip. 27 апреля версия 26.01 уже закрывала пакет memory-safety багов, включая CVE-2026-48095 с более высокой оценкой риска. Ту дыру в обработчике NTFS GitHub Security Lab подробно разобрал 22 мая и даже показал рабочий proof-of-concept. На этом фоне нынешняя уязвимость 7-Zip выглядит тише, но для ИБ-команд это даже хуже: шум вокруг нее меньше, а значит и вероятность, что обновление отложат «на потом», выше. При этом версия 26.02 закрывает сразу весь набор последних исправлений, так что одно обновление снимает несколько вопросов сразу.

Есть и важный операционный вывод. 7-Zip не относится к тем программам, которые в большинстве инфраструктур получают обновления автоматически и незаметно для пользователя. Обновление ставится вручную с официального сайта, а многие «стабильные» машины живут по принципу «если открывает архивы, не трогай». Именно такие машины потом и становятся входной точкой для фишинговых писем с вложениями или архивов из внешних источников. Если в компании 7-Zip попадает в золотой образ рабочих станций, пакет обновления стоит пересобрать и проверить распространение по всей базе, а не ограничиваться одной заметкой в чате админов.

Есть и второй слой проблемы: уязвимой может быть не только установленная пользователем копия 7-Zip, но и сторонний продукт, который поставляет внутри себя этот же XZ-декодер. В исходном материале прямо сказано, что таким решениям нужен собственный патч от вендора. Это типичный сюжет для цепочки поставки ПО в миниатюре: библиотека или компонент исправлены, а до конечного продукта обновление доезжает с задержкой. Поэтому разработчикам и владельцам desktop-софта имеет смысл не просто обновить 7-Zip у себя, а проверить, не лежит ли у них внутри приложения старая версия соответствующего кода.

Для бизнеса вывод довольно скучный, но именно такие скучные выводы потом экономят время на разборе инцидентов. Нужно обновить 7-Zip до 26.02 или новее на всех машинах, которые открывают архивы извне, и пересмотреть практику запуска утилит с повышенными правами. Для разработчиков это еще одно напоминание, что обработка форматов файлов остается одной из самых уязвимых зон даже в зрелых проектах с длинной историей. А для ИБ-отделов это хороший повод инвентаризировать «маленькие настольные программы», про которые вспоминают только когда очередной архив внезапно оказывается не просто архивом. Дополнительные детали по кейсу собрал The Hacker News.

Поделиться: Telegram X LinkedIn