Contournement du middleware Next.js : CVE-2026-44575

La faille

Le middleware Next.js (renommé proxy dans les versions récentes) s’exécute avant le rendu de la page. Beaucoup d’équipes y placent leur contrôle d’accès :

```typescript

// middleware.ts

export function middleware(request: NextRequest) {

const token = request.cookies.get('session')

if (!token) {

return NextResponse.redirect(new URL('/login', request.url))

}

}

export const config = { matcher: ['/dashboard/:path*'] }

`

Ce code protège /dashboard. Mais l’App Router ne sert pas une page par une seule URL. Pour la navigation côté client et le prefetch, il utilise des variantes de transport : des requêtes vers des URL suffixées en .rsc ou des URL de prefetch de segment, qui renvoient le contenu sérialisé des Server Components. Selon l’avis GitHub, des URL .rsc et de prefetch de segment spécialement construites aboutissent à la même page sans correspondre à la règle du middleware. Le contrôle ne s’exécute pas, le contenu protégé est renvoyé.

• Identifiants : CVE-2026-44575, GHSA-267c-6grr-h53f, classée CWE-288 (contournement d’authentification par un chemin alternatif).
• Sévérité : élevée, CVSS 7.5, impact en confidentialité.
• Versions affectées : 15.2.0 à 15.5.15, 16.0.0 à 16.2.4.
• Versions corrigées : 15.5.16 et 16.2.5. Le correctif étend les matchers du middleware aux variantes de transport de l’App Router.
• Correctif incomplet : une alerte de suivi (GHSA-26hh-7cqf-hhc6) traite un contournement résiduel. La version de référence de la série de mai est 15.5.18 ou 16.2.6, et Next.js 13.x et 14.x doivent migrer vers l’une d’elles.

Les trois autres contournements de la même série

La même publication de mai 2026 liste trois autres alertes de sévérité élevée qui visent les applications utilisant middleware.js ou proxy.js pour l’autorisation :

1. le contournement du prefetch de segment, suite au correctif incomplet ;
2. dans le Pages Router avec i18n, le chemin de la locale par défaut contourne l’autorisation du proxy : la route de données non préfixée renvoie le JSON SSR d’une page protégée ;
3. un contournement par injection de paramètre de route dynamique.

Vercel indique qu’aucune règle de WAF ne bloque ces attaques de façon fiable : seule la mise à jour corrige.

Pourquoi ce motif revient

Ce n’est pas le premier contournement du middleware. En 2025, CVE-2025-29927 permettait déjà de sauter le middleware avec un simple en-tête. Le problème de fond ne change pas : le middleware raisonne sur une URL, alors que le framework sait servir la même ressource par plusieurs chemins (préfixes de langue, données JSON, flux RSC, prefetch). Chaque nouveau chemin est une occasion de rater la règle.

Comment le tester

Sur votre propre application, en préproduction de préférence :

1. Version : npm ls next donne la version réellement installée. Toute version inférieure à 15.5.18 ou 16.2.6 est à mettre à jour.
2. Inventaire : listez les routes dont la protection repose uniquement sur middleware.ts ou proxy.ts. Ce sont elles qui comptent.
3. Requête de référence : sans cookie de session, curl -i https://app.exemple.fr/dashboard doit renvoyer une redirection vers /login.
4. Variantes de transport : rejouez la même requête sans session en ajoutant l’en-tête RSC: 1, puis sur la variante .rsc de la page, et en mode prefetch (Next-Router-Prefetch: 1). Si la réponse est un 200 qui contient des données de la page protégée au lieu d’une redirection ou d’un 401, la page est atteignable sans contrôle.
5. Pages Router et i18n : si vous utilisez i18n, testez la route de données /_next/data/<buildId>/<page>.json avec et sans préfixe de locale.
6. Contrôle côté serveur : pour chaque page sensible, vérifiez qu’une requête sans session échoue aussi quand le middleware est désactivé localement. Si elle passe, votre seule barrière est le middleware.

Comment corriger

Tout de suite

Mettez à jour vers 15.5.18 ou 16.2.6 (ou plus récent), puis redéployez. Les versions mineures plus anciennes de 15.x et 16.x ne reçoivent pas de rétroportage.

Durablement

Gardez le middleware pour les redirections et l’ergonomie, mais vérifiez l’autorisation au plus près de la donnée :

• dans chaque Server Component ou layout qui lit des données sensibles (lecture de la session côté serveur) ;
• dans chaque Route Handler et chaque Server Action, comme expliqué dans notre article sur les erreurs de sécurité des Server Components ;
• dans la base elle-même, avec des politiques RLS si vous utilisez Supabase ou PostgreSQL.

Ainsi, quand un contournement du middleware sera de nouveau publié, il n’ouvrira qu’une page vide.

Et si un agent IA était concerné par le contournement du middleware Next.js CVE-2026-44575 ?

Beaucoup d’agents internes appellent l’application de l’entreprise par HTTP : un outil fetch_page ou un serveur MCP qui lit le tableau de bord, des factures ou des fiches clients. Si l’accès de l’agent est filtré par le même middleware, deux risques apparaissent. D’abord, un agent qui construit lui-même ses URL peut, sous l’effet d’une injection de prompt, appeler une variante .rsc qui échappe au filtre et récupérer des données hors de son périmètre. Ensuite, la réponse RSC sérialisée contient souvent plus de champs que la page affichée, et l’agent les lira et pourra les recopier ailleurs. La protection doit donc s’appliquer côté serveur et vérifier l’identité de l’agent sur chaque route.

Si vous exposez une application Next.js à un agent, notre Red Team Agent Express teste en cinq jours ce que cet agent peut atteindre en dehors de ce qui était prévu.