CVE-2026-18953: Transform MCP Server от AWS не имел границы записи

5 августа 2026 года Amazon опубликовала бюллетень по безопасности 2026-075-AWS для CVE-2026-18953 — обхода путей (path traversal) в get_resource — инструменте awslabs.aws-transform-mcp-server, открытого сервера Model Context Protocol, который работает на собственной машине разработчика, чтобы ИИ-ассистент мог запускать задачи AWS Transform и получать их артефакты. Версии с 0.1.0 по 0.1.4 недостаточно строго ограничивали имена путей, и savePath мог записывать файлы за пределами предполагаемого рабочего каталога — как говорится в рекомендации GitHub в репозитории Amazon, «это может привести к локальному выполнению кода». Amazon присвоила ему оценку 8,6 — High. Исправление — версия 0.1.5, и серверного или чисто конфигурационного обходного решения нет, поскольку уязвимый участок кода присутствует в конфигурации по умолчанию. Ни один публичный источник не зафиксировал фактов его эксплуатации. Полная запись с оценками серьёзности и достоверности находится в Orca AI Incident Archive вместе с инцидентами MCP и сред выполнения агентов, зарегистрированными в том же месяце.

MCP-сервер, который пишет там, где работает разработчик

Серверы Model Context Protocol — это слой, который наделяет ассистента вызываемыми инструментами, и этот сервер намеренно локальный. В бюллетене Amazon он описывается как «MCP-сервер с открытым исходным кодом, который работает локально на машине разработчика и позволяет ассистентам на базе ИИ взаимодействовать с AWS Transform для выполнения заданий по преобразованию кода и получения их артефактов». В описании пакета на Python Package Index говорится, что он предоставляет доступ к жизненному циклу Transform через 19 инструментов, управляя рабочими пространствами преобразования, заданиями, коннекторами, задачами с участием человека, артефактами и чатом, а также охватывает модернизацию мейнфреймов, миграцию VMware, модернизацию .NET и пользовательские преобразования кода.

Именно это размещение и делает уязвимость значимой. Сервер на собственной инфраструктуре поставщика, который неправильно обрабатывает имя файла, повреждает хранилище поставщика. Этот же работал от имени разработчика, в домашнем каталоге разработчика, рядом с его конфигурацией оболочки и SSH-ключами, а описанное Amazon воздействие — не повреждённая загрузка, а «локальное выполнение кода». Все оценки, присвоенные CVE, сходятся в одном: вектор атаки — локальный, а не сетевой.

Инструмент, упомянутый в рекомендации, — это тот, который скачивает артефакт задания на диск. get_resource принимает savePath, указывающий, куда должен попасть файл. Ошибка в том, что ничто не мешало этому пути указывать на другое место.

Насколько плохо, и по чьей арифметике

К этому CVE привязаны три оценки, и они не совпадают. Amazon, которая назначила CVE как орган нумерации, оценивает его в 8.6 High по CVSS v3.1 с вектором CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — локальная, низкая сложность, привилегии не требуются, требуется взаимодействие пользователя, область изменена, высокое воздействие на конфиденциальность, целостность и доступность. Запись NIST в Национальной базе уязвимостей содержит собственную основную оценку v3.1 — 8.8 по другому вектору, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: требуются низкие привилегии, взаимодействие пользователя не требуется. Обе оценки попадают в категорию High. Разногласие касается предварительных условий — требуется ли злоумышленнику уже иметь точку опоры и нужно ли убеждать человека, — а не того, насколько серьёзны последствия.

Оценка Amazon по CVSS v4.0 для того же CVE составляет 6,3 (Medium) по CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H. Посмотрите на метрики воздействия: на самой уязвимой системе — ничего, на последующей системе всё высоко. Это характерная картина обхода, который выходит за пределы собственной границы инструмента — ущерб наносится всему, до чего инструмент может добраться, поэтому это попадает в столбец подсистемы, а уязвимая система получает ноль.

Обогащение CVE со стороны CISA, датированное 6 августа 2026 г., фиксирует решение SSVC: эксплуатация: отсутствует, автоматизируемость: нет, техническое воздействие: полное. Запись NVD была изменена в последний раз 23 октября 2026 г. и по-прежнему содержит обе оценки — 8.6 и 8.8 — рядом. Ни один из документов не считает другой ошибочным.

Что делал уязвимый код и что изменилось в 0.1.5

