{"id":22083,"date":"2026-10-23T05:56:32","date_gmt":"2026-10-22T21:56:32","guid":{"rendered":"https:\/\/synopower.club\/?p=22083"},"modified":"2026-10-23T05:56:32","modified_gmt":"2026-10-22T21:56:32","slug":"synology-php2shell-emergency-patch","status":"publish","type":"post","link":"https:\/\/synopower.club\/fr\/synology-php2shell-emergency-patch\/","title":{"rendered":"PHP2Shell sur Synology\u00a0: Comment nous avons corrig\u00e9 six sites en une journ\u00e9e"},"content":{"rendered":"

PHP2Shell<\/strong> CVE-2026-109618 et CVE-2026-109619, deux failles critiques du moteur PHP permettant l'ex\u00e9cution de code \u00e0 distance sans authentification, ont \u00e9t\u00e9 d\u00e9sign\u00e9es par l'industrie. Les d\u00e9tails ont fuit\u00e9 le 20 octobre 2026, la veille de la divulgation coordonn\u00e9e, et le projet PHP a publi\u00e9 des correctifs d'urgence le 21 octobre. Le bogue se situant dans l'interpr\u00e9teur et non dans une application, l'application de correctifs \u00e0 WordPress, Joomla ou MediaWiki est inefficace. Seule une nouvelle version de PHP peut r\u00e9soudre le probl\u00e8me. Nous h\u00e9bergeons six sites WordPress publics sur du mat\u00e9riel Synology, et l'introduction de PHP2Shell a n\u00e9cessit\u00e9 la reconstruction de chacun d'eux la m\u00eame semaine. Ce guide explique la nature du bogue, comment le corriger sur DSM via le Centre de paquets, comment le g\u00e9rer lorsqu'un site s'ex\u00e9cute dans un conteneur, et \u00e9tablit une comparaison pertinente entre les solutions propos\u00e9es par le Synology et celles mises en \u0153uvre par les autres fournisseurs de NAS.<\/p>\n\n\n\n

\n

Point SynoPower Club :<\/strong>Nos six sites ont \u00e9t\u00e9 corrig\u00e9s en moins d'une journ\u00e9e ouvrable apr\u00e8s la publication de l'avis de s\u00e9curit\u00e9 concernant PHP2Shell. Ce qui a rendu cela possible, ce n'est pas un exploit, mais la publication par Synology de correctifs le jour m\u00eame de l'avis. Le correctif Synology-SA-26:14 a \u00e9t\u00e9 publi\u00e9 le 22 octobre avec le statut \u00ab\u00a0R\u00e9solu\u00a0\u00bb et un tableau complet des versions corrig\u00e9es jusqu'\u00e0 PHP 7.4. Le m\u00eame jour, QNAP publiait QSA-26-18 avec le statut \u00ab\u00a0En cours de correction\u00a0\u00bb et la mention \u00ab\u00a0\u00c0 annoncer\u00a0\u00bb dans chaque cellule de version corrig\u00e9e. ASUSTOR a r\u00e9agi en supprimant les anciennes versions de PHP d'App Central au lieu de les corriger. Si vous h\u00e9bergez vous-m\u00eame un site web public sur un NAS, ce d\u00e9lai n'est pas un argument marketing. Il fait toute la diff\u00e9rence entre mettre \u00e0 jour un paquet et rendre votre site inaccessible pendant l'attente.<\/p>\n<\/blockquote>\n\n\n\n

Qu'est-ce que PHP2Shell et pourquoi est-il diff\u00e9rent ?<\/h2>\n\n\n\n

PHP2Shell n'est pas un simple bug, mais un ensemble de d\u00e9faillances li\u00e9es \u00e0 la gestion de la m\u00e9moire par PHP apr\u00e8s une requ\u00eate ayant entra\u00een\u00e9 une insuffisance de m\u00e9moire. PHP utilise longjmp()<\/code> Pour \u00e9viter les erreurs fatales, y compris les erreurs de m\u00e9moire insuffisante, ce saut ignore le code de nettoyage qui permettrait normalement au moteur de retrouver un \u00e9tat connu. Une partie de cet \u00e9tat est globale et persiste lors de la prochaine requ\u00eate trait\u00e9e par le m\u00eame processus.<\/p>\n\n\n\n

La vuln\u00e9rabilit\u00e9 CVE-2026-109618 est li\u00e9e \u00e0 une insuffisance de m\u00e9moire. Une requ\u00eate HTTP malveillante \u00e9puise la m\u00e9moire alors que les donn\u00e9es ne sont que partiellement initialis\u00e9es, ce qui a pour cons\u00e9quence que la routine de nettoyage parcourt des structures inachev\u00e9es. La vuln\u00e9rabilit\u00e9 CVE-2026-109619 est li\u00e9e \u00e0 une utilisation de m\u00e9moire lib\u00e9r\u00e9e\u00a0: un \u00e9tat global pointant vers la m\u00e9moire lib\u00e9r\u00e9e lors d'une requ\u00eate peut \u00eatre lu par une requ\u00eate ult\u00e9rieure sur le m\u00eame n\u0153ud de calcul, ce qui permet l'ex\u00e9cution de code ou la divulgation de donn\u00e9es en m\u00e9moire.<\/p>\n\n\n\n

Deux caract\u00e9ristiques rendent PHP2Shell plus dangereux que les alertes PHP habituelles. Premi\u00e8rement, il s'agit d'une vuln\u00e9rabilit\u00e9 de pr\u00e9-authentification. Les deux failles se d\u00e9clenchent avant toute authentification au niveau de l'application\u00a0; par cons\u00e9quent, un syst\u00e8me de connexion, un plugin d'adh\u00e9sion ou un mot de passe administrateur ne prot\u00e8gent en rien. Deuxi\u00e8mement, la variante de divulgation de m\u00e9moire expose la m\u00e9moire du processus worker, et un worker PHP sur un site WordPress peut contenir des identifiants de base de donn\u00e9es, des jetons d'API et des cl\u00e9s de paiement. Une simple lecture de m\u00e9moire n'a pas besoin d'atteindre l'ex\u00e9cution de code pour compromettre votre s\u00e9curit\u00e9.<\/p>\n\n\n\n

Les deux vuln\u00e9rabilit\u00e9s PHP2Shell ont obtenu un score CVSS v4.0 de 9,2 selon l'\u00e9quipe de s\u00e9curit\u00e9 PHP. Synology leur a attribu\u00e9 un score de 9,8 sur CVSS v3.1 dans son propre avis de s\u00e9curit\u00e9. Des \u00e9chelles diff\u00e9rentes pour une m\u00eame conclusion. Les rapports d'exploitation sont contradictoires\u00a0: watchTowr indique avoir constat\u00e9 des tentatives d'exploitation de son r\u00e9seau de honeypots, tandis que Bitdefender n'a rien signal\u00e9 dans ses donn\u00e9es t\u00e9l\u00e9m\u00e9triques au moment de la r\u00e9daction, et QNAP affirme n'avoir re\u00e7u aucun signalement d'exploitation ciblant sp\u00e9cifiquement ses produits.<\/p>\n\n\n\n

\"Synology-SA-26:14
Synology-SA-26:14, publi\u00e9 le 22 octobre 2026 \u00e0 19:45 UTC+8 avec le statut R\u00e9solu.<\/figcaption><\/figure>\n\n\n\n

PHP2Shell contre une faille de s\u00e9curit\u00e9 WordPress classique<\/h2>\n\n\n\n

La plupart des probl\u00e8mes rencontr\u00e9s sur un site WordPress public proviennent de failles de s\u00e9curit\u00e9 li\u00e9es \u00e0 des plugins. Le sch\u00e9ma est classique\u00a0: un plugin introduit un point d'acc\u00e8s REST d\u00e9fectueux, un outil d'analyse le d\u00e9tecte, vous mettez \u00e0 jour le plugin et la faille est corrig\u00e9e. PHP2Shell rompt radicalement avec cette habitude, et l'audit syst\u00e9matique des plugins s'av\u00e8re ici un effort vain.<\/p>\n\n\n\n

Aspect<\/th>CVE typique des plugins<\/th>PHP2Shell<\/th><\/tr><\/thead>
L\u00e0 o\u00f9 vit l'insecte<\/td>Code de l'application (plugin ou th\u00e8me)<\/td>L'interpr\u00e9teur PHP lui-m\u00eame<\/td><\/tr>
Qui peut le d\u00e9clencher ?<\/td>N\u00e9cessite souvent un r\u00f4le d'abonn\u00e9 ou d'administrateur.<\/td>Personne. Pr\u00e9-authentification, avant l'ex\u00e9cution de la logique de l'application.<\/td><\/tr>
La mise \u00e0 jour de WordPress est-elle utile\u00a0?<\/td>G\u00e9n\u00e9ralement oui<\/td>Non. Les mises \u00e0 jour du noyau et des plugins sont sans importance.<\/td><\/tr>
Est-ce qu'un pare-feu applicatif f\u00e9minin (WAF) l'emp\u00eache ?<\/td>G\u00e9n\u00e9ralement, une fois qu'une r\u00e8gle existe<\/td>En partie. Les r\u00e8gles de forme de requ\u00eate ne g\u00e8rent pas le chemin OOM.<\/td><\/tr>
Qu'est-ce qui le r\u00e9sout r\u00e9ellement ?<\/td>Mise \u00e0 jour du plugin<\/td>Une nouvelle version de PHP, rien d'autre<\/td><\/tr>
Rayon d'explosion<\/td>Un site, une fonctionnalit\u00e9<\/td>Tous les sites PHP h\u00e9berg\u00e9s sur le serveur, simultan\u00e9ment.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

C\u2019est cette derni\u00e8re ligne qui explique pourquoi PHP2Shell a n\u00e9cessit\u00e9 une journ\u00e9e enti\u00e8re de travail au lieu d\u2019un apr\u00e8s-midi. Un simple paquet PHP partag\u00e9 sur un NAS peut \u00eatre h\u00e9berg\u00e9 par une douzaine de machines virtuelles Web Station, et une seule image de conteneur peut servir de base \u00e0 plusieurs sites. Les correctifs ne sont pas appliqu\u00e9s par site, mais par environnement d\u2019ex\u00e9cution\u00a0; il faut donc recenser tous les environnements d\u2019ex\u00e9cution avant de pouvoir consid\u00e9rer que le travail est termin\u00e9.<\/p>\n\n\n\n

Comment savoir si votre NAS est expos\u00e9<\/h2>\n\n\n\n

L'\u00e9valuation de votre exposition \u00e0 PHP2Shell commence par la distinction de deux questions distinctes\u00a0: le syst\u00e8me contient-il une version de PHP vuln\u00e9rable et cette version est-elle accessible depuis Internet\u00a0? Synology \u00e9tablit explicitement cette distinction\u00a0: DSM int\u00e8gre un composant PHP interne utilis\u00e9 par le syst\u00e8me d'exploitation, et Synology pr\u00e9cise qu'il ne comporte aucun module accessible de l'ext\u00e9rieur et, par cons\u00e9quent, aucune surface d'attaque expos\u00e9e. Le risque associ\u00e9 \u00e0 ce composant est minime, et le correctif est pr\u00e9vu pour une version ult\u00e9rieure de DSM afin que les analyses de vuln\u00e9rabilit\u00e9 cessent de le signaler.<\/p>\n\n\n\n

Les packages pertinents pour PHP2Shell sont ceux qui permettent d'ex\u00e9cuter 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\u00e9 et accessible l'un de ces packages, vous \u00eates concern\u00e9.<\/p>\n\n\n\n

V\u00e9rifiez directement les versions plut\u00f4t que de vous fier \u00e0 un tableau de bord. Dans le Centre de paquets, les paquets PHP install\u00e9s affichent leur version sur la vignette, et la notification de mise \u00e0 jour indique la version cible. Depuis un terminal, interrogez directement l'environnement d'ex\u00e9cution\u00a0:<\/p>\n\n\n\n

# Synology Package PHP (adaptez le chemin \u00e0 la version que vous utilisez) \/volume1\/@appstore\/PHP8.2\/usr\/local\/bin\/php -v # Site conteneuris\u00e9 docker exec php -v<\/code><\/pre>\n\n\n\n
La raison d'insister sur php -v<\/code> Lors d'un audit PHP2Shell, il est crucial de v\u00e9rifier que tous les autres signaux sont trompeurs. La sortie de compilation peut indiquer une r\u00e9ussite tout en r\u00e9utilisant une couche en cache, un tableau de bord peut afficher un paquet comme \u00e9tant \u00e0 jour alors que le processus en cours d'ex\u00e9cution ne l'est pas, et un en-t\u00eate de r\u00e9ponse HTTP peut \u00eatre supprim\u00e9 par un CDN avant m\u00eame que vous ne le voyiez. Deux de nos six sites \u00e9taient signal\u00e9s comme op\u00e9rationnels par leurs interfaces d'administration alors qu'ils utilisaient encore un interpr\u00e9teur non patch\u00e9.<\/p>\n\n\n\n
Patch PHP2Shell sur Synology en 4 \u00e9tapes<\/h2>\n\n\n\n
Pour un site Web Station sous DSM, la correction compl\u00e8te du probl\u00e8me PHP2Shell consiste en une mise \u00e0 jour du Centre de paquets. Synology publie des correctifs de s\u00e9curit\u00e9 PHP pour DSM 7.4, 7.3 et 7.2. Apr\u00e8s la mise \u00e0 jour du paquet PHP, les paquets d\u00e9pendants red\u00e9marrent automatiquement, ce qui r\u00e9sout le probl\u00e8me. Mail Station constitue une exception document\u00e9e et n\u00e9cessite une mise \u00e0 jour manuelle.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Consultez l'avis<\/h3>\n
Ouvrez le fichier Synology-SA-26:14 et notez la version corrig\u00e9e pour chaque branche PHP install\u00e9e. Les versions cibles sont\u00a0: 7.4.33-0131, 8.0.30-0122, 8.1.34-0120, 8.2.35-0171, 8.3.36-0051 et 8.4.27-0051. PHP 7.3 n'est pas pris en charge car il n'est plus maintenu.<\/p>\n<\/div>\n<\/div>\n
\n
Mise \u00e0 jour via le centre de colis<\/h3>\n
Dans DSM, ouvrez le Centre de paquets et consultez la section \u00ab\u00a0Install\u00e9s\u00a0\u00bb. Chaque paquet PHP vuln\u00e9rable affiche une mise \u00e0 jour disponible avec la nouvelle version en ligne. Cliquez sur \u00ab\u00a0Mettre \u00e0 jour\u00a0\u00bb pour chaque branche PHP list\u00e9e et mettez \u00e0 jour Synology Calendar et Mail Station si vous les utilisez.<\/p>\n<\/div>\n<\/div>\n
\n
Laissez les personnes \u00e0 charge red\u00e9marrer<\/h3>\n
Les paquets d\u00e9pendant de PHP red\u00e9marrent automatiquement une fois la mise \u00e0 jour de PHP termin\u00e9e\u00a0; c\u2019est ce red\u00e9marrage qui permet d\u2019appliquer la correction. Mail Station fait exception et doit \u00eatre mis \u00e0 jour manuellement depuis le Centre de paquets.<\/p>\n<\/div>\n<\/div>\n
\n
V\u00e9rifiez l'interpr\u00e9teur en cours d'ex\u00e9cution.<\/h3>\n
Ne vous fiez pas au tableau de bord. Ex\u00e9cutez la commande `php -v` sur le chemin du paquet ou \u00e0 l'int\u00e9rieur du conteneur et v\u00e9rifiez que le num\u00e9ro de build correspond \u00e0 l'avis de s\u00e9curit\u00e9. Assurez-vous ensuite que chaque h\u00f4te virtuel Web Station est bien li\u00e9 \u00e0 un profil que vous avez mis \u00e0 jour.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Le
Le centre de paquets propose PHP 8.2.35-0171, la version mentionn\u00e9e dans l'avis.<\/figcaption><\/figure>\n\n\n\n
La capture d'\u00e9cran ci-dessus provient de l'une de nos machines, le lendemain matin de la publication de l'avis de s\u00e9curit\u00e9 concernant PHP2Shell. Notez que le panneau \u00ab\u00a0Nouveaut\u00e9s\u00a0\u00bb indique directement la version amont, ce qui permet de faire correspondre le suffixe de build Synology \u00e0 la version de PHP sans avoir \u00e0 deviner. Synology Calendar appara\u00eet dans la m\u00eame liste de mises \u00e0 jour \u00e0 la version 3.0.4-21435, qui correspond exactement \u00e0 la version recommand\u00e9e par l'avis de s\u00e9curit\u00e9.<\/p>\n\n\n\n
\"Bo\u00eete
La bo\u00eete de dialogue de mise \u00e0 jour nomm\u00e9e PHP 8.2.35-0171, publi\u00e9e par Synology Inc.<\/figcaption><\/figure>\n\n\n\n
Attention aux pi\u00e8ges de PHP2Shell pour les utilisateurs de Web Station\u00a0: une machine DSM peut avoir plusieurs branches PHP install\u00e9es simultan\u00e9ment, et chaque h\u00f4te virtuel est li\u00e9 \u00e0 un profil. La mise \u00e0 jour du profil par d\u00e9faut est sans effet sur un site associ\u00e9 \u00e0 une autre branche. Commencez par lister les profils, mettez-les tous \u00e0 jour, puis v\u00e9rifiez la liaison de chaque site sous Web Service.<\/p>\n\n\n\n
Quels sont les packages DSM concern\u00e9s\u00a0?<\/h2>\n\n\n\n
Le message d'erreur concernant Synology sur PHP2Shell est plus restrictif que ne le laissait entendre le message d'erreur. Seuls les syst\u00e8mes utilisant certains paquets d\u00e9pendants de PHP sont concern\u00e9s, et Synology Drive n'en fait pas partie. IDrive figure dans la liste, mais il s'agit d'un logiciel tiers.<\/p>\n\n\n\n