CVE-2026-109618 : la faille PHP à corriger sans attendre

Le 21 octobre 2026, PHP a publié un correctif pour CVE-2026-109618, une vulnérabilité permettant une exécution de code à distance sans authentification dans des configurations confirmées. Si votre site ou votre boutique utilise PHP, demandez dès maintenant à votre hébergeur de vérifier le moteur réellement en service. Mettre à jour un CMS ou ses extensions ne remplace pas cette intervention.

Cet article s’adresse aux responsables de sites et aux administrateurs qui doivent décider quoi vérifier, sans confondre une version installée avec un serveur effectivement corrigé. Les informations ci-dessous ont été vérifiées dans les avis officiels le 21 octobre 2026. Les versions et l’état des analyses peuvent évoluer : les sources en fin d’article restent la référence.

L’essentiel en une minute

• Le problème se situe dans PHP, le moteur qui exécute le code côté serveur, pas dans un thème ou un plugin particulier.
• Une exécution de code à distance sans connexion préalable a été démontrée avec Apache mod_php, sous le compte du processus web. Cela ne signifie pas automatiquement un accès administrateur au système.
• PHP-FPM n’est pas à considérer comme épargné : l’analyse du code le juge susceptible, même si aucun exploit complet FPM n’est démontré dans cet avis précis.
• Les premières versions corrigées des branches PHP amont maintenues sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les distributions peuvent fournir leurs propres correctifs rétroportés.
• La correction complète consiste à installer une version contenant le correctif, puis à renouveler les processus concernés et à vérifier le service.

Que permet exactement cette faille ?

La vulnérabilité touche la gestion des erreurs de manque de mémoire, appelées OOM pour « out of memory ». Dans certaines situations, PHP peut interrompre une opération alors que des données internes de la requête ne sont pas encore complètement initialisées. Le nettoyage de la requête peut ensuite traiter cet état invalide comme s’il était utilisable.

L’avis PHP décrit une conséquence grave : l’exécution de code choisi par un attaquant distant, sans authentification, dans le contexte du processus web. Les permissions de ce compte déterminent ensuite les données et ressources auxquelles il peut accéder. Il ne faut donc ni minimiser le risque, ni annoncer que chaque serveur exposé est déjà compromis.

Avec Apache mod_php, le scénario confirmé peut se produire avant même que le code de l’application commence à s’exécuter. Une protection située uniquement dans le CMS n’est donc pas une réponse suffisante. La fiabilité d’une exploitation dépend néanmoins de la compilation de PHP, des extensions, du frontal HTTP et de l’organisation de la mémoire : tous les environnements ne se comportent pas de manière identique.

Apache, PHP-FPM : qui doit vérifier son installation ?

Le nom du serveur web ne suffit pas. Apache peut exécuter PHP via mod_php ou transmettre les requêtes à PHP-FPM. Un autre frontal peut également transmettre les requêtes à FPM. Il faut identifier le mode d’exécution de PHP derrière chaque site, pas simplement lire la bannière du serveur.

Un site WordPress, WooCommerce, PrestaShop, Magento ou une application développée sur mesure peut être concerné si son moteur PHP est vulnérable. Le nom du CMS ne permet pas à lui seul de conclure. De même, un site dont la partie visible utilise une autre technologie peut encore appeler une API ou un service PHP.

Sur un hébergement mutualisé ou administré, ne modifiez pas au hasard la configuration : demandez une confirmation écrite au prestataire. Sur un serveur administré en interne, inventoriez les versions, les pools et les conteneurs réellement utilisés, y compris les tâches de fond.

Quelles versions de PHP contiennent le correctif ?

Pour les branches distribuées directement par le projet PHP, l’avis indique les versions corrigées suivantes. Choisissez la version corrigée de votre branche, ou une version ultérieure dont l’éditeur confirme qu’elle inclut le correctif.

Cette liste ne veut pas dire que les branches plus anciennes sont sans risque. Si vous utilisez une branche qui n’est plus maintenue en amont, vérifiez l’existence d’un support de sécurité chez votre distributeur ou fournisseur. À défaut, une migration vers une branche maintenue doit être organisée avec les vérifications de compatibilité nécessaires.

Le piège des versions Ubuntu et des correctifs rétroportés

Un numéro PHP qui paraît ancien peut contenir un correctif de sécurité ajouté par la distribution. Il faut comparer la version complète du paquet avec l’avis correspondant à votre version d’Ubuntu, et non comparer uniquement « 8.1 » ou « 8.3 » avec les versions PHP amont.

