Как одно изображение может привести к компрометации Mac: разбор уязвимости CVE-2026-3102 в ExifTool

Введение

ExifTool — это популярная утилита для чтения и записи метаданных в файлах изображений, PDF, аудио и видео. Она доступна как в виде отдельного приложения командной строки, так и в виде библиотеки, которую можно встраивать в другое ПО. В этой статье мы анализируем CVE-2026-3102 — уязвимость в ExifTool, обнаруженную экспертами глобального центра исследований и анализа угроз (GReAT) «Лаборатории Касперского» в феврале 2026 года и исправленную разработчиками в том же месяце. Проблема затрагивает системы macOS с ExifTool 13.49 и более ранних версий. В основе уязвимости лежит недостаточная очистка (санитизация) входных данных в ExifTool при обработке некоторых тегов метаданных в macOS. Подготовив изображение с вредоносными командами, встроенными в поле даты в метаданных, злоумышленник может спровоцировать выполнение кода при обработке файла.

Исследование началось с повторного анализа уязвимости CVE-2021-22204, с которой мы впервые столкнулись много лет назад. Эта брешь позволяла использовать недостаточную очистку на основе регулярных выражений перед передачей пользовательского ввода в функцию-приемник eval. В ходе анализа соседних функций валидации ввода в кодовой базе ExifTool на предмет аналогичных упущений мы и обнаружили CVE-2026-3102. При успешной эксплуатации CVE-2026-3102 злоумышленник может выполнять произвольные shell-команды с привилегиями пользователя, запустившего ExifTool, что потенциально может привести к полной компрометации системы.

Техническая информация

Важное замечание

Для эксплуатации CVE-2026-3102 требуется флаг -n (также известный как -printConv), который выводит данные в машиночитаемом формате без дополнительной обработки.

Отслеживание уязвимого приемника

Анализ компрометации данных позволяет выявлять «загрязненные» данные, которые могут передаваться опасным участкам кода без должной валидации. В данном контексте «приемник» (или sink) — это точка или функция в программе, где значения параметров или данные, помеченные как «загрязненные» либо поступающие из ненадежного источника (например, введенные пользователем), могут влиять на поведение программы. В ExifTool такими функциями являются eval и system, причем обе способны выполнять системные команды. Если CVE-2021-22204 использовала в качестве приемника функцию eval, то новая уязвимость (CVE-2026-3102) нацелена на функцию system. Зная уязвимый приемник, мы должны были проследить, как именно пользовательские данные достигают этой точки исполнения. Рассмотрим этот момент подробнее.

Поиск неочищенного значения даты

На скриншоте выше показано, где именно внутри функции SetMacOSTags располагается вызов приемника system(). Прослеживая путь в обратном направлении от system(), мы определили источник выполняемой команды — переменную $cmd. Она формируется из трех входных параметров: $file (должным образом очищен), $setTags (обрабатывается итеративно) и $val (под контролем пользователя и, что критически важно, попадает неочищенным в уязвимый фрагмент кода).

В ExifTool тег представляет собой именованное поле метаданных. При парсинге изображения утилита извлекает значения даты и времени из стандартных записей EXIF или атрибутов файловой системы macOS. Чтобы работать с датами создания файлов в macOS, ExifTool опирается на атрибут MDItemFSCreationDate системы поиска Spotlight. В коде программы этот атрибут сопоставляется с внутренним псевдонимом $FileCreateDate. Эти два идентификатора определяют, как хранится и применяется дата создания файла.

Эта взаимосвязь и легла в основу уязвимости. При парсинге изображения ExifTool перебирает обнаруженные теги. Имя текущего тега присваивается переменной $tag, а его текстовое содержимое (например, строка даты) — переменной $val. Уязвимый участок кода выполняется только тогда, когда значение $tag совпадает с MDItemFSCreationDate или $FileCreateDate. В этот момент содержимое тега попадает в $val и передается в функцию SetMacOSTags. Как показано на скриншоте ниже, параметр имени файла экранирован корректно, а вот значение даты ($val) — нет. Поскольку дата извлекается напрямую из метаданных файла, злоумышленник может внедрить кавычки в это поле. Структура команды будет нарушена, что позволит вредоносной нагрузке выполниться через приемник system().
На следующих скриншотах приведены некоторые из тегов, которые можно изменять. Определив уязвимый параметр, необходимо продумать способ доставки: как поместить вредоносную нагрузку в FileCreateDate, не вызывая преждевременную валидацию данных? Ответ нашелся в официальной документации.

