CVE-2026-32722

Bloomberg Memray: Stored XSS через неэкранированные метаданные командной строки

Введение

Я обнаружил эту проблему при проверке Memray, Python-профилировщика памяти от Bloomberg, с простым вопросом:

Могут ли контролируемые злоумышленником метаданные времени выполнения небезопасно попасть в отчет, отображаемый в браузере?

В данном случае ответ был да.

Ошибка находилась в пути генерации HTML-отчетов Memray, где метаданные командной строки выводились в отчет, открываемый в браузере, без экранирования. Это превратило операционное поле в исполняемый HTML-приемник и в конечном итоге привело к CVE-2026-32722.

Проект: Memray на GitHub
Уведомление: GHSA-r5pr-887v-m2w9 /CVE-2026-32722

Цепочка атак

attacker-controlled argv → metadata.command_line → HTML template sink without escaping → raw markup in generated report → browser-side JavaScript execution

Что делает Memray

Memray — это Python-профилировщик памяти.

Он инструментирует процесс Python, записывает поведение выделения памяти и создает отчеты, которые помогают разработчикам понять:

• где выделяется память
• какие пути вызовов ответственны
• как выглядит пиковое использование памяти
• как память изменяется со временем

Некоторые из этих отчетов создаются в виде HTML и открываются в браузере.

Это делает генерацию отчетов реальной границей безопасности.

Важен не вопрос о том, является ли Memray «локальным инструментом».
Важен вопрос: могут ли контролируемые злоумышленником данные небезопасно попасть в вывод, отображаемый в браузере.

В данном случае — могли.

Почему эта ошибка заслуживала внимания

Многие недооценивают инструменты разработчика.

Это ошибка.

Как только инструмент:

• записывает метаданные времени выполнения,
• хранит значения, на которые повлиял злоумышленник,
• и затем выводит их в HTML,

он наследует те же риски, связанные с кодированием вывода, что и веб-приложение.

Вот в чем была суть проблемы.

Эта ошибка была не в логике профилирования. Не в отслеживании выделения памяти. Не в собственной работе с памятью.

Это был классический провал доверия границ:

• ненадежные метаданные попали в систему,
• пересекли границу в HTML-приемник,
• и были выведены без экранирования.

Этого достаточно, чтобы создать реальную уязвимость.

Граница, на которой я сосредоточился

Я не подходил к Memray с фаззингом случайных опций CLI или погоней за сбоями.

Более сильный подход — сначала определить наиболее вероятную поверхность безопасности.

Для Memray это была генерация HTML-отчетов.

Почему?

Потому что вывод HTML вводит браузерный приемник, а браузерные приемники превращают обычные ошибки метаданных в проблемы безопасности, если:

• входные данные находятся под влиянием злоумышленника,
• выходные данные не экранированы,
• и браузер интерпретирует результат как разметку, а не как текст.

Именно это и произошло.

Первопричина

Ошибка сводится к двум строкам.

В:

def get_render_environment() -> jinja2.Environment:
    loader = jinja2.PackageLoader("memray.reporters")
    env = jinja2.Environment(loader=loader)

среда Jinja создается без автоматического экранирования.

Затем в:

Command line: <code>{{ metadata.command_line }}</code><br>

metadata.command_line выводится напрямую в HTML.

Это и есть вся уязвимость.

Почему это эксплуатируемо

Потому что metadata.command_line находится под влиянием злоумышленника.

Memray записывает командную строку, использованную для запуска профилируемой программы. Это означает, что контролируемые пользователем значения из argv сохраняются как метаданные и затем вставляются в отчет.

Таким образом, цепочка эксплуатации прямолинейна:

• злоумышленник контролирует содержимое командной строки
• Memray сохраняет его в metadata.command_line
• шаблон выводит его в HTML
• среда не экранирует его
• браузер интерпретирует его как живую разметку

Это превращает метаданные в исполняемое содержимое браузера.

Что делает это проблемой безопасности, а не просто плохим рендерингом

Важное различие — выполнение.

Множество ошибок приводят к некорректному HTML. Этого недостаточно.

Здесь содержимое, управляемое злоумышленником, было не просто видно в исходном коде страницы. Оно интерпретировалось браузером как активный HTML и выполнялось как JavaScript.

Вот разница между:

• искажением форматирования
• и реальным XSS-приемником

Поэтому вопрос был не:

«Может ли HTML появиться в отчете?»

Настоящий вопрос был:

«Может ли HTML, управляемый злоумышленником, стать исполняемым при открытии отчета?»

Ответ был да.

PoC

Мой первоначальный репродуцирующий пример использовал явный скрипт и управляемый злоумышленником аргумент:

cat > victim.py <<'PY'
x = [b"A" * 1024 for _ in range(1000)]
print("done")
PY

python -m memray run -o poc.bin victim.py ''
python -m memray flamegraph -o poc.html poc.bin

Сгенерированный HTML содержал необработанную разметку, управляемую злоумышленником:

Command line: <code>~/memray/src/memray/__main__.py run -o poc.bin victim.py </code><br>

Открытие или обновление сгенерированного отчета вызывало выполнение JavaScript.

