PHP2Shell sur Synology : Comment nous avons corrigé six sites en une journée

PHP2Shell CVE-2026-109618 et CVE-2026-109619, deux failles critiques du moteur PHP permettant l'exécution de code à distance sans authentification, ont été désignées par l'industrie. Les détails ont fuité le 20 octobre 2026, la veille de la divulgation coordonnée, et le projet PHP a publié des correctifs d'urgence le 21 octobre. Le bogue se situant dans l'interpréteur et non dans une application, l'application de correctifs à WordPress, Joomla ou MediaWiki est inefficace. Seule une nouvelle version de PHP peut résoudre le problème. Nous hébergeons six sites WordPress publics sur du matériel Synology, et l'introduction de PHP2Shell a nécessité la reconstruction de chacun d'eux la même semaine. Ce guide explique la nature du bogue, comment le corriger sur DSM via le Centre de paquets, comment le gérer lorsqu'un site s'exécute dans un conteneur, et établit une comparaison pertinente entre les solutions proposées par le Synology et celles mises en œuvre par les autres fournisseurs de NAS.

Point SynoPower Club :Nos six sites ont été corrigés en moins d'une journée ouvrable après la publication de l'avis de sécurité concernant PHP2Shell. Ce qui a rendu cela possible, ce n'est pas un exploit, mais la publication par Synology de correctifs le jour même de l'avis. Le correctif Synology-SA-26:14 a été publié le 22 octobre avec le statut « Résolu » et un tableau complet des versions corrigées jusqu'à PHP 7.4. Le même jour, QNAP publiait QSA-26-18 avec le statut « En cours de correction » et la mention « À annoncer » dans chaque cellule de version corrigée. ASUSTOR a réagi en supprimant les anciennes versions de PHP d'App Central au lieu de les corriger. Si vous hébergez vous-même un site web public sur un NAS, ce délai n'est pas un argument marketing. Il fait toute la différence entre mettre à jour un paquet et rendre votre site inaccessible pendant l'attente.

Qu'est-ce que PHP2Shell et pourquoi est-il différent ?

PHP2Shell n'est pas un simple bug, mais un ensemble de défaillances liées à la gestion de la mémoire par PHP après une requête ayant entraîné une insuffisance de mémoire. PHP utilise longjmp() Pour éviter les erreurs fatales, y compris les erreurs de mémoire insuffisante, ce saut ignore le code de nettoyage qui permettrait normalement au moteur de retrouver un état connu. Une partie de cet état est globale et persiste lors de la prochaine requête traitée par le même processus.

La vulnérabilité CVE-2026-109618 est liée à une insuffisance de mémoire. Une requête HTTP malveillante épuise la mémoire alors que les données ne sont que partiellement initialisées, ce qui a pour conséquence que la routine de nettoyage parcourt des structures inachevées. La vulnérabilité CVE-2026-109619 est liée à une utilisation de mémoire libérée : un état global pointant vers la mémoire libérée lors d'une requête peut être lu par une requête ultérieure sur le même nœud de calcul, ce qui permet l'exécution de code ou la divulgation de données en mémoire.

Deux caractéristiques rendent PHP2Shell plus dangereux que les alertes PHP habituelles. Premièrement, il s'agit d'une vulnérabilité de pré-authentification. Les deux failles se déclenchent avant toute authentification au niveau de l'application ; par conséquent, un système de connexion, un plugin d'adhésion ou un mot de passe administrateur ne protègent en rien. Deuxièmement, la variante de divulgation de mémoire expose la mémoire du processus worker, et un worker PHP sur un site WordPress peut contenir des identifiants de base de données, des jetons d'API et des clés de paiement. Une simple lecture de mémoire n'a pas besoin d'atteindre l'exécution de code pour compromettre votre sécurité.

Les deux vulnérabilités PHP2Shell ont obtenu un score CVSS v4.0 de 9,2 selon l'équipe de sécurité PHP. Synology leur a attribué un score de 9,8 sur CVSS v3.1 dans son propre avis de sécurité. Des échelles différentes pour une même conclusion. Les rapports d'exploitation sont contradictoires : watchTowr indique avoir constaté des tentatives d'exploitation de son réseau de honeypots, tandis que Bitdefender n'a rien signalé dans ses données télémétriques au moment de la rédaction, et QNAP affirme n'avoir reçu aucun signalement d'exploitation ciblant spécifiquement ses produits.

PHP2Shell contre une faille de sécurité WordPress classique

