В Payload CMS раскрыли сразу несколько серьёзных уязвимостей. Что нужно обновить

6 октября в GitHub Advisory Database появился большой пакет CVE для Payload CMS и официальных плагинов. Среди них SQL-инъекции, обходы разграничения доступа, проблемы с API-ключами и уязвимости в плагинах Import Export, MCP, Stripe и ecommerce. Критический уровень получили три уязвимости, и это важный нюанс: по двум самым обсуждаемым проблемам обновиться успевают многие, а третья — обход access control — закрыта только начиная с 3.90.0.

Исправления при этом появились раньше самих CVE. Значительная их часть уже вошла в Payload 3.88.0, а следующий пакет исправлений — в 3.90.0. Поэтому если проект до сих пор работает на старой версии Payload 3.x, обновление лучше не откладывать. И идти при этом стоит до 3.90.x, а не останавливаться на версии, где закрыта конкретная CVE.

Почему CVE появились только сейчас

Здесь даты могут запутать, поэтому сначала хронология.

1. 18 сентября вышел Payload 3.90.0. В release notes разработчики прямо пометили его как релиз с набором критических исправлений безопасности и рекомендовали обновиться как можно скорее. Детали эксплуатации вместе с релизом намеренно не публиковались.
2. 22 сентября в репозитории Payload появились подробные security advisory — в том числе по SQL-инъекции и prototype pollution.
3. 6 октября соответствующие уязвимости получили CVE в GitHub Advisory Database.

Получилась нормальная для security-релизов последовательность: сначала пользователям дали исправления и время обновиться, затем — подробные advisory и CVE-идентификаторы.

SQL-инъекция: CVE-2026-105845

Одна из наиболее серьёзных проблем — CVE-2026-105845, SQL-инъекция при использовании Payload с PostgreSQL или SQLite.

Проблема находилась в обработке динамических запросов: не доверенный пользователь, который может выполнять запросы к коллекциям с динамическими фильтрами или join-параметрами, способен повлиять непосредственно на SQL, который выполняет Payload.

Уязвимы версии Payload:

• >= 3.0.0 и < 3.88.0

Исправление находится в 3.88.0 и новее.

Для проектов на MongoDB именно эта уязвимость неактуальна: речь идёт о реляционных адаптерах Payload.

Важно и то, что это уже не первая подобная проблема за последнее время. В том же октябрьском пакете опубликована ещё одна SQL-инъекция — CVE-2026-105856, тоже закрытая в 3.88.0. А в марте исправлялась третья — CVE-2026-34747, закрытая в 3.79.1. Каждый раз разработчики усиливали проверку входных параметров запросов, но устойчивый паттерн из трёх инъекций за год говорит о том, что поверхность атаки в drizzle-слое Payload требует внимания в любом проекте с реляционной базой.

Import Export: prototype pollution вплоть до выполнения кода

Вторая критическая проблема находится не в самом Payload, а в официальном пакете @payloadcms/plugin-import-export.

CVE-2026-105844 связана с prototype pollution при обработке импортируемых данных. По описанию advisory неаутентифицированный пользователь при включённом плагине мог вызвать непредвиденное поведение приложения и привести к выполнению кода на сервере. Насколько легко это эксплуатируется на практике — зависит от конфигурации эндпоинтов плагина, но сама формулировка «без авторизации» делает уязвимость особенно неприятной.

Исправление также находится в 3.88.0. Как временная мера до обновления — отключить плагин или ограничить доступ к его эндпоинтам.

Если Import Export в проекте вообще не используется, конкретно эта проблема не затрагивает. Но если плагин подключён, проверять его версию стоило ещё 22 сентября, когда вышел advisory.

Разграничение доступа: третья критическая и ещё несколько проблем

Отдельный набор исправлений касается того, что Payload в некоторых сценариях возвращал или позволял изменить данные, которые пользователь видеть или менять не должен.

CVE-2026-105851 — третья уязвимость уровня Critical, и о ней стоит рассказать отдельно. Проблема в операции дублирования документов: она копировала значения полей из исходного документа даже тогда, когда поле скрыто или его правила access.read / access.create запрещают текущему пользователю такое значение. Настройка disableDuplicate, включённая по умолчанию на auth-коллекциях, этого не останавливала.

Проблема интересна именно с точки зрения архитектуры Payload: разработчик мог настроить ограничения на конкретное поле и рассчитывать, что они применяются во всех операциях, а дублирование их молча обходило. Исправление вошло в 3.90.0; временный обходной путь до обновления — хук beforeDuplicate, очищающий такие поля.

Остальные проблемы этой группы:

