Publication du correctif de la faille de sécurité dans Next.js version 15.2.3

• CVE-2025-29927

• Next.js version 15.2.3 a été publiée pour corriger une faille de sécurité (CVE-2025-29927). Il est recommandé à tous les déploiements Next.js auto-hébergés utilisant next start et output: 'standalone' de procéder immédiatement à la mise à jour.

• Chronologie

  • 2025-02-27T06:03Z : signalé à l’équipe Next.js via un rapport de vulnérabilité privé sur GitHub
  • 2025-03-14T17:13Z : l’équipe Next.js commence l’examen du rapport
  • 2025-03-14T19:08Z : déploiement du correctif pour Next.js 15.x
  • 2025-03-14T19:26Z : déploiement du correctif pour Next.js 14.x
  • 2025-03-17T22:44Z : publication de Next.js 14.2.25
  • 2025-03-18T00:23Z : publication de Next.js 15.2.3
  • 2025-03-18T18:03Z : publication de CVE-2025-29927 sur GitHub
  • 2025-03-21T10:17Z : publication de l’avis de sécurité
  • 2025-03-22T21:21Z : publication de Next.js 13.5.9
  • 2025-03-23T06:44Z : publication de Next.js 12.3.5

• Détails de la vulnérabilité

  • Next.js utilise l’en-tête interne x-middleware-subrequest pour éviter les boucles infinies. Selon le rapport de sécurité, il existe une possibilité de contourner l’exécution du middleware, ce qui permettrait d’échapper à des vérifications critiques.

• Portée de l’impact

  • Cas affectés

    • Applications Next.js auto-hébergées utilisant le middleware (next start et output: 'standalone')
    • Cas où le middleware est utilisé pour l’authentification ou des contrôles de sécurité
    • Les applications utilisant Cloudflare peuvent activer des règles WAF managées

  • Cas non affectés

    • Applications hébergées sur Vercel
    • Applications hébergées sur Netlify
    • Applications déployées en export statique (le middleware n’est pas exécuté)

• Versions corrigées

  • Next.js 15.x : problème corrigé dans 15.2.3
  • Next.js 14.x : problème corrigé dans 14.2.25
  • Next.js 13.x : problème corrigé dans 13.5.9
  • Next.js 12.x : problème corrigé dans 12.3.5
  • S’il est impossible d’appliquer le correctif vers une version sûre, il est recommandé d’empêcher que les requêtes d’utilisateurs externes incluent l’en-tête x-middleware-subrequest

• Notre responsabilité en matière de sécurité

  • Depuis 2016, Next.js a publié 16 avis de sécurité. Les avis de sécurité GitHub et les CVE sont la norme du secteur pour informer les utilisateurs, fournisseurs et entreprises des vulnérabilités logicielles. Pour combler certaines lacunes dans la communication avec les partenaires, une liste de diffusion partenaires a été créée. Vous pouvez écrire à [e-mail] pour y être inclus.

[GN⁺]

Avis Hacker News

• Le système de middleware de Next pose de nombreux problèmes, et il vaudrait sans doute mieux le réimplémenter depuis zéro

  • Il n’existe pas de méthode officielle pour chaîner plusieurs middlewares
  • Les fonctions principales sont définies comme membres statiques, ce qui peut poser problème avec des middlewares tiers
  • Les moyens de communication entre les middlewares et les route handlers sont insuffisants
  • La méthode consistant à transmettre des données via les en-têtes n’est pas sûre
  • Cela oblige aussi à renoncer au caching automatique
  • Il est difficile d’obtenir le véritable nom d’hôte de la requête

• Découverte d’un autre article sur les problèmes de sécurité du système de middleware

  • Le mode de communication via les en-têtes est séparé de la validation des entrées utilisateur
  • Autoriser tous les en-têtes provenant de l’utilisateur peut être risqué
  • Un support du framework est nécessaire pour résoudre les problèmes de conception du serveur

• Informations sur la faille de sécurité de Next.js

  • Il existait une vulnérabilité permettant au serveur de renvoyer une réponse incorrecte en ajoutant un en-tête spécifique
  • Cette vulnérabilité n’a pas de CVE, et les versions affectées ne sont pas clairement identifiées
  • Selon la politique de support de Next.js, seules certaines versions reçoivent un correctif

• Inquiétudes concernant le retard dans la correction de la faille de sécurité de Next.js

  • Il a fallu plus de deux semaines après le signalement pour que la correction commence
  • Il est possible que la gravité du problème n’ait pas été correctement transmise

• Critique de la complexité de Next.js

  • React a apporté beaucoup de valeur, mais Next n’ajoute que de la complexité
  • Le routing basé sur les fichiers et le server-side rendering ne sont utiles que dans certains cas précis

• Simplicité d’exploitation de la faille de sécurité

  • Le simple ajout d’un en-tête spécifique permettait de contourner l’authentification

• Problème lié à l’utilisation d’en-têtes internes par Next.js

  • Il existe un en-tête interne destiné à éviter les requêtes récursives
  • Cet en-tête pourrait permettre de contourner des vérifications importantes

• Malaise concernant le choix de l’auto-hébergement de Next.js

  • Plus on lit les commentaires sur HN, plus le doute grandit sur ce choix

• Inquiétudes concernant le retard dans la résolution du problème de sécurité

  • Un délai de 13 jours pour corriger le problème est très préoccupant