La plupart des problèmes rencontrés sur un site WordPress public proviennent de failles de sécurité liées à des plugins. Le schéma est classique : un plugin introduit un point d'accès REST défectueux, un outil d'analyse le détecte, vous mettez à jour le plugin et la faille est corrigée. PHP2Shell rompt radicalement avec cette habitude, et l'audit systématique des plugins s'avère ici un effort vain.

Aspect	CVE typique des plugins	PHP2Shell
Là où vit l'insecte	Code de l'application (plugin ou thème)	L'interpréteur PHP lui-même
Qui peut le déclencher ?	Nécessite souvent un rôle d'abonné ou d'administrateur.	Personne. Pré-authentification, avant l'exécution de la logique de l'application.
La mise à jour de WordPress est-elle utile ?	Généralement oui	Non. Les mises à jour du noyau et des plugins sont sans importance.
Est-ce qu'un pare-feu applicatif féminin (WAF) l'empêche ?	Généralement, une fois qu'une règle existe	En partie. Les règles de forme de requête ne gèrent pas le chemin OOM.
Qu'est-ce qui le résout réellement ?	Mise à jour du plugin	Une nouvelle version de PHP, rien d'autre
Rayon d'explosion	Un site, une fonctionnalité	Tous les sites PHP hébergés sur le serveur, simultanément.

C’est cette dernière ligne qui explique pourquoi PHP2Shell a nécessité une journée entière de travail au lieu d’un après-midi. Un simple paquet PHP partagé sur un NAS peut être hébergé par une douzaine de machines virtuelles Web Station, et une seule image de conteneur peut servir de base à plusieurs sites. Les correctifs ne sont pas appliqués par site, mais par environnement d’exécution ; il faut donc recenser tous les environnements d’exécution avant de pouvoir considérer que le travail est terminé.

Comment savoir si votre NAS est exposé

L'évaluation de votre exposition à PHP2Shell commence par la distinction de deux questions distinctes : le système contient-il une version de PHP vulnérable et cette version est-elle accessible depuis Internet ? Synology établit explicitement cette distinction : DSM intègre un composant PHP interne utilisé par le système d'exploitation, et Synology précise qu'il ne comporte aucun module accessible de l'extérieur et, par conséquent, aucune surface d'attaque exposée. Le risque associé à ce composant est minime, et le correctif est prévu pour une version ultérieure de DSM afin que les analyses de vulnérabilité cessent de le signaler.

Les packages pertinents pour PHP2Shell sont ceux qui permettent d'exécuter du PHP sur le Web. La liste Synology comprend Calendar, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station et WordPress. Si vous avez installé et accessible l'un de ces packages, vous êtes concerné.

Vérifiez directement les versions plutôt que de vous fier à un tableau de bord. Dans le Centre de paquets, les paquets PHP installés affichent leur version sur la vignette, et la notification de mise à jour indique la version cible. Depuis un terminal, interrogez directement l'environnement d'exécution :

# Synology Package PHP (adaptez le chemin à la version que vous utilisez) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # Site conteneurisé docker exec php -v

La raison d'insister sur php -v Lors d'un audit PHP2Shell, il est crucial de vérifier que tous les autres signaux sont trompeurs. La sortie de compilation peut indiquer une réussite tout en réutilisant une couche en cache, un tableau de bord peut afficher un paquet comme étant à jour alors que le processus en cours d'exécution ne l'est pas, et un en-tête de réponse HTTP peut être supprimé par un CDN avant même que vous ne le voyiez. Deux de nos six sites étaient signalés comme opérationnels par leurs interfaces d'administration alors qu'ils utilisaient encore un interpréteur non patché.

Patch PHP2Shell sur Synology en 4 étapes

Pour un site Web Station sous DSM, la correction complète du problème PHP2Shell consiste en une mise à jour du Centre de paquets. Synology publie des correctifs de sécurité PHP pour DSM 7.4, 7.3 et 7.2. Après la mise à jour du paquet PHP, les paquets dépendants redémarrent automatiquement, ce qui résout le problème. Mail Station constitue une exception documentée et nécessite une mise à jour manuelle.

La capture d'écran ci-dessus provient de l'une de nos machines, le lendemain matin de la publication de l'avis de sécurité concernant PHP2Shell. Notez que le panneau « Nouveautés » indique directement la version amont, ce qui permet de faire correspondre le suffixe de build Synology à la version de PHP sans avoir à deviner. Synology Calendar apparaît dans la même liste de mises à jour à la version 3.0.4-21435, qui correspond exactement à la version recommandée par l'avis de sécurité.