Au 21 octobre 2026, la fiche officielle Ubuntu indique notamment :

Ces repères concernent les paquets Ubuntu correspondants, pas automatiquement ceux d’un dépôt tiers, d’une image de conteneur ou d’un panneau d’hébergement. Pour les autres versions d’Ubuntu, consultez la matrice complète officielle. Ne copiez pas un numéro de paquet prévu pour une autre distribution.

Si un miroir ne propose pas encore la version annoncée, vérifiez la fraîcheur des métadonnées et la disponibilité du dépôt de sécurité officiel. Ne désactivez pas la vérification des signatures et n’ajoutez pas un dépôt inconnu pour obtenir simplement un numéro plus élevé. Un paquet « à jour » par rapport à un miroir en retard n’est pas nécessairement corrigé.

La bonne séquence : identifier, corriger, renouveler, vérifier

1. Identifier le PHP réellement utilisé

La commande php -v renseigne sur le binaire en ligne de commande. Elle ne prouve pas que le site utilise cette même version. Demandez ou vérifiez séparément le moteur HTTP, ses pools FPM éventuels, les modules Apache, les images de conteneurs et les consommateurs de files d’attente.

Sur un système Debian ou Ubuntu, dpkg-query -W et apt-cache policy permettent d’examiner les paquets installés et candidats. Ils doivent être utilisés avec les noms de paquets réellement présents. Conservez la version complète et la référence de l’avis de sécurité : une capture « PHP 8.x » est une preuve trop vague.

2. Préparer une intervention maîtrisée

Avant la mise à jour, vérifiez la compatibilité et les sauvegardes, relevez l’état des services et définissez quelques parcours de contrôle. Pour une boutique, cela peut inclure le catalogue, le panier et un scénario de commande dans un environnement de test prévu à cet effet. Ne déclenchez pas un paiement réel uniquement pour vérifier un correctif.

Un inventaire des paquets et une sauvegarde de configuration sont utiles, mais ne constituent pas une sauvegarde complète des données. Une mise à jour peut aussi redémarrer des services pendant l’installation, via les scripts du gestionnaire de paquets. Prévoyez cette interruption éventuelle au lieu de supposer qu’elle n’aura lieu qu’au redémarrage manuel final.

3. Installer les paquets corrigés de la bonne provenance

Utilisez le canal de mise à jour officiel de votre système ou de votre fournisseur. Examinez la transaction avant de l’appliquer : paquets concernés, version cible, suppressions éventuelles et changements sans rapport. L’objectif est de corriger le moteur et ses composants installés, pas de lancer simultanément une refonte de toute la pile.

Pour un conteneur, une image reconstruite ne suffit pas tant que les instances qui servent les requêtes n’ont pas été remplacées. Pour un hébergement géré, demandez la référence du correctif et la version effectivement déployée, pas seulement l’annonce d’une maintenance planifiée.

4. Renouveler aussi les processus qui restent en mémoire

Des fichiers corrigés sur disque peuvent coexister avec d’anciens processus PHP toujours actifs. Vérifiez le renouvellement des workers web et des processus PHP de longue durée. Les consommateurs de files d’attente, imports et traitements planifiés persistants peuvent nécessiter une procédure distincte.

Utilisez le mécanisme de redémarrage gracieux prévu par l’application et son superviseur, en tenant compte des tâches en cours. Ne tuez pas aveuglément un traitement d’inventaire ou de commande. Une commande de redémarrage acceptée n’est pas, à elle seule, la preuve que les anciens processus ont quitté : vérifiez les processus qui tournent réellement après l’intervention.

5. Contrôler le fonctionnement et conserver une preuve

Après l’intervention, vérifiez la version des paquets, les tests de configuration, l’état des services et les parcours représentatifs. Conservez l’heure du renouvellement des workers et le résultat des contrôles. Si un processus ancien subsiste, notez-le comme un point restant à traiter, pas comme une correction terminée.

Consultez aussi les journaux accessibles et les anomalies récentes. Une absence d’erreurs dans un échantillon ne démontre pas une absence de compromission. Des traces suspectes doivent faire l’objet d’une analyse séparée ; installer un correctif n’efface pas les conséquences d’une attaque antérieure.

Un pare-feu ou un changement de mémoire peut-il suffire ?

