Next.js — 13 failles corrigées en mai 2026 : ce que tu dois savoir et faire
Next.js vient de publier un patch de sécurité majeur en mai 2026 : 13 vulnérabilités corrigées, dont des bypasses d'autorisation, du SSRF et du cache poisoning. Voici ce qui a été patché, pourquoi c'est sérieux, et comment vérifier que ton app est clean.
13 vulnérabilités. Un patch publié discrètement un mardi. Et des milliers d'apps Next.js en production qui tournent encore sur des versions exposées. La bonne nouvelle : corriger prend 10 minutes. Encore faut-il savoir qu'on est concerné.
Le 13 mai 2026, Vercel a publié une mise à jour de sécurité pour Next.js couvrant 13 vulnérabilités réparties sur les versions 15.x et 16.x. Les deux versions cibles sont :
15.5.18
16.2.6
Si ton app tourne sur une version antérieure à l'une de ces deux releases, elle est potentiellement exposée.
Ce n'est pas un patch de routine. Plusieurs failles classées High ont été corrigées, ce qui signifie qu'elles sont exploitables sans conditions particulièrement complexes. Aucune exploitation active connue au moment de la publication — mais avec un projet open source aussi suivi, les PoC (preuves de concept) émergent souvent dans les jours qui suivent un patch.
Bypass d'autorisation via le middleware (App Router)#
C'est la faille qui attire le plus l'attention. Le middleware Next.js, utilisé pour protéger des routes (authentification, rôles, redirections), pouvait dans certaines configurations être contourné.
Concrètement : un utilisateur non authentifié pouvait accéder à des routes que le middleware était censé bloquer. Si tu utilises le middleware pour garder des espaces membres, des dashboards admin, ou des API privées — c'est directement dans le scope.
Ce n'est pas une nouveauté dans l'écosystème Next.js. Une faille similaire (CVE-2025-29927) avait déjà agité la communauté début 2025, permettant de bypasser le middleware via une manipulation du header x-middleware-subrequest. L'histoire se répète, les patterns aussi.
Signal d'alerte : si ton middleware ressemble à ça et que tu n'as pas patché —
// middleware.tsexport function middleware(request: NextRequest) { const token = request.cookies.get("token"); if (!token) return NextResponse.redirect(new URL("/login", request.url));}
Il ne faut jamais supposer que le middleware est la seule ligne de défense. La vérification d'auth doit aussi exister côté serveur (dans les Server Components, les Route Handlers ou l'ORM).
Le SSRF permet à un attaquant de forcer le serveur à effectuer des requêtes HTTP vers des ressources internes — metadata AWS (169.254.169.254), services internes non exposés publiquement, autres microservices du réseau.
Sur une app Next.js déployée sur Vercel ou sur un VPS, une faille SSRF bien exploitée peut donner accès aux variables d'environnement de la machine, aux tokens de service, ou permettre de pivoter vers d'autres services.
C'est une faille classée dans l'OWASP Top 10 depuis 2021 (A10:2021), et elle est particulièrement redoutable sur les architectures headless ou les apps qui agrègent des données depuis plusieurs sources externes.
Le cache poisoning consiste à injecter une réponse malveillante dans le cache d'une app, de sorte que tous les utilisateurs suivants reçoivent le contenu empoisonné. Sur une app Next.js avec ISR (Incremental Static Regeneration) ou une logique de cache custom, une réponse malveillante peut persister et être servie à grande échelle.
Le risque concret : modification de contenu affiché (défacement fonctionnel), injection de liens malveillants dans des pages statiques, ou dégradation ciblée d'une page de conversion.
React : 19.0.6, 19.1.7, 19.2.6 pour les packages react-server-dom-parcel, react-server-dom-webpack et react-server-dom-turbopack
Les frameworks et bundlers utilisant les packages react-server-dom-* doivent installer les dernières versions fournies par leurs mainteneurs respectifs.
Lance ta suite de tests — si tu en as une, c'est le moment de la faire tourner.
Teste manuellement les routes protégées par middleware : déconnecte-toi et tente d'accéder directement à /dashboard, /admin, /api/protected.
Vérifie tes variables d'environnement : rien d'exposé côté client qui ne devrait pas l'être (NEXT_PUBLIC_ prefix).
Inspecte tes headers HTTP : X-Frame-Options, Content-Security-Policy, Strict-Transport-Security. Des outils comme securityheaders.com font ça en deux clics.
Ce que ce patch révèle sur l'architecture Next.js#
Ce n'est pas une critique de Next.js — c'est un framework excellent, activement maintenu, avec une équipe sécurité réactive. Mais ce patch est l'occasion de remettre à plat quelques convictions qui traînent dans les équipes :
Non. Le middleware est une première ligne, pas une garantie. L'authentification doit être vérifiée au plus près de la donnée sensible : dans le Server Component, dans le Route Handler, dans la query ORM.
Si tu as un espace connecté, des formulaires, des webhooks ou des appels API — tu as des données sensibles. La surface d'attaque ne se limite pas aux bases de données.
Je propose des audits de sécurité orientés Next.js — middleware, API routes, gestion des sessions, exposition des variables d'environnement, headers HTTP — et du renfort ponctuel si tu veux qu'on passe en revue l'existant ensemble.
Pas de rapport de 80 pages incompréhensible. Un audit actionnable, avec des findings classés par priorité et des recommandations concrètes adaptées à ta stack.
