PHP : les correctifs sont disponibles, le moteur du serveur est à mettre à jour

Le risque se situe dans PHP lui-même

Le NCSC UK décrit deux défauts de gestion de la mémoire : CVE-2026-109618 peut interrompre le traitement alors que les données internes d’une requête ne sont pas entièrement initialisées ; CVE-2026-109619 peut laisser un état périmé utilisé par une requête suivante. Sous certaines conditions, ces corruptions permettent une exécution de code à distance sans authentification.

Cloudflare dit avoir observé du trafic d’attaque et déployé des protections. C’est un constat attribué à cet opérateur, pas la preuve que chaque serveur PHP a été compromis. Le NCSC demande aussi de rechercher PHP dans les logiciels et équipements qui l’embarquent, pas seulement dans les sites que vous administrez directement.

Le 22 octobre, le CERT-FR ajoute avoir connaissance de preuves de concept pour les deux CVE dans certains déploiements PHP. Une preuve de concept publique ne prouve pas à elle seule une compromission de votre serveur ; elle renforce l’intérêt de vérifier le correctif sans attendre.

Le CERT/CC précise qu’une preuve de concept vise particulièrement Apache mod_php : des requêtes sans authentification peuvent déclencher l’attaque avant l’exécution du code de l’application. Une protection dans le seul CMS ne suffit donc pas à traiter ce chemin.

Version amont et paquet de distribution : deux repères différents

Le CERT-FR liste les branches PHP suivantes comme affectées en dessous de ces versions corrigées. Ce tableau concerne les versions amont ; un paquet maintenu par une distribution peut porter un autre numéro.

Ubuntu ajoute USN-8948-2 pour 20.04 LTS et 18.04 LTS avec Ubuntu Pro, ainsi que 16.04 LTS et 14.04 LTS avec Ubuntu Pro et l’extension Legacy Support. Ces correctifs de distribution existent même si la branche PHP amont n’est plus maintenue. Debian annonce pour trixie le paquet php8.4 8.4.27-1~deb13u1 dans DSA-6574-1. Vérifiez le paquet et le niveau de support qui correspondent réellement à votre système.

QNAP : les correctifs du NAS sont encore en préparation

QNAP publie QSA-26-18 le 22 octobre pour les deux CVE PHP. Le bulletin classe les produits concernés en « Fixing » et leurs versions corrigées « To be announced ». La disponibilité de PHP corrigé ne signifie donc pas que le firmware de votre NAS l’intègre déjà.

Le tableau ci-dessous reprend les systèmes listés. Le bulletin nomme aussi plusieurs applications et équipements ; QVR Surveillance 3.0.3 et antérieures est notamment limité aux modèles ARM32 dans cette liste. Vérifiez le nom et la version de chaque composant directement dans l’avis.

Dans l’attente, QNAP demande de ne plus exposer directement l’appareil à Internet : retirer les redirections de ports et l’UPnP, limiter l’administration aux réseaux locaux ou VPN de confiance, et arrêter les services inutiles. Désactiver le serveur web ne protège pas l’interface d’administration. Un appareil local déjà compromis reste un risque.

QNAP précise que PHP dans les conteneurs Container Station ou les applications tierces ne relève pas de ses mises à jour. Contactez le fournisseur de l’image ou de l’application. L’éditeur dit n’avoir reçu aucun signalement d’exploitation ciblant ses produits ; cela ne garantit pas qu’aucun appareil n’a été touché. Nous n’avons pas testé ces atténuations.

Synology : des paquets corrigés, mais pas pour PHP 7.3

Synology-SA-26:14, publié le 22 octobre, nomme les deux CVE et fournit des mises à jour pour les paquets PHP ci-dessous, Mail Station et Synology Calendar. Ce ne sont pas les mêmes numéros que les versions PHP amont. PHP 7.3 est en fin de vie et ne recevra pas de correctif : ne restez pas dans l’attente d’un paquet annoncé comme inexistant.

