Next.js : deux failles critiques permettent une exécution de code à distance sans authentification
Vercel a publié un correctif d'urgence pour deux vulnérabilités critiques dans Next.js, permettant à un attaquant non authentifié d'exécuter du code arbitraire sur le serveur. Ces brèches, exploitable via une image AVIF malveillante ou une traversée de répertoire spécifique aux environnements Windows, exigent une mise à jour immédiate de toutes les applications exposées.
En bref
- RCE via AVIF : Une image AVIF spécifiquement conçue peut déclencher l'exécution de code arbitraire côté serveur lors de son traitement, sans aucune authentification préalable.
- Path Traversal sur Windows : Sur les systèmes d'exploitation Windows, une manipulation des chemins de fichiers permet de lire ou d'écrire des fichiers sensibles en dehors du répertoire racine de l'application.
- Impact critique : Ces deux failles se classent au niveau "Critical" (CVSS élevé) car elles permettent une prise de contrôle totale du serveur hébergeant l'application Next.js.
- Correctif disponible : Les versions affectées sont désormais obsolètes ; la mise à jour vers les dernières versions de
nextet des packages associés est impérative. - Vulnérabilité systémique : Ces incidents soulignent les risques liés au traitement de fichiers binaires et à la gestion des chemins dans les frameworks Node.js modernes.
Analyse technique de la RCE via image AVIF
La première vulnérabilité repose sur une faille de logique dans le pipeline de traitement des images de Next.js. Bien que le framework optimise et transforme les images par défaut (via next/image), le mécanisme interne de décodage et de manipulation des flux binaires contenait une faille critique.
Un attaquant pouvait soumettre une image au format AVIF contenant des métadonnées ou une structure de flux spécifiquement corrompue. Lors du traitement de cette image par les dépendances natives ou les workers Node.js chargés par Next.js, cette structure anormale contournait les contrôles de sécurité et permettait l'injection de commandes système. Contrairement aux failles classiques d'injection SQL ou XSS, ici, l'exécution se produit dans le processus serveur lui-même, offrant un accès direct au système d'exploitation sous-jacent (Linux, macOS ou Windows).
L'aspect le plus dangereux réside dans l'absence de prérequis d'authentification. Il suffisait d'envoyer une requête HTTP standard vers un endpoint acceptant des uploads ou affichant des images. Cette vector d'attaque est particulièrement redoutable pour les architectures serverless ou les conteneurs Docker exposés publiquement, où l'isolation réseau est souvent limitée à la seule couche applicative.
Pour les consultants IT, il est crucial de comprendre que ce type de faille ne se limite pas à une simple erreur de configuration. Il s'agit d'un bug dans la librairie de manipulation d'images intégrée ou utilisée par Next.js. La correction nécessite donc la mise à jour du noyau du framework, pas seulement la configuration de next.config.js.
La traversée de répertoire sur les serveurs Windows
La seconde faille exploite une différence fondamentale dans la gestion des chemins de fichiers entre Unix/Linux et Windows. Sur les systèmes POSIX, la séparation des répertoires est /, tandis que Windows utilise \. De plus, Windows gère les entrées de disque (comme C:\) et les chemins relatifs de manière distincte.
Next.js, en tentant de normaliser les chemins pour servir des fichiers statiques ou des assets dynamiques, présentait une faille de logique sur les environnements Windows. Un attaquant pouvait construire une requête contenant des séquences de chemin (comme ..\..\) qui, après normalisation incomplète par le framework, pointaient vers des fichiers sensibles tels que :
.env(contenant des clés API, mots de passe de base de données).- Fichiers de configuration du système (
system.ini,boot.ini). - Fichiers de journaux (logs) contenant des données utilisateur ou des tokens de session.
Cette vulnérabilité est particulièrement piégeuse car la majorité des tests de sécurité et des scans automatisés (comme OWASP ZAP ou Burp Suite) sont souvent calibrés sur des environnements Linux. Les tests de path traversal standard (../../etc/passwd) échouent souvent sur Windows si le framework ne gère pas correctement les convertisseurs de caractères. Il fallait une connaissance précise des spécificités de l'implémentation de Next.js sur Windows pour exploiter cette faille.
Pour les équipes d'infrastructure, cela rappelle que la sécurité des applications web ne peut pas être dissociée de l'OS d'hébergement. Une application testée sur un conteneur Linux n'est pas nécessairement aussi sûre lorsqu'elle est déployée sur une VM Windows, et vice-versa.
Impact sur l'architecture et les environnements serverless
L'impact de ces deux failles est maximal dans les environnements "Serverless" ou conteneurisés, qui sont devenus la norme pour le déploiement de Next.js via Vercel ou des solutions on-premise basées sur Docker/Kubernetes.
- Exfiltration de données sensibles : La path traversal permet de voler les secrets stockés dans les variables d'environnement. Dans une architecture microservices, cela signifie que la compromission d'un seul service Next.js peut entraîner la compromission de l'ensemble de la chaîne d'appels (BDD, API externes, stockage objet).
- Persistance et Pivotage : La RCE via AVIF permet d'installer des backdoors, de miner des cryptomonnaies (cryptojacking) ou de pivoter vers d'autres services sur le même réseau interne.
- Intégrité des données : Un attaquant avec un accès root (obtenu via RCE) peut modifier les données en base, altérer les logs pour masquer sa présence, ou injecter du code malveillant dans les fichiers statiques servis par l'application.
Il est important de noter que ces failles n'affectent pas seulement les sites de marketing. Tout backend API construit avec Next.js (via getServerSideProps ou les API Routes) est potentiellement vulnérable si les images sont traitées dynamiquement ou si les chemins de fichiers sont manipulés sans validation stricte.
Procédure de mitigation et vérification
La seule mitigation fiable est la mise à jour du package next et de ses dépendances associées. Il ne suffit pas de patcher une seule dépendance ; l'écosystème complet doit être aligné sur la version corrigée.
1. Vérification de la version actuelle
Avant toute action, identifiez la version installée dans votre projet :
# Dans le répertoire racine de votre projet Next.js
cat package.json | grep '"next"'
# Ou via npm
npm list next
2. Mise à jour des dépendances
Mettez à jour next et assurez-vous que les dépendances d'images (comme sharp si utilisé) sont également à jour.
# Mettre à jour Next.js à la dernière version stable
npm install next@latest
# Mettre à jour les dépendances liées au traitement d'images
npm install sharp@latest
# Nettoyer le cache potentiellement corrompu ou contenant des assets malveillants
npm cache clean --force
rm -rf .next
rm -rf node_modules
npm install
3. Vérification post-patch
Après la mise à jour, effectuez un redémarrage complet de l'application et vérifiez les logs pour détecter toute activité suspecte antérieure.
# Redémarrer le serveur de développement ou de production
npm run dev
# ou
npm run build && npm start
4. Audit des fichiers accessibles
Si vous avez exploité la faille de path traversal, vérifiez quels fichiers ont pu être lus. Sur Linux, examinez les accès au fichier .env :
# Vérifier les timestamps d'accès au fichier .env (si atime est activé)
stat .env
Sur Windows, consultez l'historique d'accès des fichiers via l'outil de gestion des fichiers ou les logs de sécurité Windows.
Bonnes pratiques pour consultants IT
Face à ce type de vulnérabilité, les consultants IT doivent adopter une approche proactive de la sécurité applicative :
- Séparation des environnements de test : Ne testez jamais uniquement sur Linux si votre production cible Windows, et inversement. Les failles de path traversal sont souvent spécifiques à l'OS.
- Principe du moindre privilège : Assurez-vous que le processus Node.js tournant Next.js dispose des droits strictement nécessaires. Même en cas de RCE, des droits limités (pas de root/admin) réduisent l'impact.
- Surveillance des dépendances : Utilisez des outils comme
npm auditou Snyk pour détecter les vulnérabilités connues dans les dépendances transitoires. Les failles comme celle de l'AVIF peuvent résider dans des librairies tierces intégrées. - Isolation réseau : Dans les environnements Kubernetes ou Docker, isolez les pods exécutant Next.js. Limitez les ports exposés et utilisez des politiques réseau (Network Policies) pour empêcher le pivotage interne en cas de compromission.
- Chiffrement des secrets : Ne stockez jamais de secrets dans des fichiers texte accessibles via le filesystem de l'application (comme
.env) sans un mécanisme de chiffrement au repos ou une gestion de secrets dédiée (HashiCorp Vault, AWS Secrets Manager).
Points cles
- Mise à jour immédiate : Toutes les instances de Next.js doivent être mises à jour vers la dernière version stable pour corriger la RCE via AVIF et la path traversal Windows.
- Spécificité OS : La faille de path traversal est spécifique aux environnements Windows, soulignant la nécessité de tests multi-OS.
- Risque d'exfiltration : Les secrets stockés dans les variables d'environnement sont la cible principale de la traversée de répertoire.
- Vulnérabilité des images : Le traitement des fichiers binaires (images) reste un vecteur d'attaque majeur dans les frameworks web modernes.
- Réponse d'incident : En cas de suspicion d'exploitation, isolez le serveur, sauvegardez les logs, et effectuez une rotation complète de toutes les clés API et mots de passe exposés.
Ces deux failles rappellent que la sécurité logicielle est un domaine en constante évolution. La rapidité de réaction des éditeurs comme Vercel est un atout, mais la vigilance des équipes IT reste la première ligne de défense. En intégrant ces vérifications dans vos routines de maintenance et de déploiement, vous réduisez significativement la surface d'attaque de vos applications Next.js.
Source : IT Connect