Описание этого механизма от Amazon состоит из одного предложения и составлено осторожно: инструмент «недостаточно ограничивал пути», что могло позволить «зависимому от контекста субъекту» «записывать произвольные файлы за пределами предполагаемого рабочего каталога через параметр savePath». В уведомлении не определяется субъект, не говорится, что запускает запись, и не описывается, как выглядит успешная эксплуатация. В нём лишь говорится, что результат «может привести к локальному выполнению кода».

Самое подробное публичное описание этого механизма принадлежит не Amazon. Это небольшой репозиторий с proof-of-concept, ronamosa/CVE-2026-18953, опубликованный на GitHub 8 августа 2026 года под Apache-2.0 — два коммита, ни одной звезды и ни одного форка на момент написания — в котором содержатся дословные копии уязвимой и исправленной версий file_validation.py и обе прогоняются через одни и те же входные данные.

Его трактовка версии 0.1.4 такова: validate_write_path() вычислял savePath с помощью realpath и expanduser, отклонял короткий список запрещённых путей (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd) и удалял компоненты каталога из предоставленного имени файла. Он никогда не ограничивал вычисленный путь каким-либо базовым или рабочим каталогом. Чёрный список конфиденциальных имён файлов — .bashrc, .zshrc, authorized_keys, id_rsa — применялся при чтении, но не при записи.

Репозиторий демонстрирует три записи, которые это допускает: абсолютный путь, вообще не требующий обхода, относительный выход через ../../ и имя dot-файла, которое путь чтения отверг бы. Все три попадают во временный каталог, создаваемый скриптом, а его пример вывода показывает dropped_by_absolute_path.sh, dropped_by_traversal.sh и .bashrc в подставном домашнем каталоге; настоящий домашний каталог никогда не затрагивается. Версия 0.1.5 добавляет недостающую границу: базовый каталог, взятый из $AWS_TRANSFORM_MCP_WRITE_DIR или из рабочего каталога запуска сервера, ниже которого должен находиться каждый путь записи после его разрешения, плюс блок-лист имён файлов, применяемый к окончательному пути записи после разрешения. Исправленный валидатор выдаёт «Путь записи должен находиться в пределах рабочего каталога» для всех трёх.

Ни одна из этих подробностей не фигурирует в рекомендации, и репозиторий не утверждает, что они взяты оттуда. Воспринимайте список запретов, проверку имени файла только для чтения и исправление базовой директории как восстановление по исходному коду, а не как вторую официальную находку. Что репозиторий действительно добавляет сверх рекомендации — это описание того, кто может предоставить путь: поскольку задача сервера — втягивать содержимое заданий и задач в контекст ассистента, сторона, выбирающая savePath, не обязательно должна быть человеком за клавиатурой. Ассистент, управляемый недоверенным содержимым, которое он получил через тот же инструмент, может сделать этот выбор. Это аргумент репозитория, основанный на коде и устройстве инструмента, а не заявление Amazon; неопределённое у Amazon «зависящее от контекста действующее лицо» согласуется с этим и на этом останавливается.

Семь недель между патчем и бюллетенем

Исправление не появилось вместе с объявлением. История релизов Python Package Index — собственные метаданные реестра, через который распространяется пакет, — датирует выпуск 0.1.4 20 мая 2026 года, а выпуск 0.1.5 — 17 июня 2026 года, за семь недель до публикации бюллетеня 2026-075 5 августа. На индексе вообще нет файла 0.1.0; самый ранний опубликованный артефакт в пределах затронутого диапазона — 0.1.1, загруженный 9 мая 2026 года. Таким образом, разработчик, устанавливающий из индекса, мог получить уязвимую сборку только в период с 9 мая по 17 июня, а все, кто отслеживал релизы, к середине июня уже использовали исправленный код.

Amazon не сообщает, когда ей стало известно о проблеме, когда поступил отчёт и почему было выпущено обновление, закрывшее её. Единственный человек, названный в записи, — Дрю Рейнс, которому выражается благодарность как в бюллетене, так и в рекомендации GitHub «за сотрудничество по этому вопросу в рамках процесса скоординированного раскрытия информации об уязвимостях». GHSA-66mr-jr63-2jgw была опубликована в репозитории Amazon awslabs/mcp 5 августа 2026 года — в тот же день, что и бюллетень; запись CVE была зарезервирована в 13:44 UTC и опубликована в 19:33 UTC того же дня.

