SvelteKit est un framework JavaScript full-stack très populaire, et Vercel est sa plateforme de déploiement la plus courante. Et si nous vous disions que toutes les applications créées à l'aide de cette combinaison étaient vulnérables aux attaques permettant à des pirates de lire les réponses provenant de n'importe quelle route d'autres utilisateurs connectés ?
Eh bien, c'est vrai. Ce vecteur d'attaque, appelé « cache deception », est exactement ce qu'un des agents IA a trouvé et nous a signalé pendant que nous testions Aikido . Et bien que sceptiques au départ, nous avons retracé ses étapes et avons découvert que nous pouvions reproduire parfaitement la vulnérabilité. Nous avons rapidement informé Vercel, et la vulnérabilité a désormais été automatiquement corrigée pour tous les utilisateurs.
Remarque : le problème peut être consultée dans la base de données IntelAikido et porte le numéro CVE réservé suivant : CVE-2026-27118. Nous avons également trouvé un autre problème qui permet un déni de service dans une fonctionnalité expérimentale de SvelteKit. Celui-ci a également été divulgué et corrigé.
Résumé rapide
Le __chemin d'accès Le paramètre de requête dans l'adaptateur Vercel de SvelteKit peut remplacer le chemin d'accès depuis n'importe où. Sur Vercel, tous les fichiers sous /_app/immuable/ a différent Contrôle du cache : en-têtes afin qu'elle puisse être mise en cache. En préfixant cela avec un faux chemin et en le réécrivant pour qu'il contienne du contenu sensible, la réponse sera forcée à être mise en cache, permettant à un attaquant de la récupérer en visitant la même URL sans cookies.
URL de la preuve de concept:
https://example.vercel.app/_app/immutable/x?__pathname=/api/session
Découverte
Nous raconterons cette histoire du point de vue de l'agent de test d'intrusion IA qui a découvert la vulnérabilité, depuis le gadget initial jusqu'à l'exploitation complète, et nous aborderons quelques idées intéressantes en cours de route. Réveillez le robot qui sommeille en vous et lancez-vous dans la recherche !
Si vous lisez le code source de SvelteKit, vous trouverez des « adaptateurs », qui sont des intermédiaires entre une plateforme d'hébergement comme Vercel et le framework SvelteKit. Cela permet d'appliquer certaines règles spéciales aux requêtes et réponses requises pour le fonctionnement interne de la plateforme. Vercel a implémenté les éléments suivants dans serverless.js:
const DATA_SUFFIX = '/__data.json';
fetch(request) {
// If this is an ISR request, the requested pathname is encoded
// as a search parameter, so we need to extract it
const url = new URL(request.url);
let pathname = url.searchParams.get('__pathname');
if (pathname) {
// Optional routes' pathname replacements look like `/foo/$1/bar` which means we could end up with an url like /foo//bar
pathname = pathname.replace(/\/+/g, '/');
url.pathname = pathname + (url.pathname.endsWith(DATA_SUFFIX) ? DATA_SUFFIX : '');
url.searchParams.delete('__pathname');
request = new Request(url, request);
}
return server.respond(request, {
getClientAddress() {
return /** @type {string} */ (request.headers.get('x-forwarded-for'));
}
});
}
Nous pouvons lire « S'il s'agit d'une requête ISR, le chemin d'accès demandé est encodé en tant que paramètre de recherche. » Le code prend cette variable de chemin d'accès (provenant du ?__chemin_d'accès= paramètre de requête) et réécrit le url.chemin d'accès avec lui. La requête ignore l'URL d'origine et utilise simplement celle-ci. __chemin d'accès à la place.
Mais il ne semble pas y avoir de vérification concernant ces requêtes ISR (Incremental Static Regeneration), donc toutes les requêtes prennent-elles en charge ce paramètre ?
La réponse est oui, et c'est précisément là que réside la vulnérabilité ! N'importe quel chemin peut être remplacé par un autre chemin à l'aide d'un simple paramètre de requête. Un test simple comme /?__pathname=/404 afficherait effectivement une erreur 404 au lieu de la page d'accueil.
Cela peut sembler étrange. Pourquoi serait-ce dangereux ? Eh bien, cela ne l'est pas, jusqu'à ce que la mise en cache entre en jeu.
Empoisonnement du cache ?
Si nous pouvons réécrire n'importe quel chemin pour pointer vers n'importe quelle autre ressource, que se passe-t-il si cette ressource corrompue est mise en cache ? C'était également notre première idée. Si nous vérifions le code source de n'importe quelle application SvelteKit, vous verrez quelque chose comme :
import("./_app/immutable/entry/start.CLO1Dlt2.js"),
import("./_app/immutable/entry/app.kQF6jJr8.js")
Le chemin /_app/immutable/entrée/démarrer.CLO1Dlt2.js renvoie du code JavaScript à exécuter, et en examinant la réponse, Contrôle du cache : Les en-têtes nous indiquent qu'il est bien mis en cache. C'est normal pour les ressources statiques :
Âge : 618
Cache-Control : public, immuable,max-age=31536000
X-Vercel-Cache : HIT
Si nous pouvions utiliser notre ?__chemin_d'accès= paramètre pour réécrire la requête afin qu'elle pointe vers un chemin contrôlé par l'attaquant, tel qu'un téléchargement de fichier, et elle serait toujours mise en cache sous la même forme brute. /_app/immutable/entrée/démarrer.CLO1Dlt2.js chemin que chaque utilisateur charge, nous aurions un XSS sur chaque utilisateur. Voyons ce qui se passe lorsque nous ajoutons ce paramètre de requête à notre requête :
GET /_app/immutable/start.CLO1Dlt2.js?__pathname=/ HTTP/2
Hôte: example.vercel.app
Dans la réponse, nous recevons de bonnes et de mauvaises nouvelles provenant des en-têtes :
Âge : 935
Cache-Control : public, immuable,max-age=31536000
X-Vercel-Cache : HIT
Le Âge : a augmenté du temps qu'il a fallu pour écrire le paragraphe ci-dessus, et le HIT signifie que avec notre paramètre de requête ajouté, la même entrée de cache est utilisée que celle que tout le monde charge. Mais cela signifie également que l'ancien contenu JavaScript est renvoyé, et non le contenu de notre chemin réécrit. Si tel est le cas, pourrions-nous vider le cache, puis être les premiers à en faire la demande afin que notre La charge utile peut-elle être mise en cache à la place ?
Malheureusement non. La plateforme Vercel est plus compliquée en raison de son architecture sans serveur, et elle n'atteint même pas le code de l'adaptateur pour une ressource aussi statique. En effet, les ressources statiques sont mises en cache et renvoyées à un niveau supérieur, ce qui nous empêche de les corrompre.
Dans ce cas, Vercel est la seule plateforme vulnérable, nous ne pouvons donc pas trouver d'autres scénarios exploitables. Nous sommes dans une impasse.
Cache Deception !
Passons maintenant au problème suivant lié à la mise en cache Web : la tromperie de cache. Dans cette technique moins connue, un pirate redirige une victime vers une page sensible qu'il peut récupérer à l'aide de ses cookies. Si le cache stocke cette page sans tenir compte de l'utilisateur qui l'a demandée, le pirate peut ensuite visiter la même URL et consulter les données privées de la victime à partir du cache. Le problème est que le cache enregistre les réponses en se basant uniquement sur l'URL, sans tenir compte du fait que différents utilisateurs avec des cookies de connexion différents devraient voir un contenu différent.
Appliquer cette idée à notre ?__chemin_d'accès= gadget, nous pouvons créer notre URL ressembler à il pointe vers un chemin statique, mais pointe en réalité vers un contenu sensible. La couche de mise en cache peut se déclencher sur ce chemin d'apparence statique et ajouter explicitement Contrôle du cache : en-têtes et remplacer la réponse privée.
Alors que certains critères de cache sont documentées, notre enquête a révélé d'autres règles. L'une d'entre elles nous est déjà familière : les chemins commençant par /_app/immuable/Il s'avère que non seulement les fichiers statiques attendus peuvent être mis en cache sous ce préfixe, mais tout Réponse 200 OK. Pour éviter les ressources déjà générées, nous pouvons initialement pointer vers une fausse ressource. Ensuite, réécrivez-la vers n'importe quel chemin sensible, par exemple /api/session:
https://example.vercel.app/_app/immutable/x?__pathname=/api/session
Et voilà notre charge utile finale. En visitant ce lien après s'être connecté en tant que victime, une requête similaire à celle-ci sera envoyée :
GET /_app/immutable/x?__pathname=/api/session HTTP/2
Hôte: example.vercel.app
Cookie: auth=...
L'adaptateur Vercel de SvelteKit réécrit le chemin d'accès vers /api/session, et est géré par l'application. Le auth= Le cookie est vérifié et leur jeton de session est renvoyé :
HTTP/2 200 OK
Age: 0
Cache-Control: public, immutable, max-age=31536000
...
Server: Vercel
X-Vercel-Cache: MISS
Content-Length: 16
{"token":"1337"}Alors que le Contrôle du cache : l'en-tête indiquerait normalement max-age=0 Pour ce point de terminaison, la couche de mise en cache de Vercel active de manière forcée la mise en cache en raison du /_app/immuable/ préfixe.
Une fois que l'attaquant sait qu'une victime a été redirigée, il peut demander lui-même la même URL, sans aucun cookie :
GET /_app/immutable/x?__pathname=/api/session HTTP/2
Hôte: example.vercel.appIls reçoivent la même réponse qu'un HIT maintenant, et peut lire le jeton de la victime.
HTTP/2 200 OK
Age: 22
Cache-Control: public, immutable, max-age=31536000
...
Server: Vercel
X-Vercel-Cache: HIT
Content-Length: 16
{"token":"1337"}
En utilisant des cache busters (chemins fictifs uniques) et en effectuant des vérifications après la redirection, cette faille aurait pu être exploitée à grande échelle. Étant donné que cette vulnérabilité fait partie intégrante de la base Sveltekit, tout site web SvelteKit hébergé sur Vercel qui utilise des cookies pour l'authentification permettrait la récupération de réponses arbitraires.
Les conséquences
Nous avons rapidement signalé le problème à Vercel, qui a proposé une solution renvoyer de manière forcée une erreur 404 sur n'importe quel /_app/immuable/ chemin, et pour supprimer le __chemin d'accès paramètre. Comme ils contrôlent l'ensemble de leur plateforme, cela résout automatiquement le problème pour tous les utilisateurs, sans qu'aucun correctif manuel ne soit nécessaire.
Une grande leçon à tirer de cette vulnérabilité est que la mise en cache est toujours délicate. Des règles simples, comme la correspondance de préfixe, peuvent être exploitées par des fonctionnalités inattendues de la plateforme que vous n'avez même pas implémentées.
C'est pourquoi les tests d'intrusion peuvent être si utiles. Des problèmes comme celui-ci seraient difficiles à détecter uniquement à partir du code, mais grâce à un déploiement réel, les règles cachées peuvent être découvertes et exploitées. Le test d'intrusion IAAikido peut détecter automatiquement les attaques par empoisonnement et tromperie de cache, comme il l'a fait dans le cas présent.
Points clés à retenir
- Le 20 janvier 2026, le système de test d'intrusion IA Aikidoa détecté quelque chose d'intéressant dans les applications SvelteKit déployées sur Vercel.
- Nous avons confirmé qu'il s'agissait d'une vulnérabilité de type « cache deception » affectant les configurations par défaut.
- Aucune configuration incorrecte requise. SvelteKit + Vercel font simplement ce qu'ils sont censés faire.
- Impact : les réponses authentifiées peuvent être mises en cache et exposées à d'autres utilisateurs.
- Toute application SvelteKit fonctionnant sur Vercel avec des points de terminaison protégés peut être affectée.
Comment vérifier si vous êtes concerné
Utilisation de Aikido:
Si vous Aikido , vérifiez votre flux central. Vous pouvez consulter le problème dans Aikido ici. Conseil : Aikido vos référentiels chaque nuit, mais nous vous recommandons également de lancer une analyse complète.
Si vous n'êtes pas encore un utilisateur Aikido, créez un compte et connectez vos dépôts. Notre couverture propriétaire des malwares est incluse dans le plan gratuit (aucune carte de crédit requise).
Le test d'intrusion IA et l'analyse de sécurité Web Aikido détectent automatiquement les flux de tromperie de cache et les comportements de réécriture non sécurisés.
Statut de correction
Nous avons communiqué cette information à Vercel le 21 janvier 2026.
Chronologie
- 20 janvier 2026: Aikido a identifié la vulnérabilité et développé un PoC fonctionnel.
- 21 janvier 2026: divulgation responsable à Vercel
- 23 janvier 2026: Rapport trié
- 9 février 2026: Vercel confirme le rapport et commence à travailler sur une solution.
- 19 février 2026 : Vercel a corrigé la vulnérabilité pour tous les utilisateurs et publié un avis (GHSA-9pq4-5hcf-288c). Le problème peut être consulté dans la base de données IntelAikido et porte le numéro CVE réservé suivant : CVE-2026-27118.
Nous avons également trouvé un autre problème qui permettait un déni de service dans une fonctionnalité expérimentale de SvelteKit. Celui-ci a également été divulgué et corrigé.