Attention aux pièges de PHP2Shell pour les utilisateurs de Web Station : une machine DSM peut avoir plusieurs branches PHP installées simultanément, et chaque hôte virtuel est lié à un profil. La mise à jour du profil par défaut est sans effet sur un site associé à une autre branche. Commencez par lister les profils, mettez-les tous à jour, puis vérifiez la liaison de chaque site sous Web Service.

Quels sont les packages DSM concernés ?

Le message d'erreur concernant Synology sur PHP2Shell est plus restrictif que ne le laissait entendre le message d'erreur. Seuls les systèmes utilisant certains paquets dépendants de PHP sont concernés, et Synology Drive n'en fait pas partie. IDrive figure dans la liste, mais il s'agit d'un logiciel tiers.

• Accessible via le Web et prioritaire. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer et phpMyAdmin. Ces outils permettent de diffuser du code PHP à quiconque peut y accéder.
• Courrier et calendrier. Mail Station nécessite une mise à jour manuelle après l'installation du paquet PHP. Le calendrier Synology dispose de sa propre version fixe (3.0.4-21435).
• Le composant interne du DSM. Présent mais non accessible de l'extérieur, correctif reporté à une version ultérieure du DSM, risque jugé minimal par Synology.
• Les conteneurs ne sont pas couverts. L'environnement d'exécution PHP intégré à Container Manager est modifiable par vos soins. Aucune mise à jour de paquet ne le modifiera, ce qui explique pourquoi un utilisateur de NAS pense avoir terminé alors que ce n'est pas le cas.

Si vous utilisez une version de DSM antérieure à la version 7.2, Synology recommande de désactiver temporairement les paquets concernés jusqu'à la disponibilité d'une version corrigée. DSM 7.2 est lui-même indiqué comme obsolète dans la déclaration, bien qu'il ait bénéficié de ces mises à jour PHP.

Le cas critique de PHP2Shell concerne PHP 7.3 et les versions antérieures. La branche Synology ne prendra pas en charge la version 7.3 car elle n'est plus maintenue et aucune mise à jour n'a été publiée pour les versions 7.3 et antérieures. Certaines distributions Linux proposent des rétroportages pour d'anciennes versions, mais un paquet PHP Synology n'est pas un paquet de distribution. Si un site nécessite PHP 7.3 ou 5.6 pour fonctionner, aucun correctif ne sera disponible et les seules solutions sont de migrer le site vers une branche prise en charge, de le protéger par un pare-feu applicatif web (WAF) ou de le retirer d'Internet.

Comment les propriétaires de sites de conteneurs gèrent PHP2Shell

Cinq de nos six sites utilisent WordPress dans Docker plutôt que dans Web Station, et c'est là que PHP2Shell devient intéressant, car le Centre de paquets ne peut pas vous aider. L'environnement d'exécution dépend du contenu de l'image, et reconstruire une image n'est pas la même chose que la mettre à jour.

Le premier problème rencontré avec PHP2Shell, et celui qui risque le plus d'affecter d'autres utilisateurs, est que la reconstruction d'une image personnalisée réutilise la couche de base mise en cache. Une image non épinglée DEPUIS L'étiquette « à jour » ne signifie pas « fraîche ». L'une de nos images avait été reconstruite quatre jours auparavant et contenait encore une version PHP datant de juillet 2025, avec plus d'un an de correctifs de sécurité en retard, car rien n'avait forcé Docker à récupérer à nouveau la base.

# Incorrect : réutilise silencieusement la couche de base mise en cache localement : `docker build -t mysite .` # Correct : toujours republier l’image de base : `docker build --pull -t mysite .` # Ensuite, démarrez uniquement le service souhaité, sans lancer les services inactifs : `docker compose up -d --no-deps wordpress` # Et vérifiez ce qui compte vraiment : `docker exec wordpress php -v`

La seconde erreur de PHP2Shell est plus grave car elle signale une réussite. Le transfert de la sortie de compilation via queue masque un échec de compilation, car le code de sortie d'un pipeline appartient à la dernière commande qui le compose et définir -e ne se déclenche jamais. L'étape de composition recrée ensuite le conteneur à partir de l'ancienne image, affiche « Démarré », et vous vous retrouvez avec un site non patché qui semble fraîchement déployé. Vérifiez le résultat de la compilation et confirmez avec php -v après.