Non : l’avis PHP indique que seule une version contenant le correctif apporte une mitigation complète. Limiter la taille des requêtes, les entrées multipart ou les téléversements peut réduire certaines possibilités d’attaque et certains risques de déni de service, mais ne remplace pas la mise à jour.

L’avis décrit aussi un réglage temporaire de la limite mémoire pour les installations qui ne peuvent pas être corrigées immédiatement. Ce n’est pas une recette à copier dans un tutoriel généraliste : supprimer une limite PHP peut déplacer le risque vers l’épuisement des ressources du système, et certaines défaillances d’allocation restent possibles. Toute mesure transitoire doit être choisie par l’administrateur à partir de l’avis complet, avec surveillance et plan de correction.

Ne testez pas un exploit sur une boutique en production pour savoir si elle est vulnérable. La version, la provenance du paquet et le mode d’exécution donnent les premiers éléments de décision sans exposer les données ou la disponibilité à une expérimentation inutile.

Le message à envoyer à votre hébergeur

Vous pouvez transmettre cette demande en l’adaptant à votre contrat :

Bonjour, pouvez-vous confirmer le traitement de CVE-2026-109618 pour notre hébergement ? Merci de préciser le mode d’exécution PHP, la version complète du paquet ou de l’image corrigée, la référence de l’avis fournisseur et la date de renouvellement des workers. Merci également de vérifier les processus PHP de longue durée et l’avis lié GHSA-6wmf-4rv5-p3rp, puis de confirmer les contrôles de fonctionnement réalisés et les éventuels points restant ouverts.

Cette demande est plus utile que « avez-vous mis à jour PHP ? ». Elle distingue une intervention annoncée, un paquet installé et un service réellement corrigé.

Questions fréquentes

Mon WordPress est à jour : suis-je protégé ?

Pas nécessairement. La mise à jour de WordPress concerne l’application ; cette CVE concerne le moteur PHP. Il faut vérifier les deux couches séparément. Inversement, la présence de WordPress ne prouve pas que le moteur installé est vulnérable.

Je suis sous PHP-FPM : puis-je attendre ?

L’absence d’exploit complet FPM démontré dans cet avis n’est pas une garantie de sécurité. PHP-FPM est considéré comme susceptible par l’analyse du code. Vérifiez et appliquez le correctif correspondant à votre distribution ou à votre fournisseur.

Faut-il changer de version majeure de PHP immédiatement ?

Pas toujours. Une branche prise en charge peut recevoir une version corrective, et une distribution peut rétroporter le correctif. Une migration de branche devient nécessaire si votre fournisseur ne maintient plus votre version ; elle doit inclure les contrôles de compatibilité de l’application.

Le site fonctionne encore : cela signifie-t-il qu’il n’a pas été attaqué ?

Non. La disponibilité ne suffit pas à conclure sur une compromission. Corrigez la vulnérabilité et faites examiner les éléments suspects sans présenter quelques journaux sans erreur comme une garantie absolue.

Un CDN ou un WAF règle-t-il le problème ?

Ces protections peuvent filtrer certains échanges, mais elles ne corrigent pas le moteur PHP. Ne déclarez pas l’hébergement protégé uniquement parce qu’un filtre est activé : demandez la preuve du correctif et de son utilisation par les processus actifs.

Sources officielles et accompagnement

• Avis de sécurité PHP : CVE-2026-109618 / GHSA-w8hw-w9fx-j79w : mécanisme, modes d’exécution, versions corrigées et limites des mesures temporaires.
• Avis officiel PHP du 21 octobre 2026 : publications des versions de sécurité.
• Fiche Ubuntu CVE-2026-109618 : état des paquets par version de distribution.
• Avis Ubuntu USN-8948-1 : mises à jour de sécurité PHP associées.
• Avis PHP distinct CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp : recommandations complémentaires que l’avis principal demande également de suivre. Il s’agit d’un rapport distinct ; ses résultats d’exploitation ne doivent pas être attribués automatiquement à cette CVE.

Si vous avez besoin de clarifier qui assure les mises à jour et comment en vérifier le résultat, notre service d’hébergement et gestion technique permet de cadrer ces responsabilités. Pour une boutique, cette maintenance s’articule avec les contrôles fonctionnels d’un site e-commerce. Vous pouvez nous contacter pour définir le périmètre d’une vérification, les accès nécessaires et les livrables attendus, sans promesse de sécurité absolue ni diagnostic à distance sans examen.