В экосистеме веб-разработки, где скорость загрузки - ключевой фактор, агрессивное кэширование статического контента стало стандартом. Однако, когда механизмы кэширования начинают неправильно интерпретировать динамические запросы, это открывает двери для серьёзных нарушений безопасности. Именно такая ситуация недавно была выявлена в связке популярного фреймворка SvelteKit и платформы для развертывания Vercel. Обнаруженная уязвимость, получившая идентификатор CVE-2026-27118, позволяла злоумышленникам получать доступ к конфиденциальным данным авторизованных пользователей через публичный кэш.
Суть проблемы: параметр, который слишком многое решал
Проблема коренится в адаптере "@sveltejs/adapter-vercel", который обеспечивает интеграцию приложений SvelteKit с платформой Vercel. В этом адаптере присутствовал служебный параметр запроса "__pathname", изначально предназначенный для внутренних нужд, например, для инкрементальной статической регенерации (ISR). Его ключевая функция - переопределять путь обрабатываемого запроса. Критическим недостатком стало полное отсутствие валидации для этого параметра: он мог указывать на любой маршрут внутри приложения, включая защищённые API-эндпоинты.
Особую опасность создавало взаимодействие этой функции с правилами кэширования Vercel. Платформа настроена агрессивно кэшировать всё, что находится по путям, начинающимся с "/_app/immutable/" - это стандартная папка для статических сборных ресурсов SvelteKit. Ответы для таких путей автоматически получали заголовки врод:
| 1 | Cache-Control: public, immutable, max-age=31536000 |
предписывающие прокси-кэшам хранить их целый год и считать общедоступными.
Механика атаки: обман кэша в два шага
Эксплуатация уязвимости, известной как обман кэша, проходила по следующему сценарию:
Фаза заражения кэша. Злоумышленник создавал специальную ссылку, например:
| 1 | https://example.vercel.app/_app/immutable/x?__pathname=/api/session |
Когда авторизованная жертва переходила по ней, адаптер Vercel, видя параметр "__pathname", подменял путь запроса на "/api/session". Сервер приложения, получив валидные куки сессии жертвы, исполнял запрос и возвращал конфиденциальные данные (токены, информацию профиля). Однако, поскольку исходный URL начинался с "/_app/immutable/", платформа Vercel, получив ответ "200 OK", помещала эти *приватные* данные в *публичный* кэш, ассоциируя их с URL, содержащим параметр.
Фаза извлечения данных. После этого злоумышленнику достаточно было самостоятельно запросить тот же самый URL, уже без каких-либо авторизационных кук. Кэширующий сервер Vercel (о чём свидетельствовал заголовок ответа "X-Vercel-Cache: HIT") возвращал данные, ранее сохранённые от имени жертвы. Таким образом, защищённая информация становилась доступна кому угодно.
Масштаб и последствия
Эта уязвимость затрагивала практически любое приложение на SvelteKit, развёрнутое на Vercel и использующее аутентификацию на основе кук для защиты маршрутов. Для успешной атаки не требовалось вносить изменения в код самого приложения - достаточно было лишь знать структуру его защищённых API-эндпоинтов. Основной риск заключался в массовой утечке сессионных токенов и персональных данных пользователей, что могло привести к компрометации учётных записей.
Стоит отметить, что исследователи из компании Aikido, обнаружившие проблему, изначально пробовали другую технику - cache poisoning (отравление кэша), целью которой является подмена контента, например, внедрение вредоносного JavaScript. Однако в данном контексте успешной оказалась именно тактика обмана, которая фокусируется на несанкционированном *извлечении* данных, а не на их подмене.
Реакция и рекомендации
Ответ на инцидент был оперативным. После ответственного раскрытия информации компанией Aikido 21 января 2026 года, инженеры Vercel оперативно приступили к работе. Патч был развёрнут 19 февраля 2026 года. Исправление включает два ключевых изменения: во-первых, все запросы к несуществующим путям внутри "/_app/immutable/" теперь принудительно возвращают ошибку 404, минуя адаптер. Во-вторых, параметр "__pathname" теперь полностью удаляется из входящих запросов.
Для владельцев приложений критически важно предпринять следующие шаги:
- Обновить зависимость. Убедиться, что в проекте используется адаптер "@sveltejs/adapter-vercel" версии 6.3.2 или выше.
- Переразвернуть приложение. Сам факт обновления пакета в "package.json" может быть недостаточным. Необходимо инициировать новый процесс сборки и развёртывания на платформе Vercel, чтобы гарантированно применить исправления на уровне платформы.
- Провести аудит. Воспользоваться инструментами для статического анализа безопасности (SAST) или специализированными сканерами, подобными тем, что предлагает Aikido, чтобы проверить код на наличие подобных или иных уязвимостей, связанных с конфигурацией кэширования.
Этот случай наглядно демонстрирует, насколько хрупким может быть взаимодействие между современными frameworks, облачными платформами и механизмами оптимизации производительности. Недостаток валидации одного служебного параметра привёл к ситуации, когда доверенная система кэширования превратилась в канал утечки данных. Для разработчиков и DevOps-инженеров инцидент служит важным напоминанием: необходимо тщательно изучать документацию платформ, понимать, как они обрабатывают и кэшируют различные запросы, и явно конфигурировать правила безопасности для маршрутов, содержащих динамические данные.
Ссылки
- https://www.cve.org/CVERecord?id=CVE-2026-27118
- https://github.com/sveltejs/kit/security/advisories/GHSA-9pq4-5hcf-288c
- https://www.aikido.dev/blog/sveltespill-cache-deception-sveltekit-vercel
