Un NAS accessible à distance, un port de conteneur publié ou une passerelle ouverte autrefois à titre provisoire : ces services passent facilement inaperçus. Face à PHP2Shell, trois questions comptent : qu’est-ce qui est accessible, quel environnement PHP traite les requêtes web et quelles autres ressources ce service peut-il atteindre ?
Les deux premiers articles de cette série présentent la situation de sécurité PHP et notre réaction, puis l’utilisation de l’IA pour faciliter l’inventaire. Ce volet porte sur les vérifications pratiques, pour les entreprises comme pour les particuliers exploitant un NAS. Une marque ne remplace pas un inventaire. Un micrologiciel à jour ne prouve pas davantage que tous les paquets et conteneurs en cours d’exécution ont été actualisés.
PHP2Shell concerne le moteur PHP réellement utilisé pour le web
CVE-2026-109618 et CVE-2026-109619 peuvent permettre l’exécution de code avant toute authentification dans l’application ; chacune est évaluée à 9,2 selon CVSS v4.0. Le projet PHP a publié les versions corrigées 8.2.35, 8.3.36, 8.4.27 et 8.5.12 le 21 octobre 2026. Les fournisseurs peuvent aussi proposer leurs propres paquets intégrant des correctifs rétroportés. L’avis applicable est donc plus pertinent qu’un simple numéro de version.
Une page de connexion ne garantit pas la protection dans ce cas. Il faut vérifier l’interpréteur qui traite effectivement les requêtes web, y compris les processus actifs. Une version récente de PHP en ligne de commande ne suffit pas à le démontrer. Cela vaut pour les serveurs web classiques comme pour les environnements intégrés aux applications, appliances et images.
L’exposition publique ne se limite pas aux redirections de ports
L’inventaire doit inclure IPv4 et IPv6, les règles du routeur, UPnP, les noms DDNS, les destinations du reverse proxy, les tunnels et les accès distants relayés par le cloud. Il faut préciser le chemin d’accès réel dans chaque cas : une adresse IP publique n’est pas, à elle seule, une application vulnérable. Un relais du fabricant n’est pas non plus automatiquement exposé au même vecteur d’attaque. À l’inverse, une règle oubliée peut rendre accessible un service censé rester interne.
Recensez les sites, CMS, portails clients, panneaux d’hébergement et interfaces de sauvegarde, de supervision et d’administration. Incluez aussi les NAS, systèmes VoIP, caméras, imprimantes et passerelles de commande. Un équipement sans composant PHP pertinent n’est pas automatiquement concerné par ces deux CVE. Son accessibilité depuis Internet mérite néanmoins d’être examinée.
Synology : examiner séparément le système et les paquets
Synology limite les conséquences à certains paquets dépendant de PHP, dont Web Station, WordPress, Calendar et MailStation. Son communiqué du 22 octobre annonce des mises à jour PHP pour DSM 7.4, 7.3 et, explicitement, DSM 7.2, bien que cette version de DSM ait atteint sa fin de vie. Pour les versions antérieures, le fabricant recommande de désactiver temporairement les paquets concernés.
PHP se met à jour dans le Centre de paquets ; MailStation nécessite également une mise à jour manuelle de son paquet. L’avis n’annonce aucun correctif pour le paquet Synology PHP 7.3. Selon le fabricant, le PHP utilisé en interne par DSM présente une exposition différente et ne comporte pas de module accessible de l’extérieur. Attention aussi aux noms : le paquet tiers IDrive n’est pas Synology Drive, que le communiqué indique comme non affecté.
Pour les installations non officielles de DSM utilisant XPEnology, il faut évaluer individuellement l’équipement, le chargeur, DSM et les paquets. Cet ensemble ne correspond pas à un système Synology normalement pris en charge. Cela ne signifie ni que les mises à jour sont toujours impossibles ni que toutes ces installations sont vulnérables. Une maintenance incertaine justifie toutefois de limiter l’accès direct depuis Internet et de prévoir une exploitation durablement maintenable.
QNAP : vérifier le statut actualisé depuis l’annonce initiale
Depuis sa révision du 24 octobre, l’avis QNAP QSA-26-18 mentionne des correctifs pour plusieurs branches QTS, QuTS hero et QuTScloud. D’autres applications répertoriées restent au statut « Fixing ». Ni « QNAP n’a encore aucun correctif » ni « tout est résolu » ne décrit correctement la situation. Le produit précis, sa branche de version et la version corrigée correspondante sont déterminants. Une mise à jour du système QNAP ne corrige pas automatiquement PHP dans les applications tierces ou les conteneurs personnalisés.
Les conteneurs posent deux questions distinctes
Première question : le moteur PHP du conteneur actif est-il corrigé ? Actualiser l’hôte ne remplace pas une ancienne image. L’image de base, les paquets supplémentaires et le déploiement réellement actif doivent correspondre. Disposer localement d’une nouvelle image n’est utile qu’une fois le service redéployé avec la version corrigée et ses fonctions vérifiées.
Deuxième question : quels droits et chemins réseau possède le service ? Les réseaux bridge Docker permettent généralement les connexions sortantes, et les conteneurs d’un même réseau bridge peuvent communiquer entre eux. L’accès aux destinations internes dépend notamment du routage et des règles de pare-feu. Un conteneur compromis ne donne donc pas automatiquement le contrôle de tout le réseau local. Des identifiants partagés, des montages hôte inutiles, des privilèges supplémentaires ou l’accès au socket Docker peuvent néanmoins aggraver fortement les conséquences. Des réseaux séparés, des règles de sortie ciblées et des droits minimaux doivent être vérifiés concrètement.
Sept vérifications pour la prochaine session de travail
- Recenser les accès : documenter les équipements, applications, ports publiés et services intermédiaires, avec leurs responsables. Inclure IPv6 et les règles temporaires oubliées.
- Identifier les environnements : relever le système, les paquets, les plugins et le PHP web de chaque service. Vérifier les avis du fournisseur et le statut de maintenance.
- Corriger et vérifier : installer les mises à jour ou images appropriées, redémarrer correctement les services concernés et contrôler la version réellement active.
- Réduire l’exposition : fermer les accès publics d’administration inutiles. Un VPN ou un réseau d’administration de confiance peut limiter l’accès ; les mises à jour restent nécessaires derrière cette protection.
- Tester les chemins et les droits : limiter les accès aux bases de données, NAS, sauvegardes et interfaces de gestion aux besoins réels. Modifier les règles avec précaution, puis vérifier les applications légitimes.
- Examiner les traces et la restauration : évaluer les accès, comptes et connexions sortantes inhabituels. Prévoir des sauvegardes indépendantes protégées contre les modifications non autorisées et tester la restauration ; les seuls snapshots ne les remplacent pas.
- Suivre les exceptions : documenter les systèmes sans correctif disponible, avec un responsable, une mesure provisoire et un plan de remplacement ou d’arrêt.
Un correctif ne clôt pas automatiquement l’analyse d’un incident
Sophos rapporte une tentative d’exploitation observée par Amazon Threat Intelligence dès le 17 octobre, avant la divulgation publique. Pour les systèmes réellement exposés, l’évaluation doit donc aussi porter sur l’activité antérieure. Une mise à jour réussie ne prouve pas l’absence d’accès non autorisé auparavant. En présence d’indices de compromission, il faut une réponse à incident organisée, préservant les éléments utiles et permettant une remise en service contrôlée.
Depuis le 23 octobre, PHP signale également un autre cas rare, dépendant de la configuration, lié au suivi de progression des téléversements de session. Les indications actuelles des fournisseurs restent donc pertinentes après la première mise à jour. Modifier globalement une configuration sans connaître ses effets sur l’exploitation est un mauvais raccourci.
Ce qui n’a pas besoin d’être public devrait rester inaccessible depuis Internet jusqu’à sa vérification. Cela réduit la surface d’attaque sans remplacer le correctif. DAXS aide à identifier les services, à hiérarchiser les mesures et à vérifier leur efficacité de manière traçable. Parlons de votre environnement.
Sources : PHP : avis de sécurité et versions corrigées · ENISA : identifier les applications PHP et limiter l’exposition · Synology : paquets concernés et versions de DSM · Synology-SA-26:14 · QNAP QSA-26-18 : correctifs par produit · Docker : fonctionnement des réseaux bridge · Sophos : exposition, activité et analyse d’incident · NCSC-NL : vue d’ensemble des dépendances PHP · Red Hat : environnements, rétroportages et recommandations complémentaires.
