Faille PHP2Shell et failles Next.js d'octobre 2026 : êtes-vous exposé ?
Octobre 2026 a apporté deux séries de failles web critiques, et les attaquants s'en sont pris à celles de PHP avant même que le correctif soit public. PHP2Shell (CVE-2026-109618 et CVE-2026-109619) peut permettre à une personne non connectée d'exécuter du code sur un serveur qui fait tourner PHP. PHP l'a corrigée le 21 octobre 2026 dans les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Une semaine plus tôt, le 14 octobre, Next.js a corrigé deux failles critiques d'exécution de code à distance et une faille de déni de service dans les versions 16.4.1 et 15.5.28. La CISA, l'agence américaine de cybersécurité, a inscrit les deux failles PHP sur sa liste des vulnérabilités exploitées activement le 26 octobre et a donné aux agences fédérales américaines jusqu'au 29 octobre pour appliquer le correctif.
Si votre boutique tourne sur WordPress avec WooCommerce, PrestaShop, Magento, OpenCart, Laravel ou tout autre logiciel PHP sur un hébergement que vous gérez, vous êtes concerné, et mettre à jour vos extensions ne réglera rien. C'est la version de PHP sous la boutique qui doit changer. Ce guide explique ce que fait chaque faille, ce qu'un attaquant peut prendre à une boutique en paiement à la livraison, comment vérifier vos versions et quelle version corrige quoi. Chaque date et chaque version ci-dessous vient des avis des éditeurs et des rapports d'entreprises de sécurité, lus le 29 octobre 2026.
Les failles d'octobre 2026 en un coup d'œil
| Faille | Identifiant | Gravité | Qui est exposé | Corrigée dans | Exploitée |
|---|---|---|---|---|---|
| Corruption mémoire de PHP quand une requête manque de mémoire | CVE-2026-109618 | Critique, 9,2 (CVSS 4.0, note de PHP) | Tout site PHP qui répond à des requêtes web | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Oui, catalogue CISA depuis le 26 oct. |
| État périmé de PHP réutilisé par la requête suivante | CVE-2026-109619 | Critique, 9,2 (CVSS 4.0, note de PHP) | Tout site PHP qui répond à des requêtes web | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Oui, catalogue CISA depuis le 26 oct. |
| Progression d'upload des sessions PHP | CVE-2026-115560 | Aucune note publiée | Seulement les applications qui passent session.serialize_handler à php pendant l'exécution | Pas encore corrigée, contournement disponible | Aucun signalement |
Exécution de code via use cache dans Next.js | GHSA-673q-mjm6-r5xr (pas de CVE) | Critique, 9,5 (CVSS 4.0, note de Next.js) | App Router avec Cache Components, de 16.0.0 à 16.4.0 | Next.js 16.4.1 | Absente du catalogue CISA |
| Optimisation d'images Next.js avec SVG | CVE-2026-96889, GHSA-2464-fhr4-w9xw | Critique, 9,5 (CVSS 4.0, note de Next.js) | Next.js sur Linux glibc, à partir de 10.0.0 | Next.js 16.4.1, 15.5.28 et sharp 0.35.5 | Absente du catalogue CISA |
| Déni de service des Server Actions de Next.js | CVE-2026-94482, GHSA-p3m5-59mp-jv5r | Élevée, 8,2 (CVSS 4.0, note de Next.js) | App Router avec au moins une Server Action, à partir de 13.0.0 | Next.js 16.4.1, 15.5.28 | Absente du catalogue CISA |
La colonne Exploitée renvoie au catalogue Known Exploited Vulnerabilities tel que publié le 29 octobre 2026. Les notes varient selon l'organisme : le NVD donne 9,8 à CVE-2026-109618 et 8,1 à CVE-2026-109619 sur l'ancienne échelle CVSS 3.1.
Ce qu'est PHP2Shell et pourquoi c'est grave
PHP2Shell, ce sont deux bugs distincts dans le moteur PHP lui-même, le programme qui fait tourner WordPress, WooCommerce, PrestaShop, Magento et la plupart des boutiques du web. PHP les décrit ainsi dans son avis :
- CVE-2026-109618 : quand une requête manque de mémoire, PHP peut être interrompu alors que ses données internes de requête ne sont qu'en partie préparées. L'étape de nettoyage traite ensuite ces données cassées comme valides. Un attaquant peut pousser une requête dans cet état avec une requête d'envoi de fichier forgée, même en restant dans les limites de taille normales du serveur.
- CVE-2026-109619 : un état interne qui appartient à une requête peut survivre après la libération de sa mémoire, et la requête suivante traitée par le même worker PHP peut s'en servir. PHP a confirmé l'exécution de code par la fonction de progression d'upload des sessions, active par défaut, et par le chemin de backtrace d'erreur de PHP 8.5.
Aucun des deux bugs ne demande de connexion, et avec mod_php le premier se déclenche avant même que le code de votre boutique démarre. PHP cite comme configurations exposées PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed, et juge le risque le plus élevé pour mod_php. Les chercheurs de Calif ont confirmé l'exécution de code avant connexion sur WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, Magento 2.4.9, phpMyAdmin 5.2.3, Laravel 13.11 et Symfony 8.1, entre autres.
Les versions touchées sont nombreuses. Les fiches du NVD commencent à PHP 7.3.0 pour le premier bug et à PHP 5.4.0 pour le second. Les branches 8.2 et plus récentes ont reçu des versions corrigées officielles. Pour PHP 7.4, 8.0 et 8.1, arrivées en fin de vie, l'équipe de sécurité de PHP a publié des correctifs minimaux du code source, et PHP 7.3 et les versions plus anciennes n'ont rien reçu de PHP.
Comment la divulgation s'est déroulée
Calif a signalé une exécution de code à distance à PHP le 11 août 2026, et Wiz a envoyé son propre rapport le 24 août. L'équipe Codex Security d'OpenAI a aussi trouvé une partie du problème. Le correctif était prévu pour le 22 octobre, mais les deux numéros CVE ont commencé à circuler sur des forums vers 15 h UTC le 20 octobre, si bien que PHP a avancé la publication au 21 octobre à 14 h UTC. Le soir du 20 octobre, Calif a aussi publié par erreur une vidéo de preuve de concept.
Le réseau de honeypots d'Amazon avait déjà enregistré une tentative d'exploitation le 17 octobre, quatre jours avant la divulgation. Le 24 octobre, un chercheur a signalé l'exploitation réussie de trois serveurs honeypot sous PHP 8.4.26, et le 26 octobre Trail of Bits a confirmé des exploits fonctionnels contre PHP 8.2 à 8.5 non corrigés. Un réseau public de capteurs géré par des chercheurs de Delft a compté plus de 73 900 requêtes d'exploitation venant de 676 adresses IP dans 73 pays entre le 21 et le 29 octobre.
Certains experts s'attendent à moins d'attaques de masse que ne le laissent penser les gros titres. Sansec, spécialiste de la sécurité des boutiques en ligne, a écrit qu'une attaque demande une connaissance précise du serveur visé, et Red Hat qualifie de difficile en pratique l'exécution de code sur sa configuration PHP-FPM standard. Aucun des deux ne dit qu'une boutique peut se passer de la mise à jour.
Ce qu'un attaquant peut faire sur une boutique piratée
L'exécution de code à distance signifie que le code de l'attaquant tourne avec les mêmes droits que celui de votre boutique. Sur une boutique PHP classique, cela donne accès au fichier de configuration qui contient le mot de passe de la base de données, et de là à toutes les tables. Pour une boutique qui vend en paiement à la livraison en Algérie, la base de données, c'est l'activité elle-même : le nom, le numéro de téléphone, la wilaya, la commune et l'adresse complète de chaque acheteur, plus l'historique de ses commandes.
Le même accès atteint les clés API enregistrées dans vos réglages : comptes chez les transporteurs, services d'envoi de SMS ou WhatsApp, jetons des pixels Facebook et TikTok. Un attaquant peut aussi modifier la page de commande, remplacer le numéro de téléphone que les acheteurs appellent ou déposer un fichier caché qui lui permet de revenir après votre mise à jour.
Ce que les attaquants ont fait en octobre est documenté. Les capteurs de Delft ont enregistré des droppers qui téléchargent des bots dérivés de Mirai, qui se servent du serveur piraté pour saturer d'autres sites, et une porte dérobée écrite en Nim qui se fait passer pour un programme appelé « sysmon ». Le 28 octobre, la CISA a ajouté une faille du noyau Linux, CVE-2026-46300, en notant qu'elle peut être enchaînée avec PHP2Shell pour déposer des webshells PHP et exécuter des commandes en root, le plus haut niveau de contrôle sur la machine.
Au 29 octobre, aucun rapport public ne cite de boutique piratée par PHP2Shell, et aucune source ne signale de skimmers de cartes bancaires diffusés par cette faille. Une porte dérobée déposée pendant la période qui a précédé votre mise à jour peut rester après celle-ci, donc les vérifications des sections suivantes comptent même sur un serveur déjà à jour.
Mon site PHP est-il touché ?
Toute version de PHP sans les correctifs d'octobre est touchée. Votre situation dépend de qui fait tourner PHP pour vous.
Plateforme de boutique hébergée. La plateforme fait tourner PHP pour vous, c'est donc à elle d'appliquer le correctif. Posez-lui la question si elle n'a rien dit (la réponse de DZBuild se trouve à la fin de ce guide).
Hébergement mutualisé avec cPanel ou Plesk. Le panneau affiche la version de PHP, mais les distributions gardent souvent l'ancien numéro sur une version corrigée. cPanel a livré le correctif dans EasyApache 4, version 25.91, le 21 octobre pour ea-php74 à ea-php85. Plesk indique que ses versions 7.4, 8.0 et 8.1 en fin de vie gardent le même numéro de version, et que le correctif se reconnaît à une date de compilation du 21 octobre 2026 ou plus récente.
Votre propre serveur (VPS). La commande php -v affiche le PHP en ligne de commande, qui peut être différent du PHP qui sert vos pages web. Vérifiez plutôt le journal des modifications du paquet :
php -v
# Debian and Ubuntu: replace 8.3 with your PHP branch
zgrep CVE-2026-109618 /usr/share/doc/php8.3-common/changelog.Debian.gz
# Red Hat, AlmaLinux, Rocky Linux
rpm -q --changelog php-common | grep CVE-2026-109618
Une ligne qui mentionne la CVE signifie que votre paquet contient le correctif. Masquer l'en-tête X-Powered-By avec expose_php = Off ne vous protège pas ; l'analyse de VirusTotal le résume simplement : cela cache l'en-tête, pas la vulnérabilité.
Comment corriger PHP2Shell
Sur un hébergement mutualisé, écrivez à votre hébergeur et posez-lui ces questions précises : quelle version de PHP sert mon site, et inclut-elle les correctifs de CVE-2026-109618 et CVE-2026-109619 ? Les workers PHP ont-ils été redémarrés après la mise à jour ? Une bonne réponse cite 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou une version de distribution qui liste les deux CVE, et confirme le redémarrage.
Sur un serveur Debian ou Ubuntu, installez les mises à jour et redémarrez PHP. Installer un paquet ne corrige pas les processus PHP déjà en cours d'exécution, donc le redémarrage fait partie du correctif :
sudo apt update
sudo apt upgrade
# replace 8.3 with your branch
sudo systemctl restart php8.3-fpm
# if your site uses Apache with mod_php
sudo systemctl restart apache2
Les paquets corrigés sont 8.2.35-1deb12u1 sur Debian 12, 8.4.27-1deb13u1 sur Debian 13 et 8.3.6-0ubuntu0.24.04.13 sur Ubuntu 24.04. Pour confirmer que le PHP-FPM en cours d'exécution utilise le nouveau binaire, lancez sudo ls -l /proc/$(pgrep -o php-fpm)/exe : le mot (deleted) à la fin signifie que l'ancien programme est encore en mémoire et que le redémarrage n'a pas eu lieu.
Avec Docker, récupérez une image officielle corrigée comme php:8.5.12-fpm, php:8.4.27-apache ou php:8.3.36-fpm-alpine, reconstruisez votre image et redéployez-la. L'image officielle de PHP n'a reçu aucun correctif pour 8.1 et les versions plus anciennes.
Sur PHP 8.1 ou plus ancien, passez à une branche maintenue. PHP 8.2 arrive en fin de vie le 31 décembre 2026, donc 8.4 ou 8.5 vous laisse plus de temps. Des versions avec correctifs rétroportés existent dans le dépôt d'Ondřej Surý et chez Remi, Ubuntu Pro, Freexian et TuxCare si vous avez besoin de quelques semaines de plus.
Si vous ne pouvez pas mettre à jour aujourd'hui, PHP cite des mesures partielles : définir memory_limit=-1 de façon que les applications ne puissent pas le modifier, limiter post_max_size à 8M sans upload ou 32M avec upload, régler session.upload_progress.enabled=0 et, sur PHP 8.5, fatal_error_backtraces=0, puis redémarrer chaque worker. PHP précise que ces mesures ne bloquent que certains chemins d'attaque, et watchTowr juge les changements de configuration inefficaces. Cloudflare bloque les schémas d'attaque connus pour les clients de son WAF gratuit et payant depuis le 21 octobre à 3 h 02 UTC. Rien de tout cela ne remplace la mise à jour.
Après le correctif, cherchez des traces : fichiers PHP que vous n'avez pas envoyés, surtout dans les dossiers d'upload, tâches cron que vous n'avez pas créées, nouveaux comptes administrateur et requêtes POST contenant PHP_SESSION_UPLOAD_PROGRESS dans vos journaux. Si vous trouvez l'un de ces signes, nettoyez le serveur, puis changez le mot de passe de la base de données et chaque clé API qui y est enregistrée.
La troisième faille PHP : CVE-2026-115560
Le 23 octobre, PHP a publié un avis informatif sur un chemin distinct, « peu probable », d'exécution de code dans la progression d'upload des sessions. Il touche aussi PHP entièrement à jour, 8.5.12 compris. Il ne s'applique que lorsqu'une application règle session.serialize_handler sur php_binary ou php_serialize dans sa configuration, puis le passe à php avec ini_set() avant de démarrer la session.
PHP la corrigera dans sa prochaine version régulière, qui n'a pas encore de date, et publiera l'avis complet à ce moment-là. D'ici là, le contournement est le même réglage que ci-dessus, session.upload_progress.enabled=0. Le 29 octobre, la faille n'avait ni note CVSS ni fiche NVD, et aucune exploitation n'avait été signalée.
La mise à jour de sécurité Next.js du 14 octobre 2026
Next.js a annoncé la version le 8 octobre et l'a publiée le 14 octobre. Deux de ses trois correctifs n'avaient pas été inclus dans la version de sécurité du 30 septembre, le temps que les projets en amont se coordonnent. Les trois se trouvent dans 16.4.1 et 15.5.28.
La faille use cache (GHSA-673q-mjm6-r5xr). Dans les applications qui utilisent l'App Router avec Cache Components, une fonction use cache qui renvoie plusieurs tableaux typés peut mener à une exécution de code sans connexion. Elle touche 16.0.0 à 16.4.0. Next.js indique qu'il n'existe aucun contournement et demande à tous les utilisateurs de 16.x de mettre à jour, même sans une telle fonction. Le correctif React correspondant est sorti le même jour dans react-server-dom-webpack, -turbopack et -parcel 19.0.9, 19.1.10, 19.2.9 et 19.3.1. Aucun numéro CVE n'avait été attribué le 29 octobre.
La faille d'optimisation d'images (CVE-2026-96889, GHSA-2464-fhr4-w9xw). Next.js redimensionne les images avec la bibliothèque sharp, qui utilise librsvg pour lire les fichiers SVG. Un bug use-after-free dans librsvg, déclenché par un SVG forgé, peut mener à une exécution de code quand Next.js tourne sur un Linux basé sur glibc. Le correctif est sharp 0.35.5, sorti le 27 septembre avec librsvg 2.63.2. Next.js 16.4.1 et 15.5.28 relèvent leur exigence sur sharp, et toutes les versions de Next.js depuis 10.0.0 jusqu'à ces versions sont touchées. L'avis ne limite pas le risque aux sites qui ont activé l'option dangerouslyAllowSVG, et un dépôt tiers publié le 16 octobre affirme avoir un exploit de laboratoire qui fonctionne avec la configuration par défaut. Nous n'avons pas testé cette affirmation.
La faille des Server Actions (CVE-2026-94482, GHSA-p3m5-59mp-jv5r). Des requêtes forgées vers une application App Router qui a au moins une Server Action peuvent saturer le processeur et bloquer toutes les autres requêtes du même processus, ce qui peut mettre la boutique hors ligne. Les applications sous Pages Router ou sans Server Actions ne sont pas exposées. Elle touche 13.0.0 et les versions suivantes, et il n'existe aucun contournement.
Aucune des trois ne figurait dans le catalogue des failles exploitées de la CISA le 29 octobre, et la Cloud Security Alliance n'avait trouvé aucun signalement d'exploitation active au 15 octobre. Next.js a un antécédent récent : React2Shell (CVE-2025-55182), une faille notée 10,0 (CVSS 3.1) dans les React Server Components, divulguée en décembre 2025, est entrée au catalogue de la CISA deux jours après sa divulgation.
Next.js 13 et 14 n'ont reçu aucun correctif. Les deux ne sont plus maintenues. Les dernières versions sont 14.2.35 en décembre 2025 et 13.5.11 en mars 2025, et pourtant les deux entrent dans les plages touchées par les failles d'images et des Server Actions. La seule issue est 15.5.28 ou 16.4.1. Next.js 15 continue de recevoir des versions de sécurité jusqu'au 31 janvier 2027.
Comment vérifier et mettre à jour une boutique Next.js
Lancez ces commandes dans le dossier de votre projet :
npx next --version
npm ls next sharp
node -e "console.log(require('sharp').versions)"
Vous devez avoir Next.js 16.4.1 ou 15.5.28 (ou plus récent), sharp 0.35.5 ou plus récent, et une valeur rsvg de 2.63.2 ou plus dans la dernière sortie. La commande next info n'affiche pas sharp, vérifiez-le donc séparément. Pour mettre à jour :
npm install sharp@^0.35.5
Il y a un piège sur Next.js 15 : la version 15.5.28 accepte encore sharp 0.34.x, qui n'a jamais reçu de correctif, donc un fichier de verrouillage (lockfile) qui fige une ancienne version de sharp vous laisse exposé après la mise à jour de Next.js. Installez sharp explicitement comme indiqué ci-dessus. Si vous déployez avec output: 'standalone' dans Docker, l'image embarque les node_modules avec lesquels elle a été construite : reconstruisez-la et redéployez-la. Sur Netlify, les anciens deploy previews et branch deploys peuvent rester exposés jusqu'à leur suppression. Nous n'avons trouvé aucune déclaration de Vercel indiquant que les applications de sa plateforme étaient protégées automatiquement contre ces trois failles, donc mettez à jour et redéployez là aussi.
Node.js lui-même a eu une version de sécurité le 21 octobre avec 10 CVE, dont une faille du décodeur Brotli (CVE-2026-111497) qui peut mener à une exécution de code à distance. Les versions corrigées sont 22.23.4, 24.22.1 et 26.12.1. Node.js 20 est arrivé en fin de vie le 30 avril 2026 et ne reçoit aucun correctif.
Autres failles d'octobre 2026 qui touchent les boutiques en ligne
- Drupal Commerce Core (CVE-2026-118539) : un contournement d'accès classé « Highly critical », publié le 28 octobre et exploité activement. Corrigé dans 3.3.13 et 8.x-2.41. Drupal demande aux sites de vérifier leurs commandes pour repérer des incohérences.
- Magento et Adobe Commerce BlockStrap (CVE-2026-103849) : exécution de code sans connexion, notée CVSS 10,0, corrigée le 13 octobre dans APSB26-153 avec des correctifs manuels pour Magento Open Source 2.4.7-p10, 2.4.8-p5 et 2.4.9. Sansec n'avait encore vu aucune attaque sur des boutiques en production.
- Adobe Commerce PolyShell (CVE-2026-48356) : une faille d'envoi de fichiers connue depuis mars 2026, ajoutée au catalogue des failles exploitées de la CISA le 27 octobre.
- Paquets npm malveillants : la base d'avis de GitHub a publié 948 avis de malware npm entre le 1er et le 29 octobre 2026. Vérifiez tout paquet que vous ajoutez à une boutique JavaScript avant de l'installer.
Une checklist pour les marchands qui hébergent leur propre site
- Trouvez quelle version de PHP sert votre boutique, auprès de votre hébergeur ou avec les commandes ci-dessus.
- Mettez à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou une version de distribution qui liste les deux CVE.
- Redémarrez PHP-FPM ou Apache pour que le programme en cours d'exécution soit le nouveau.
- Quittez PHP 8.1 et les versions plus anciennes pour une branche maintenue.
- Si votre boutique utilise Next.js, passez à 16.4.1 ou 15.5.28 et à sharp 0.35.5, puis reconstruisez et redéployez.
- Cherchez les fichiers PHP, tâches cron et comptes administrateur inconnus.
- Si quelque chose semble anormal, changez le mot de passe de la base de données et chaque clé API après avoir nettoyé le serveur.
Boutiques DZBuild : rien à faire
Les marchands DZBuild ne gèrent pas de serveur, donc aucune des étapes ci-dessus ne les concerne. Les versions de sécurité PHP du 21 octobre 2026 tournaient sur les serveurs de DZBuild le 22 octobre, le lendemain de leur publication par PHP. Les boutiques DZBuild n'utilisent pas Next.js, donc les failles du 14 octobre ne les atteignent pas. La troisième faille PHP demande un réglage de session que DZBuild ne modifie jamais. Il n'y a rien à mettre à jour, aucun hébergeur à contacter et aucun serveur à redémarrer.
Si vous gérez une boutique WooCommerce ou PrestaShop auto-hébergée et préférez vendre plutôt que passer une semaine sur les mises à jour de sécurité, créez une boutique DZBuild gratuitement. Le paiement à la livraison, les listes de wilayas et de communes et les connexions aux transporteurs sont intégrés.
Questions fréquentes
Qu'est-ce que PHP2Shell ? PHP2Shell est le nom donné à deux failles du moteur PHP, CVE-2026-109618 et CVE-2026-109619, publiées le 21 octobre 2026. Les deux peuvent permettre à un attaquant non connecté d'exécuter du code sur un serveur web qui fait tourner PHP. PHP les note toutes les deux 9,2 sur 10 (CVSS 4.0, critique).
Quelles versions de PHP corrigent PHP2Shell ? PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026. Les distributions Linux livrent le correctif sous leurs propres numéros de version, par exemple 8.2.35-1~deb12u1 sur Debian 12 et 8.3.6-0ubuntu0.24.04.13 sur Ubuntu 24.04. Du côté du projet PHP, PHP 7.4, 8.0 et 8.1 n'ont reçu que des correctifs du code source, et PHP 7.3 et les versions plus anciennes n'ont reçu aucun correctif.
Mettre à jour WordPress, WooCommerce ou PrestaShop corrige-t-il PHP2Shell ? Non. Les failles se trouvent dans le moteur PHP, pas dans le logiciel de la boutique. Seule une mise à jour de PHP les corrige. PrestaShop l'a dit clairement : mettre à jour PrestaShop ou ses modules ne corrigera pas le problème et il n'existe aucun correctif PrestaShop à installer.
La faille PHP2Shell est-elle exploitée ? Oui. Amazon a observé une première tentative le 17 octobre 2026, quatre jours avant que le correctif soit public, et la CISA a ajouté les deux CVE à son catalogue Known Exploited Vulnerabilities le 26 octobre 2026. Au 29 octobre, un réseau public de capteurs avait enregistré plus de 73 900 requêtes d'exploitation venant de 676 adresses IP dans 73 pays.
Comment savoir si ma boutique a été piratée par PHP2Shell ? Cherchez des fichiers PHP que vous n'avez pas envoyés, surtout dans les dossiers d'upload, des tâches cron que vous n'avez pas créées, de nouveaux comptes administrateur et des requêtes POST contenant PHP_SESSION_UPLOAD_PROGRESS dans les journaux du serveur. Si vous trouvez l'un de ces signes, considérez le serveur comme compromis et changez le mot de passe de la base de données et chaque clé API qui y est enregistrée après l'avoir nettoyé.
Quelles versions de Next.js corrigent les failles d'octobre 2026 ? Next.js 16.4.1 et 15.5.28, publiées le 14 octobre 2026. Vérifiez aussi que la bibliothèque d'images sharp est en version 0.35.5 ou plus récente, car Next.js 15.5.28 accepte encore une ancienne version de sharp qui reste vulnérable à CVE-2026-96889.
Next.js 14 est-il encore sûr ? Non. Next.js 13 et 14 ne sont plus maintenus et n'ont reçu aucun correctif en octobre 2026, alors qu'ils entrent dans les plages de versions touchées par la faille d'optimisation d'images et par le déni de service des Server Actions. Les seules versions corrigées sont 15.5.28 et 16.4.1.
Les marchands DZBuild doivent-ils faire quelque chose ? Non. Les versions de sécurité PHP du 21 octobre 2026 tournaient sur les serveurs de DZBuild le 22 octobre, les boutiques DZBuild n'utilisent pas Next.js, et la troisième faille PHP demande un réglage de session que DZBuild ne modifie jamais. Les marchands n'ont rien à mettre à jour.
Sources
- PHP, annonce de la version de sécurité et avis GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp, 21 octobre 2026 : php.net
- PHP Foundation, récit de la publication et de la fuite, 21 octobre 2026 : thephp.foundation
- CISA, catalogue Known Exploited Vulnerabilities, version du 29 octobre 2026 : cisa.gov
- Amazon Threat Intelligence, exploitation avant la divulgation : aws.amazon.com
- Delft, télémétrie de l'exploitation en direct, mise à jour le 29 octobre 2026 : php2shell.delftintellab.com
- Sansec, PHP2Shell et les boutiques en ligne, 21 octobre 2026 : sansec.io
- Calif, applications touchées : calif.io
- Next.js, mise à jour de sécurité du 14 octobre 2026 : nextjs.org
- Avis sharp GHSA-wq5f-xc86-pv6w : github.com
- Node.js, versions de sécurité d'octobre 2026 : nodejs.org
- Drupal, SA-CONTRIB-2026-254 : drupal.org