Deux petites remarques. Étiquetez l'ancienne image avant de la reconstruire, car une image conserve son étiquette et vous offre un point de restauration gratuit, bien moins coûteux qu'un instantané. De plus, ne vous attendez pas à ce qu'une mise à jour de l'image mette à niveau l'application : le point d'entrée officiel des images WordPress ne copie les fichiers principaux que lorsque le répertoire racine est vide. Par conséquent, recréer un conteneur sur une image plus récente laisse l'installation existante exactement au même endroit. Nous l'avons vérifié sur un environnement de test avant de passer en production, et la version de WordPress n'a pas bougé.

Pourquoi la désactivation de session.upload_progress ne résout-elle que la moitié du problème ?

La solution de contournement PHP2Shell qui circule pour les machines ne pouvant être patchées consiste à configurer session.upload_progress.enabled = 0, et sur DSM, accessible via Web Station dans les paramètres du langage de script, onglet « Core » du profil PHP. Cela vaut la peine d'être fait. Ce n'est pas une solution définitive, et l'écart est important.

Le suivi de la progression du chargement des sessions n'est qu'une des voies d'accès. La vulnérabilité de divulgation de mémoire est exploitée via la gestion classique des requêtes multipart et ne nécessite aucunement l'activation des sessions ; désactiver cette fonctionnalité laisse donc cette voie ouverte. Le projet PHP a clairement indiqué qu'il n'existe aucune solution de contournement complète et que la mise à jour est la seule solution sûre. Imunify360 signale qu'aucune règle ne bloque actuellement l'exploitation de la vulnérabilité CVE-2026-109618 liée à une insuffisance de mémoire, et Elastic note que le paramètre de suivi de la progression du chargement ferme les voies de session confirmées, mais pas toutes les variantes.

Vous verrez également limite_mémoire = -1 Cette solution est proposée, partant du principe que le bug survient suite à une saturation de la mémoire. Il faut la considérer comme un compromis, et non comme un avantage. Supprimer la limite sur un serveur web public ne fait que remplacer un mode de défaillance par un autre, et sur un NAS avec une mémoire partagée, cela risque d'entraîner la saturation de la machine par le pool de processus.

Le filtrage Edge est la couche PHP2Shell qui apporte une réelle valeur ajoutée, car elle intercepte le trafic déchiffré, contrairement à votre routeur. Cloudflare a déployé une protection par règles gérées pour PHP2Shell, AWS a intégré la protection contre la vulnérabilité CVE-2026-109619 dans la version 2.3 de son groupe de règles gérées PHP, et Azure Front Door a déployé la règle 99006001, désactivée par défaut. Des règles communautaires Snort et Suricata sont disponibles sur GitHub, mais les ensembles de règles officiels Snort et Emerging Threats n'étaient pas encore publiés au moment de la rédaction de ce document. Par conséquent, une fonctionnalité de prévention des intrusions NAS ne vous sera d'aucune utilité dans ce cas précis. De toute façon, elle ne peut pas lire le trafic TLS.

Quel fournisseur de NAS a réellement déployé un correctif ?

Voici la partie de l'histoire de PHP2Shell qui devrait influencer votre choix. La version officielle de PHP a été publiée le 21 octobre. Voici la position des quatre principaux fournisseurs de NAS grand public et semi-professionnels le lendemain, d'après leurs propres pages d'information et non des articles de presse.

Fournisseur	Consultatif	Statut	Versions corrigées publiées
Synologie	Synology-SA-26:14, 22 oct. 2026	Résolu	Oui. Chaque branche coûte entre 7,4 et 8,4 PHP, plus le calendrier et le service de messagerie.
QNAP	QSA-26-18, 22 oct. 2026	Fixation	Non. Chaque ligne porte la mention « À annoncer ».
ASUSTOR	Retrait des versions précédentes de PHP, le 22 octobre 2026	La retraite, pas un patch	Les versions PHP 7, 7.3, 7.4 et 8.1 n'ont pas été retirées d'App Central.
UGREEN	Aucun résultat trouvé	Inconnu	Aucun avis n'a été trouvé pour UGOS Pro.

Le même jour que l'avis de sécurité, Synology a publié un tableau complet des versions de PHP2Shell et l'a marqué comme résolu. Un administrateur DSM, après avoir consulté cet avis, a pu agir immédiatement : ouvrir le Centre de paquets, cliquer sur « Mettre à jour » et vérifier. C'est la procédure de correction complète, et c'est pourquoi nos machines Web Station ont été mises à jour en quelques minutes au lieu de plusieurs jours.