Итак, дата исправления установлена, а причина — нет. Патченная версия, присутствующая в реестре за семь недель до публикации рекомендации, согласуется с тихим исправлением, за которым последовало скоординированное раскрытие, — но это вывод из двух временных меток, и ни в одном документе об этом не сказано.

Что подтверждают материалы дела, а что — нет

Архив оценивает эту запись на A — хорошо документирована, первичные источники согласуются — и не помечает её как спорную. Он относит её к исследовательским записям — это обнаружение уязвимости, а не инцидент при развёртывании — без зафиксированного реального ущерба. Оценка касается качества документации, и на основании рассмотренных доказательств она подтверждается: бюллетень, рекомендация GitHub и запись CVE — это три документа, опубликованные Amazon, которые совпадают в отношении продукта, версий, исправления и признания заслуг.

• Установлено. Amazon опубликовала бюллетень 2026-075-AWS от 5 августа 2026 г., посвящённый CVE-2026-18953 — обходу каталогов (path traversal) типа CWE-22 в обработке get_resource (а именно savePath) в awslabs.aws-transform-mcp-server версий с 0.1.0 по 0.1.4, исправлено в 0.1.5; серверного или чисто конфигурационного обходного решения нет, поскольку уязвимый путь находится в конфигурации по умолчанию.

• Установлено. Оценки и их расхождение: 8,6 High от Amazon как органа присвоения номеров CVE, 8,8 High от NIST как основной оценки NVD, 6,3 Medium по CVSS v4.0 и решение CISA по SSVC от 6 августа о том, что не было отмечено ни эксплуатации, ни автоматизируемого пути.

• Установлено. Даты выпуска на Python Package Index и благодарность Дрю Рейнсу за скоординированное раскрытие.

• Выведено из исходного кода третьей стороной. Список запретов (deny-list), блок-лист имён файлов, доступных только для чтения, отсутствующая базовая директория и исправление _ALLOWED_WRITE_BASE — всё это происходит из репозитория proof-of-concept от ronamosa, чьи вендорные копии двух версий валидатора может сравнить любой желающий.

• Выведено на основании временных меток и дизайна. То, что 0.1.5 был намеренным релизом безопасности, и что ассистент, управляемый недоверенным содержимым, мог предоставить враждебный путь. Amazon не утверждает ни того, ни другого.

• Не установлено. Какие-либо случаи эксплуатации в реальных условиях. Формулировка CISA «Эксплуатация: отсутствует» датирована 6 августа — за два дня до появления публичного proof-of-concept, поэтому она отражает ситуацию на тот момент, а не что-либо после него. Число затронутых пользователей, уведомления клиентам или данные телеметрии не публиковались.

• Не установлено.Независимое освещение. Похоже, ни одно из основных изданий не освещало эту CVE. Публичные сведения состоят из трёх документов Amazon, дополнений к ним от NIST и CISA, страниц трекеров, которые повторяют эти сведения, и единственного небольшого репозитория с proof-of-concept, описанного выше.

Что изменилось и что проверить

Средство исправления от Amazon — это просто повышение версии, и ничего больше: обновитесь до 0.1.5 или более поздней версии и «убедитесь, что любой ответвлённый или производный код исправлен с включением новых исправлений». Именно второе положение имеет хождение. Сервер имеет открытый исходный код, и форк, в который был вендорен валидатор 0.1.4, наследует уязвимость, не наследуя рекомендацию; бюллетень просит операторов производного кода внести изменение в него, то есть выпуск вышестоящего проекта не достигает копии, которую поддерживает кто-то другой.

Репозиторий proof-of-concept предлагает нечто, чего рекомендация предлагать не желает. По его словам, операторам, которые не могут обновиться немедленно, следует запускать сервер с рабочим каталогом, установленным на выделенный пустой каталог, и считать любой файл, в который он может записать, скомпрометированным. Позиция Amazon строже: обходного решения на стороне сервера или только средствами конфигурации нет вообще. По собственному признанию репозитория, это предложение также слабое, поскольку уязвимый код изначально никогда не ограничивал запись рабочим каталогом. Там, где два источника расходятся, в силе остаётся инструкция производителя только об обновлении.

Полезное в этой записи — не её оценка. Полезна её форма: локальный сервер MCP, загрузка артефакта с местом назначения, задаваемым вызывающей стороной, и отсутствие границы между ними. Значение имеет не дата бюллетеня, а зафиксированная версия — 0.1.5 или более поздняя, — и то же изменение, перенесённое в любой форк, который копировал валидатор.