Это установило основное утверждение:

• значение не было экранировано,
• браузер интерпретировал его как разметку,
• и приемник был исполняемым.

Позже, во время согласованного раскрытия, мейнтейнер упростил репродуцирующий пример:

python -m memray run -o poc.bin -c '# '

Эта версия лучше, потому что она более прямо изолирует уязвимую границу:

• не требуется дополнительных файлов
• не требуется дополнительной логики приложения
• просто содержимое командной строки, контролируемое злоумышленником, попадает в конвейер отчетов

Почему был выбран такой пэйлоад

Пэйлоад был намеренно простым:

Речь не о броских пэйлоадах.

Это чистый зонд для выполнения, потому что:

• не требует внешней инфраструктуры
• очевиден в отображаемом HTML
• немедленно доказывает интерпретацию HTML
• доказывает выполнение на стороне браузера без использования удаленного контента

Для такого класса ошибок этого достаточно.

Проверка масштаба

Одного типа отчета уже было бы достаточно, чтобы обосновать проблему.

Но я хотел выяснить, была ли это изолированная или структурная проблема.

Я подтвердил такое же поведение в:

• flamegraph-отчетах
• табличных отчетах
• flamegraph-отчетах, сгенерированных с помощью --no-web

Это было важно по двум причинам.

Первое

Это показало, что уязвимый приемник использовался повторно в нескольких HTML-выводах.

Второе

Это доказало, что ошибка не зависела от внешних CDN-ресурсов.

--no-web все равно воспроизводил проблему, что означает, что проблема была в собственном сгенерированном HTML и обработке шаблонов Memray, а не в удаленном JavaScript. Это сделало аргумент гораздо сильнее.

Почему это было классифицировано как низкая серьезность

Основной заботой мейнтейнера был практический контроль злоумышленника.

Это справедливо.

Это не та проблема, когда неаутентифицированный удаленный злоумышленник попадает на открытый HTTP-эндпоинт и получает мгновенный эффект.

Условие эксплуатации более узкое:

• злоумышленник влияет на ввод командной строки
• жертва позже открывает сгенерированный отчет в браузере

Поэтому реалистичная классификация — низкая серьезность.

Это не делает ошибку слабой.

Серьезность связана с условиями эксплуатации и вероятным воздействием. Валидность — с тем, реальна ли проблема.

Эта проблема была явно реальной:

• источник, управляемый злоумышленником
• HTML-приемник
• отсутствие экранирования
• фактическое выполнение JavaScript
• детерминированное исправление

Вот почему она все равно получила CVE.

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

Исправление было минимальным и корректным.

Мейнтейнер изменил:

{{ metadata.command_line }}

на:

{{ metadata.command_line|e }}

Это правильное исправление, потому что оно напрямую устраняет уязвимый приемник.

Вместо вывода необработанной разметки, такой как:

шаблон теперь выводит экранированный текст:

<img src=x onerror=alert(1)>

Это сохраняет информационную ценность поля командной строки, удаляя путь выполнения в браузере.

Мейнтейнер также проверил остальной контекст шаблона и пришел к выводу, что:

• несколько полей были числовыми
• некоторые строки полностью контролировались Memray
• значения, связанные со скриптами, выводились с помощью |tojson Таким образом, проблема была правильно локализована в metadata.command_line.

Это именно тот обзор исправления, который вы хотите видеть в реальном раскрытии.

Раскрытие

Это было сообщено приватно через GitHub Security Advisories.

Мейнтейнеры:

• подтвердили проблему
• согласились, что это их ошибка
• упростили репродуцирующий пример
• исправили уязвимый приемник
• выпустили исправление в версии 1.19.2
• запросили CVE
• опубликовали уведомление

Проблеме был присвоен: CVE-2026-32722

Чему на самом деле учит эта ошибка

Ключевой урок здесь прост:

метаданные не являются автоматически доверенными только потому, что выглядят как операционные.

• Командная строка кажется безобидной.
• Модальное окно отчета кажется безобидным.
• Локальный HTML-файл кажется безобидным.

Ничто из этого не имеет значения, как только содержимое, управляемое злоумышленником, попадает в вывод, отображаемый в браузере, без экранирования.

Как только инструмент выдает HTML, к нему нужно относиться как к приложению, производящему HTML.

Вот настоящий вывод.

Ключевые моменты

• Генераторы HTML-отчетов являются поверхностями безопасности
• Инструменты разработчика все еще требуют дисциплины кодирования вывода
• Локальные артефакты отчетов могут содержать реальные XSS-приемники
• Отсутствие экранирования в шаблонах достаточно, когда управляемые злоумышленником метаданные достигают приемника
• Низкая серьезность не означает низкое качество
• Правильный образ мышления здесь — анализ доверенных границ, а не слепой фаззинг

Заключительные слова

Эта уязвимость была не про хитрый пэйлоад.

Она была про выявление правильной границы.

Memray брал управляемые злоумышленником метаданные командной строки и выводил их в сгенерированный HTML без экранирования. Остальное сделал браузер.

Вот почему это стало CVE-2026-32722.

Исправлено в Memray 1.19.2.