Un bug dans les images OG de Next.js peut exécuter du code sur votre serveur. Mettez à jour vers la 16.3.6.

Un bug dans les images OG de Next.js peut exécuter du code sur votre serveur. Mettez à jour vers la 16.3.6.

Vercel a publié une version exceptionnelle de Next.js le 22 septembre, et si vous générez des images Open Graph depuis votre application, lisez ceci avant tout autre chose aujourd'hui. La mise à jour, versions 16.3.6 et 15.5.26, corrige une faille critique d'exécution de code à distance dans next/og, référencée CVE-2026-94545 (avis GHSA-vcvr-r3jv-pc5j). Le score CVSS est de 9,5. C'est à peu près le pire qu'un bug de framework puisse atteindre.

La faille se trouve dans la version Node.js de ImageResponse, l'outil que la plupart des équipes utilisent pour créer des cartes de partage dynamiques : ces petits aperçus avec titre et miniature qui apparaissent lorsque vous partagez un lien sur Slack, LinkedIn ou dans un groupe de discussion. En coulisses, ImageResponse transmet votre JSX à Satori, qui le convertit en SVG, puis transforme ce SVG en PNG. La cause racine se situe une couche plus bas dans Satori, qui possède son propre avis (GHSA-wx4j-mvgx-mqwp) : il n'échappait pas certaines valeurs avant de les écrire dans le SVG. Ainsi, une valeur que vous pensiez être du texte brut pouvait s'échapper et être interprétée comme du balisage SVG actif. Lorsque le moteur de rendu traite ensuite ce balisage, une entrée contrôlée par un attaquant peut finir par s'exécuter sur votre serveur.

Êtes-vous réellement exposé ?

La condition qui vous rend vulnérable est spécifique, et il vaut la peine d'être honnête à ce sujet. Vous êtes exposé si vous utilisez ImageResponse en Node.js (le comportement par défaut de l'App Router lorsqu'une route n'opte pas pour Edge) et si vous injectez dans l'image une valeur contrôlée par un visiteur. Un mot extrait de l'URL. Un nom de profil. Un paramètre de chaîne de requête. Ce n'est pas un schéma exotique. C'est exactement la recette que tout le monde utilise pour créer une carte de partage par article. Si votre route OG ne rend que des titres codés en dur ou des valeurs issues d'une base de données de confiance, vous n'êtes pas dans la zone de danger. L'implémentation Edge de ImageResponse n'est pas non plus affectée.

Les versions concernées sont Next.js 16.2.0 à 16.3.5. La correction est dans la 16.3.6. Vercel a également publié la 15.5.26 le même jour, mais cette version n'est qu'un renforcement ; la branche 15.x n'était pas vulnérable à l'exécution de code à distance.

Le point qui piège tout le monde

Voici où nous passons beaucoup de temps lors des missions de pentest : mettre à jour le framework est nécessaire mais pas toujours suffisant. npm install next@16.3.6 met à niveau le Satori intégré à Next.js. Cela ne fait rien pour un satori ou un @vercel/og que vous avez ajouté à votre propre package.json. Nous voyons cela constamment. Une équipe met à jour la dépendance principale, le scanner continue d'alerter, et personne ne comprend pourquoi. Si vous utilisez Satori directement quelque part, mettez-le à niveau vers la version 0.33.5 ou ultérieure de manière indépendante, et vérifiez ce que votre fichier de verrouillage résout réellement plutôt que de vous fier à la version de niveau supérieur.

Ce qu'il faut faire cette semaine

Commencez par faire une recherche dans votre base de code pour next/og, opengraph-image et twitter-image. Si rien ne ressort, respirez et planifiez la mise à jour selon votre rythme habituel. Si quelque chose ressort, traitez chacune de ces routes comme accessible jusqu'à ce que vous l'ayez examinée. Posez une question par route : un visiteur peut-il influencer une valeur qui atteint l'image ? Ensuite, mettez à niveau vers la 16.3.6 (ou la 15.5.26 sur la branche 15), réinstallez pour que le fichier de verrouillage se mette à jour, recompilez et redéployez. Confirmez la version de Satori résolue dans la sortie compilée, pas seulement dans package.json.

Si vous ne pouvez vraiment pas déployer aujourd'hui, la solution de contournement officielle de Vercel est radicale mais efficace : arrêtez d'injecter des entrées non fiables dans l'image. Remplacez la valeur dynamique par un espace réservé sûr, ou déplacez la route vers le runtime Edge si elle fonctionne sans modifications. Aucune des deux n'est une solution à long terme. Toutes deux vous donnent un jour de répit.

La leçon plus large

Il y a un schéma ici, et c'est le même que Log4Shell et le récent bug de pollution de prototype d'axios nous ont appris. Les vulnérabilités dangereuses se trouvent rarement dans votre propre code. Elles se situent une ou deux couches plus bas, dans une bibliothèque largement utilisée qu'un framework intègre pour vous. Lorsque nous développons des applications cloud-native pour des clients entreprise, c'est pourquoi nous insistons sur une véritable nomenclature logicielle et une analyse automatisée des dépendances intégrée à la CI, et non sur un audit trimestriel. Vous voulez que les outils vous disent « vous déployez Satori 0.31, il est désormais vulnérable » le matin où l'avis est publié, pas trois semaines plus tard quand un client vous transmet un rapport d'analyse.

La forme injection-vers-RCE est aussi un rappel utile sur la façon dont vous pensez à tout moteur de rendu, côté serveur ou dans une application mobile. Tout ce qui prend une entrée structurée et produit un document (SVG, HTML, un PDF, un contenu WebView) est un endroit où « juste du texte » peut discrètement devenir « exécutable ». Dans nos projets iOS et Android natifs, nous appliquons la même règle à tout ce qui rend du contenu piloté par le serveur : échapper à la frontière, et ne jamais supposer que la couche inférieure l'a fait à votre place. La correction de Satori était exactement cela : échapper les valeurs de texte et d'attribut avant qu'elles n'atteignent le SVG. Le framework avait fait confiance à la bibliothèque pour faire quelque chose que la bibliothèque ne faisait pas.

Si vous souhaitez un regard extérieur sur les routes next/og que vos visiteurs peuvent réellement atteindre, c'est un travail de routine pour nous. Découvrez notre approche de la sécurité des applications web. Et si un avis critique tombant un vendredi après-midi sans que personne ne sache quelles routes sont exposées vous semble familier, parlons-en.

expert-analysisnextjssecuritytech-newsvulnerabilityweb-development