• CVE-2026-105849 — пользователи с правом чтения чужих документов могли получить их активные API-ключи; ключ действует до ротации и даёт разрешения владельца. Условие — включённый useAPIKey и право читать чужие документы. Исправлено в 3.90.0, пострадавшие ключи рекомендуется ротировать.
• CVE-2026-105853 — ответы механизмов refresh token и reset password могли содержать поля, закрытые ограничениями доступа. Полного обходного пути нет — только обновление до 3.90.0.
• CVE-2026-105855 — ограничение access.update на поле password в auth-коллекции не enforced на сервере. Исправлено в 3.90.0.
• CVE-2026-105847 — фильтры полиморфных join-запросов позволяли выводить скрытые значения, включая токены сброса пароля. Исправлено в 3.90.0.
• CVE-2026-105805 — сортировка по защищённым полям раскрывала ограниченную информацию о них. Исправлено в 3.88.0.
• CVE-2026-105846 — подделываемый redirect-параметр уводил гостя на недоверенный адрес после аутентификации. Исправлено в 3.88.0.

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

Для Payload это особенно чувствительная категория ошибок: access control — одна из функций, на которых обычно строится backend приложения.

Затронуты и официальные плагины

Кроме Import Export опубликованы проблемы в нескольких официальных пакетах.

В @payloadcms/plugin-mcp обнаружена проблема с контролем доступа к API-ключам — CVE-2026-105806, исправлена в 3.88.0. В том же октябрьском пакете у плагина ещё два advisory без номера CVE: утечка скрытых полей в ответах MCP login (исправлено в 3.88.0) и захват чужого аккаунта через password recovery при включённых экспериментальных auth-инструментах (исправлено в 3.90.0).

В @payloadcms/plugin-stripe — недостаточная проверка доступа в REST Proxy, CVE-2026-105848 (исправлено в 3.90.0).

Отдельная уязвимость опубликована для официального ecommerce-плагина — CVE-2026-105850, проблема валидации подтверждения заказа (исправлено в 3.90.0).

Для полноты картины: сентябрьско-октябрьская волна advisory шире, чем этот пакет CVE. В неё попали критический RCE в Form Builder, обходы авторизации в multi-tenant плагине, целая группа проблем загрузок (SVG, XML, перезапись объектов S3) и пара advisory для MCP без CVE-номеров. Полный список — на странице security advisory репозитория.

Поэтому при обновлении стоит смотреть не только на версию пакета payload, но и на версии всех официальных @payloadcms/* пакетов в проекте: монорепо выпускает их с общими номерами версий, и security-фиксы едут одной волной.

Что делать

Практический ориентир по версиям такой.

• Ниже 3.88.0 — не закрыты обе SQL-инъекции, prototype pollution в Import Export, проблема MCP API-ключей и часть access control исправлений. Среди них критические уязвимости, поэтому обновление уже нельзя считать плановым обновлением зависимостей.
• 3.88.x закрывают SQL-инъекции, Import Export, MCP API-ключи и часть мелких проблем, но не содержат исправлений CVE-2026-105851 (critical) и большинства access control фиксов.
• 3.89.x добавляют только исправление доступа к Payload Jobs.
• 3.90.x закрывают весь октябрьский пакет, включая обе access control критические уязвимости и плагины Stripe и ecommerce.

Поэтому идти нужно до актуальной версии 3.90.x, а не останавливаться на минимальной, в которой закрыта конкретная CVE. На момент публикации актуальный стабильный релиз — Payload 3.90.2.

После перехода на 3.90 разработчики Payload рекомендуют перегенерировать типы:

pnpm payload generate:types

А проектам с реляционной базой — создать и применить миграцию:

pnpm payload migrate:create <migration-name>
pnpm payload migrate

Это важно: security-релиз 3.90.0 содержит изменения схемы и поведения ряда механизмов, поэтому просто поднять номер пакета в package.json недостаточно.

Отдельно: если в проекте был включён useAPIKey, а пользователи имели право читать чужие документы, активные API-ключи стоит ротировать после обновления — CVE-2026-105849 означает, что они могли быть скомпрометированы.

Не только CVE

У этой истории есть ещё один полезный вывод. Payload быстро развивается, и разница между «проект работает» и «проект можно не обновлять» становится всё заметнее.

За последние месяцы уже исправлялись SSRF в загрузках, SQL-инъекции, проблемы с access control, API-ключами и официальными плагинами. Например, мартовская SSRF при загрузках файлов была закрыта только начиная с Payload 3.79.1, как и мартовская SQL-инъекция.

Если Payload используется не просто как CMS для публичных страниц, а как backend приложения с пользователями, личными кабинетами, файлами и внешним API, обновления безопасности лучше рассматривать так же, как обновления любого другого серверного фреймворка.

Особенно когда очередной release notes начинается с рекомендации обновиться как можно скорее.

Полный список security advisory: github.com/payloadcms/payload/security/advisories

Релизы Payload 3.88.0–3.90.2: github.com/payloadcms/payload/releases