Стандарт x402 позволяет программам, включая ИИ-агентов, оплачивать вызовы API прямо в рамках веб-запроса, без подтверждения человеком каждой операции. 22 октября компания по кибербезопасности V12 сообщила о 25 найденных уязвимостях в SDK x402: три из них получили критическую оценку. Уязвимости обнаружили при анализе кода и локальных тестах; ни V12, ни x402 Foundation не сообщали о реальных атаках. Фонд исправил все три критические проблемы в выпусках от 18 августа.
Риск списания денег касался агентов, которые автоматически подписывали платежи, если приложение не задавало лимиты. В обычном сценарии сервер отвечает кодом HTTP 402 Payment Required и предлагает варианты оплаты: в каждом указаны сумма, токен и получатель. Клиент выбирает вариант, подписывает платёж и повторяет запрос. До исправления клиент по умолчанию выбирал первый вариант из списка и не ограничивал сумму. Злоумышленный API мог потребовать весь баланс поддерживаемого токена. Предыдущий небольшой платёж мог раскрыть адрес кошелька агента, а по нему сервер узнавал остаток. Если приложение не задавало платёжную политику, автоматический подписант мог подтвердить списание; для токена с поддержкой подписанных переводов злоумышленнику оставалось отправить платёж.
В версиях от 18 августа клиенты TypeScript, Python и Go получили ограничения: по умолчанию один платёж не превышает 1 доллар, а оплачивать запросы можно распознанными стейблкоинами, привязанными к доллару США, например USDC. Приложение может настроить собственные лимиты. Но параметр
Другая ошибка затрагивала обработку платежей в Solana. Сервер продавца поручает проверку и отправку транзакции фасилитатору; в Solana тот же фасилитатор оплачивает комиссию сети. TypeScript-версия фасилитатора проверяла, что платёж обращается к разрешённой программе токенов, но не проверяла тип инструкции. Из-за этого разрешение на расходование токенов принималось за перевод. Разрешение лишь даёт другому аккаунту право потратить токены позднее и само по себе их не перемещает; от инструкции перевода оно отличается первым байтом.
В локальном тесте V12 фасилитатор принял такое разрешение за платёж, но тестовая транзакция не отправлялась в сеть. Продавец, полагавшийся на проверку фасилитатора, мог выдать ресурс, не получив токены. V12 назвала это «полным обходом оплаты». Для атаки требовался аккаунт токена, но не его баланс: комиссию каждый раз платил фасилитатор. SDK для Python и Go уже проверяли тип инструкции; в выпусках от 18 августа такую проверку добавили в TypeScript. Уязвимость была во всех опубликованных версиях
Третья уязвимость касалась расширения входа Sign-In-With-X (SIWx). Оно позволяет агенту подписать сообщение кошельком, например чтобы подтвердить прежнюю оплату вместо повторного платежа. В Ethereum такое сообщение указывает сайт, адрес кошелька и одноразовый код. Автоматический клиент подписывал SIWx-сообщение, не проверяя, совпадает ли указанный сайт с тем, которому он отправил запрос. Злоумышленный сервер мог получить от другого сайта свежее сообщение для входа, передать его агенту и использовать подпись, чтобы войти туда от имени кошелька агента. Результат зависел от того, принимал ли сайт пересланное сообщение; атакующий получал доступ, предусмотренный этой учётной записью.
Исправления от 18 августа заставляют клиенты TypeScript, Python и Go отказываться от подписи, если сайт в сообщении не совпадает с сайтом, отправившим ответ 402. Такое же требование внесли в спецификацию SIWx. В TypeScript-коде, который напрямую вызывает
x402 создала Coinbase, а в этом году передала проект x402 Foundation, входящему в Linux Foundation. Среди членов фонда — Visa и Mastercard; Coinbase занимает старшее место в его техническом руководящем комитете. При этом фонд не выпустил предупреждений безопасности о трёх критических ошибках, а в списках изменений исправления не обозначил как связанные с безопасностью. По состоянию на 23 октября
На 23 октября последние версии были такими: 2.28.0 для
Если обновление пока невозможно, команда может зарегистрировать платёжную политику, отклоняющую варианты выше выбранной суммы. В старых клиентах для этого есть
Изображение носит иллюстративный характер
Риск списания денег касался агентов, которые автоматически подписывали платежи, если приложение не задавало лимиты. В обычном сценарии сервер отвечает кодом HTTP 402 Payment Required и предлагает варианты оплаты: в каждом указаны сумма, токен и получатель. Клиент выбирает вариант, подписывает платёж и повторяет запрос. До исправления клиент по умолчанию выбирал первый вариант из списка и не ограничивал сумму. Злоумышленный API мог потребовать весь баланс поддерживаемого токена. Предыдущий небольшой платёж мог раскрыть адрес кошелька агента, а по нему сервер узнавал остаток. Если приложение не задавало платёжную политику, автоматический подписант мог подтвердить списание; для токена с поддержкой подписанных переводов злоумышленнику оставалось отправить платёж.
В версиях от 18 августа клиенты TypeScript, Python и Go получили ограничения: по умолчанию один платёж не превышает 1 доллар, а оплачивать запросы можно распознанными стейблкоинами, привязанными к доллару США, например USDC. Приложение может настроить собственные лимиты. Но параметр
spendControls: false отключает все эти ограничения. Другая ошибка затрагивала обработку платежей в Solana. Сервер продавца поручает проверку и отправку транзакции фасилитатору; в Solana тот же фасилитатор оплачивает комиссию сети. TypeScript-версия фасилитатора проверяла, что платёж обращается к разрешённой программе токенов, но не проверяла тип инструкции. Из-за этого разрешение на расходование токенов принималось за перевод. Разрешение лишь даёт другому аккаунту право потратить токены позднее и само по себе их не перемещает; от инструкции перевода оно отличается первым байтом.
В локальном тесте V12 фасилитатор принял такое разрешение за платёж, но тестовая транзакция не отправлялась в сеть. Продавец, полагавшийся на проверку фасилитатора, мог выдать ресурс, не получив токены. V12 назвала это «полным обходом оплаты». Для атаки требовался аккаунт токена, но не его баланс: комиссию каждый раз платил фасилитатор. SDK для Python и Go уже проверяли тип инструкции; в выпусках от 18 августа такую проверку добавили в TypeScript. Уязвимость была во всех опубликованных версиях
@x402/svm с 2.0.0 по 2.22.0 включительно; начиная с 2.23.0 она исправлена. The Hacker News сообщило, что нашло проблему, просмотрев опубликованные пакеты. Третья уязвимость касалась расширения входа Sign-In-With-X (SIWx). Оно позволяет агенту подписать сообщение кошельком, например чтобы подтвердить прежнюю оплату вместо повторного платежа. В Ethereum такое сообщение указывает сайт, адрес кошелька и одноразовый код. Автоматический клиент подписывал SIWx-сообщение, не проверяя, совпадает ли указанный сайт с тем, которому он отправил запрос. Злоумышленный сервер мог получить от другого сайта свежее сообщение для входа, передать его агенту и использовать подпись, чтобы войти туда от имени кошелька агента. Результат зависел от того, принимал ли сайт пересланное сообщение; атакующий получал доступ, предусмотренный этой учётной записью.
Исправления от 18 августа заставляют клиенты TypeScript, Python и Go отказываться от подписи, если сайт в сообщении не совпадает с сайтом, отправившим ответ 402. Такое же требование внесли в спецификацию SIWx. В TypeScript-коде, который напрямую вызывает
createSIWxPayload, теперь нужно передавать URL ответа 402 с учётом всех перенаправлений. Обёртки @x402/fetch и @x402/axios передают этот URL автоматически. x402 создала Coinbase, а в этом году передала проект x402 Foundation, входящему в Linux Foundation. Среди членов фонда — Visa и Mastercard; Coinbase занимает старшее место в его техническом руководящем комитете. При этом фонд не выпустил предупреждений безопасности о трёх критических ошибках, а в списках изменений исправления не обозначил как связанные с безопасностью. По состоянию на 23 октября
npm audit не показывал предупреждений для последних TypeScript-релизов до исправлений, а PyPI не указывал уязвимостей в последнем предшествовавшем им выпуске Python. The Hacker News отмечало: разработчики, полагавшиеся на эти проверки, не получили сигнала обновить SDK. На 23 октября последние версии были такими: 2.28.0 для
@x402/core, @x402/svm, @x402/extensions, @x402/fetch и @x402/axios; v2.28.0 для модуля Go; 2.25.0 для пакета Python. Чтобы получить исправление лимита платежей в TypeScript, нужно обновить @x402/fetch или @x402/axios как минимум до 2.23.0: вместе с ними подтянется соответствующая версия @x402/core. Для проверки SIWx требуется также @x402/extensions 2.23.0 или новее, а для проверки платежей Solana на стороне фасилитатора — @x402/svm не ниже 2.23.0. В более новых выпусках есть и последующие исправления, включая отдельный обход оплаты, устранённый в @x402/core 2.27.0 в сентябре. Если обновление пока невозможно, команда может зарегистрировать платёжную политику, отклоняющую варианты выше выбранной суммы. В старых клиентах для этого есть
registerPolicy в TypeScript и Go и register_policy в Python; в Python доступна готовая политика max_amount. V12 также советует проверять сайт в SIWx-сообщении до подписи, задавать бюджет на каждый платёж и общий лимит расходов, а для агента ограничивать разрешённые токены, сети и адреса получателей.