Планирование доставки вредоносной нагрузки

Изучим документацию, чтобы понять, как ExifTool обрабатывает операции с тегами, и попробуем найти легитимную функцию, которую можно приспособить под эксплойт. В частности, требуется способ доставки вредоносной нагрузки в уязвимый параметр FileCreateDate. В результате анализа тегов, связанных с macOS, а также FileCreateDate, была собрана следующая информация:

• Для записи или удаления метаданных значения тегов присваиваются с помощью параметра -TAG=[ЗНАЧЕНИЕ] и (или) -geotag, -csv= или -json=.
• При копировании или перемещении метаданных используется функция -tagsFromFile.
(Полезную информацию об операциях с тегами и внутреннем устройстве ExifTool можно найти в соответствующем разделе документации и на странице описания утилиты.)

Чтобы воспользоваться уязвимостью, нам нужно скопировать строку (формат даты: ММ/ДД/ГГГГ) с помощью параметра -tagsFromFile, поскольку эта операция вызывает функцию SetMacOSTags, где неочищенное значение $val достигает приемника system().

С помощью параметра -tagsFromFile мы можем подготовить исходный тег (например, DateTimeOriginal), который может принимать произвольные значения, и скопировать нужное нам значение из него в FileCreateDate, вызвав тем самым уязвимую функцию с контролируемым нами вводом.

При этом нужно использовать одинарные кавычки, поскольку они не экранируются в $val. Для начала следует найти в таблице тегов EXIF тег даты и времени, который будет копироваться через -tagsFromFile. Значение тега FileCreateDate строго валидируется, поэтому задать ему вредоносное значение напрямую не получится. Нужно найти другой исходный тег, который принимает необработанные значения и может быть скопирован в целевое поле. В следующем фрагменте показано начало упомянутой таблицы.

В этом исследовании мы использовали DateTimeOriginal, хотя, вероятно, подошел бы и тег CreateDate с идентификатором 0x9004 (см. скриншот ниже). Первые попытки внедрения некорректного формата даты провалились: встроенный фильтр ExifTool отклонил входные данные. Чтобы обойти это ограничение, мы изучили, как утилита поступает с необработанными метаданными.

Обход фильтра

Чтобы подтвердить, что фильтр PrintConvInv отклоняет неправильные даты при прямой записи, мы выполнили следующую команду, где evil_benign.jpg — это обычный JPG-файл с некорректным форматом даты и времени. Результат — сообщение об ошибке «Invalid date/time» («Неверные дата/время»), так как мы не указали время. Следующий скриншот подтверждает, что так эксплойт не сработает: код валидации даты в ExifTool обнаруживает некорректный ввод и отклоняет изменения, активируя внутренний фильтр PrintConvInv.

Впрочем, можно заставить утилиту игнорировать форматирование с помощью флага -n, который принимает необработанные значения вместо человекочитаемых. Флаг -n пропускает этап преобразования PrintConvInv, на котором и происходит очистка входных данных. Воспользовавшись этим параметром, мы убедились, что можем спрятать неочищенные данные в исходном теге. Последний шаг — активировать уязвимый участок кода, скопировав эти данные в тег FileCreateDate. Таким образом, в тег DateTimeOriginal было записано значение с некорректным форматом даты и времени с помощью флага -n. Затем мы прочли этот тег из метаданных EXIF, чтобы подтвердить, что нам удалось сохранить необработанное значение без приведения к человекочитаемому формату, который обычно требует ExifTool.

Запуск эксплойта

Для инъекции команд необходимо поместить их в одинарных кавычках в указанные теги даты и времени.

Как видно на скриншоте ниже, мы успешно записали метаданные даты и времени с командой в одинарных кавычках. Мы поместили вредоносную нагрузку в исходный тег и теперь нам нужно ее скопировать в тег FileCreateDate, что приведет к вызову уязвимой функции system().