QNAP a publié le même jour une liste de produits concernés, incluant QTS 6.1.0, QTS 5.2.11 et versions antérieures, QuTS hero h6.1.0, h6.0.x et h5.2.11 et versions antérieures, QuTScloud c5.2.9 et versions antérieures, Note Station 3, QNE ADRA, QVR Surveillance sur les modèles ARM32 et TVR OS. Le statut de correction est indiqué pour chacun de ces produits, sans version corrigée. Le runtime PHP étant intégré aux composants web de QTS, aucun paquet n'est disponible pour une mise à jour ; la correction doit donc être apportée par une mise à jour du firmware.

En attendant, QNAP propose aux victimes de PHP2Shell une liste de mesures d'atténuation. Il est important de la lire attentivement, car elle recommande de désactiver la redirection de ports et l'UPnP sur votre routeur, de dépublier les services myQNAPcloud, de passer l'accès distant par un VPN, de limiter les ports d'administration aux sous-réseaux de confiance, d'arrêter les applications PHP inutiles, de désactiver le serveur web intégré s'il n'est pas utilisé et de consulter régulièrement QuLog Center afin de détecter toute compromission. Ces conseils sont judicieux pour un système non patché. Pour toute personne hébergeant un site web public, il est impératif de le mettre hors ligne.

ASUSTOR a opté pour une troisième solution. Son avis, daté du 22 octobre et intitulé « Annonce de retrait des anciennes versions de PHP », retire immédiatement PHP 7, PHP 7.3, PHP 7.4 et PHP 8.1 d'App Central, recommande la sauvegarde des données importantes et invite les utilisateurs à n'utiliser que PHP 8.3 ou 8.4 à partir de maintenant. Cette décision se justifie, car les développeurs ne corrigent que les versions 8.2 et ultérieures. Pour un utilisateur exécutant une ancienne application PHP, l'environnement d'exécution disparaît de l'App Store au lieu d'être corrigé, et ASUSTOR n'indique pas avoir publié de version corrigée de PHP 8.3 ou 8.4. À noter la différence avec Synology, qui a publié une version corrigée de PHP 7.4 (7.4.33-0131) destinée précisément aux utilisateurs qu'ASUSTOR invite à migrer.

Concernant UGREEN, nous n'avons trouvé aucune information relative à PHP2Shell pour UGOS Pro. L'absence de déclaration publique ne prouve pas qu'un produit est vulnérable, et UGOS Pro peut tout simplement ne pas inclure d'environnement d'exécution PHP accessible via le web. Cependant, si vous êtes le propriétaire du produit, le silence n'est pas une réponse exploitable et constitue en soi une forme de vulnérabilité.

Rien de tout cela ne rend Synology parfait. Il ne corrige pas PHP 7.3, il signale la fin de vie de DSM 7.2 et son propre composant PHP interne est toujours en attente de correctifs plutôt que d'être mis à jour. L'enjeu est plus précis et plus utile qu'une simple question de marque : le jour où une faille d'exécution de code à distance avant authentification a été découverte dans le moteur PHP, un fournisseur a rendu la correction accessible via un simple bouton dans le Centre de paquets, tandis que les autres ont opté pour une stratégie d'attente.

Où trouver plus de ressources officielles

PHP2Shell n'existe que depuis deux jours au moment de la rédaction de ce document et la situation évolue encore ; privilégiez donc les sources primaires aux résumés. Aucun fournisseur n'a encore publié de vidéo officielle, la liste ci-dessous constitue donc une documentation et non des tutoriels.

• Synology-SA-26:14 Il s'agit du tableau de versions faisant foi. Consultez-le à nouveau avant d'appliquer un correctif, car les avis de version sont régulièrement mis à jour.
• Déclaration PSIRT Synology Cette liste répertorie les paquets concernés et explique le composant interne de DSM ainsi que l'exception relative à Mail Station.
• Les avis GitHub en amont GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp sont liés à l'avis Synology et décrivent le comportement du moteur plutôt que l'emballage du fournisseur.
• QNAP QSA-26-18 C'est ici qu'apparaîtra la version corrigée du firmware si vous utilisez QTS ou QuTS Hero. Il s'agit de la page à consulter, et non d'un article d'actualité.
• Votre Centre de colis est la source ultime d'informations sur ce qui est installé. L'avis vous indique la configuration cible, la vignette vous indique ce que vous possédez réellement, et seulement php -v vous indique ce qui est en cours d'exécution.