L’éditeur distingue le PHP intégré au système, qu’il dit non exposé aux surfaces d’attaque externes et à risque d’exploitation très faible. Cette appréciation ne couvre pas tous les paquets installés sur le NAS. Vérifiez chaque application dans le Centre de paquets et le bulletin, plutôt que de considérer une seule mise à jour DSM comme la preuve que tout est corrigé.

Faire confirmer le moteur qui sert réellement le site

Identifiez qui maintient PHP : vous, l’hébergeur ou l’éditeur du produit qui l’intègre. Appliquez son correctif adapté, puis vérifiez la version du moteur utilisé par le service web. La version affichée dans un terminal peut ne pas être celle qui sert le site. Ne concluez pas qu’une mise à jour du CMS corrige à elle seule PHP.

Pour un hébergement géré, transmettez les deux CVE au prestataire et demandez confirmation des correctifs appliqués. Si vous administrez le service, prévoyez une sauvegarde utilisable et contrôlez son fonctionnement après l’intervention. SecuFocus n’a pas testé ces paquets ni reproduit les attaques.

Cisco a ouvert une enquête sur les produits et services de sa gamme. La liste « Products Under Investigation » ne signifie pas que tous ces produits sont vulnérables, ni déjà corrigés. Si PHP est intégré à un équipement, attendez la confirmation et la procédure de son éditeur plutôt que de remplacer vous-même son moteur.

La révision 1.4 du bulletin Cisco, datée du 22 octobre à 23:00 GMT, confirme désormais Ultra-Reliable Wireless Backhaul (URWB), Expressway et Expressway Select comme affectés. Pour URWB, Cisco exige un attaquant déjà authentifié comme administrateur et annonce 27.1.1 pour février 2027, date estimée. Pour les deux gammes Expressway, la cible 15.5.21 reste sans date. Ces numéros annoncés ne prouvent pas qu’un correctif est déjà disponible.

Umbrella et ISE figurent parmi les produits confirmés non vulnérables, mais ISE Portal Builder reste sous enquête. Ne confondez pas ces deux dernières lignes. D’autres produits et services restent en cours d’examen ; Cisco dit ne disposer d’aucun contournement traitant ces vulnérabilités.

Le NCSC précise désormais de traiter d’abord les systèmes exposés à Internet, puis les systèmes internes. Le périmètre d’inventaire n’est donc pas limité aux sites publics : recherchez aussi les installations PHP utilisées à l’intérieur du réseau.

• Auto-hébergement : prévoir les correctifs et les sauvegardes↗
• Node.js : vérifier aussi le moteur d’application↗

Le WAF ne remplace pas le correctif

Cloudflare distingue ses protections : les nouvelles règles gratuites ne demandent pas d’activation, tandis que les clients Professional, Business et Enterprise doivent vérifier que leur Managed Ruleset est déployé en mode blocage. Le nouveau pare-feu de réponse est annoncé comme automatiquement déployé sur toutes les offres ; sa présence se vérifie dans Security > Security Rules. Aucune de ces couches ne remplace le correctif PHP.

Le CERT-FR précise désormais que désactiver upload-progress réduit la surface d’attaque pour CVE-2026-109619, pas pour les deux failles, et que ses contournements provisoires ne sont pas qualifiés. Si ni la mise à jour ni une atténuation adaptée ne sont possibles assez vite, le NCSC recommande d’envisager la mise hors ligne du système jusqu’à sa protection. Un contournement partiel ne doit pas devenir une réparation définitive.

Le CERT/CC détaille des mesures provisoires pour les deux failles, à appliquer ensemble, et demande de redémarrer les workers pour certaines modifications. Certaines recommandations déplacent la limitation de mémoire vers le système ou le conteneur. Ne recopiez pas isolément un réglage trouvé dans ce bulletin : faites valider l’ensemble pour votre déploiement. Ces atténuations ne donnent pas une protection complète.