Далее требуется скопировать тег даты и времени в другой файл, что приведет к вызову функции SetMacOSTags. Согласно документации, следующая команда позволяет скопировать данные из исходного тега в тег FileCreateDate. Она использует параметр -tagsFromFile, который, как уже упоминалось, вызывает SetMacOSTags.

Теперь мы можем составить нашу финальную команду:

Ниже приведено подтверждение успешного выполнения вредоносной нагрузки. Обратите внимание, что при копировании тегов в macOS (Darwin) используется команда /usr/bin/setfile. Чтобы увидеть полное значение переменной $cmd до инъекции, мы добавили отладочную инструкцию, которая выводит фактическую команду, выполняемую внутри функции system().

После инъекции видно, что наша команда выполняется через механизм подстановки команд (command substitution). Добавленные нами одинарные кавычки помогли сделать всю команду синтаксически корректной. Ниже представлена более подробная разметка элементов и их роль в успешной реализации инъекции командной строки:

Такое вредоносное изображение может выглядеть полностью безобидным и легко попасть в редакцию новостей или любую другую организацию, обрабатывающую фотографии на macOS с использованием ExifTool. После обработки файла злоумышленник может незаметно развернуть троянец для скрытой эксфильтрации данных, загрузить дополнительное вредоносное ПО или использовать скомпрометированную систему в качестве плацдарма для дальнейшего распространения внутри сети жертвы.

Анализ исправления

Убедившись в работоспособности эксплойта, мы изучили, как разработчики устранили уязвимость в версии 13.50. В уязвимой версии ExifTool команды очищались до их объединения в единую строку. Это означало, что сохранялась возможность конкатенации одинарных кавычек, что открывало путь к эксплуатации. Однако в исправлении разработчики вынесли вызов system в отдельную функцию-обертку и вместо объединенной строки передают ей список аргументов, что полностью исключило необходимость ручного экранирования.
1. Замена строковой формы на форму списка аргументов

2. Новая функция-обертка System()
В версии 13.49 вывод перенаправлялся в /dev/null. Чтобы сохранить эту логику, функция-обертка временно перенаправляет STDOUT и STDERR в /dev/null и восстанавливает ввод-вывод после вызова.

Как избежать рисков, связанных с уязвимостью ExifTool

Важно, чтобы во всех рабочих процессах обработки фотографий использовалась обновленная версия утилиты. Все платформы управления цифровыми активами, приложения для организации фотографий и любые скрипты пакетной обработки изображений в macOS должны использовать ExifTool версии 13.50 или новее и не включать встроенные устаревшие библиотеки этого компонента.
ExifTool, как и любое другое программное обеспечение, может содержать и другие подобные уязвимости. Для усиления защиты рекомендуется использовать Kaspersky Open Source Software Threats Data Feed для мониторинга компонентов с открытым исходным кодом в цепочке поставок ПО, а также Kaspersky для macOS в качестве комплексного решения для защиты рабочих мест. Кроме того, ненадежные файлы нужно обрабатывать на выделенных компьютерах или в виртуальных средах с ограниченным доступом к сети и хранилищу. Если вы работаете с фрилансерами, привлекаете подрядчиков или разрешаете сотрудникам использование личных устройств (BYOD), необходимо внедрить политику, при которой доступ к корпоративной сети получают только устройства с активным решением безопасности для macOS.

Заключение

Уязвимость CVE-2026-3102 наглядно демонстрирует риски, связанные с недостаточной очисткой входных данных в инструментах, в которых при высокоуровневом парсинге метаданных задействуются платформозависимые утилиты. Хотя для эксплуатации уязвимости требуется явное использование флага -n и угроза актуальна только для macOS, она подчеркивает опасность ручных механизмов экранирования в кодовых базах активно развивающихся проектов. Переведя механизм выполнения системных команд на передачу списка аргументов, разработчики надежно устранили проблему на уровне архитектуры и полностью исключили риски несанкционированного выполнения команд через shell. Этот случай подтверждает базовый принцип безопасности: замена уязвимого механизма конкатенации строк безопасными API-вызовами на основе списков остается наиболее надежным способом защиты от инъекции команд.