Pour en savoir plus sur l'exploitation de sites web publics sur des machines virtuelles Synology, consultez notre guide sur Déplacement d'une pile Docker entre invités VDSM décrit les habitudes de capture d'instantanés et de restauration qui ont permis de surmonter cette situation d'urgence.

Limites et notes de sécurité de PHP2Shell

L'application de correctifs à PHP2Shell est simple sur DSM et trompeuse partout ailleurs ; il convient donc d'énoncer clairement quelques limites avant de déclarer le travail terminé.

La mise à jour du paquet PHP2Shell ne constitue pas un audit de site. La mise à jour de PHP corrige la faille à partir de ce moment, mais si le serveur était accessible depuis Internet entre le 20 et le 22 octobre, il l'était alors qu'une faille de sécurité fonctionnelle était publique. Vérifiez les journaux pour détecter un volume anormal de requêtes POST, recherchez les fichiers apparus dans les répertoires accessibles en écriture et changez les identifiants qu'un processus PHP aurait pu détenir. Dans le cas d'une divulgation de la mémoire, le changement d'identifiants est une précaution raisonnable plutôt qu'une excès de zèle.

La vérification PHP2Shell doit cibler l'interpréteur en cours d'exécution. Les tableaux de bord, les journaux de compilation et les en-têtes de réponse nous ont tous fait défaut au moins une fois lors de cette itération. Un CDN peut supprimer l'en-tête indiquant la version, une compilation peut signaler une réussite tout en réutilisant une couche en cache, et la vignette d'un paquet peut afficher la version actuelle alors qu'un ancien processus est toujours en service. php -v L'élément qui traite les demandes les règle à l'intérieur.

Les conteneurs ne sont couverts par aucun avis de sécurité PHP2Shell des fournisseurs. Il est important de le rappeler, car cela engendre un faux sentiment de sécurité très répandu sur un NAS. Si votre site est exécuté dans Container Manager, le fait que Package Center indique que tout est à jour ne vous renseigne en rien sur son état. Il en va de même pour toute application tierce intégrant son propre environnement d'exécution.

Les mesures d'atténuation de la configuration sont par nature partielles. Désactiver l'affichage de la progression du chargement des sessions est utile, supprimer la limite de mémoire ne fait que déplacer un risque vers un autre, et la fonction de prévention des intrusions d'un routeur ne peut pas inspecter le trafic TLS qui aboutit ailleurs. Considérez tout cela comme un gain de temps en attendant un correctif définitif, et non comme un substitut.

Les environnements d'exécution en fin de vie ne sont plus compatibles avec PHP2Shell. PHP 7.3 et les versions antérieures n'ont reçu aucune mise à jour des développeurs amont ni de Synology. Si un site nécessite réellement une branche non prise en charge, vous devez choisir entre la migration, l'isolation ou le retrait d'Internet. Il n'existe pas d'autre option, et prétendre le contraire revient à rendre un site obsolète vulnérable à la contamination de l'ensemble du système.

Enfin, privilégiez la consultation de l'avis plutôt que le suivi de l'actualité. Synology a marqué l'avis SA-26:14 comme résolu et l'a modifié une fois dans les six minutes suivant sa publication. QNAP a indiqué que l'avis QSA-26:18 sera mis à jour dès que des versions corrigées seront disponibles. Ces deux pages seront modifiées, et les numéros de version mentionnés dans cet article correspondent à ceux publiés le 22 octobre 2026.

Références

• Synology-SA-26:14 Avis de sécurité PHP2Shell, publié le 22 octobre 2026, statut Résolu, avec des versions corrigées pour PHP 7.4 à 8.4.
• Déclaration Synology concernant les vulnérabilités de PHP2Shell, la note PSIRT répertoriant les paquets concernés et la couverture DSM.
• QNAP QSA-26-18, Statut : Correction en cours. Les produits concernés sont listés avec les versions corrigées. À annoncer.
• Annonce de retrait d'ASUSTOR Legacy PHP, suppression de PHP 7, 7.3, 7.4 et 8.1 d'App Central.
• Aide Net Security concernant les versions amont de PHP2Shell, couvrant PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 et les rétroportages du code source uniquement pour les branches plus anciennes.

Questions fréquemment posées