Pourquoi des sites web ont-ils été mis hors ligne ?
Des sites ont été suspendus par précaution face à deux vulnérabilités critiques de PHP, un langage exécuté sur les serveurs pour faire fonctionner des applications web. Ces failles peuvent permettre une exécution de code à distance sans authentification : un attaquant pourrait faire exécuter des instructions au serveur sans disposer d’un compte. Une fermeture préventive ne prouve donc pas qu’un site a été piraté.
Le projet PHP a annoncé une publication de sécurité le 20 octobre 2026, puis diffusé les correctifs le 21 octobre. CERT-EU recommande de corriger immédiatement les installations concernées et, lorsque cela reste impossible, d’envisager leur isolement des réseaux publics jusqu’à l’application et à la vérification du correctif.
Pour une entreprise au Maroc, la priorité consiste à vérifier l’environnement réellement utilisé par son site et à obtenir une confirmation technique de son hébergeur. Les informations ci-dessous tiennent compte des annonces officielles consultées le 23 octobre 2026, notamment d’un avis complémentaire publié ce jour-là.
Deux vulnérabilités dans PHP, au-delà du logiciel du site
Les identifiants CVE servent à distinguer les vulnérabilités connues. CVE-2026-109618 concerne une corruption de mémoire pendant le traitement d’un manque de mémoire. CVE-2026-109619 implique un état interne conservé entre des requêtes alors que la mémoire correspondante a déjà été libérée. Les avis du projet PHP expliquent que ces défauts peuvent conduire à une exécution de code à distance.
Le risque concerne les installations PHP qui traitent des requêtes web, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet PHP considère mod_php comme la configuration présentant le risque le plus élevé : une exploitation démontrée peut intervenir avant même l’exécution du code de l’application. Les conditions techniques varient toutefois selon l’environnement.
La vérification ne doit donc pas se limiter aux extensions ou au thème d’un site. Il faut aussi contrôler le moteur PHP qui exécute l’application. Pour un dirigeant, la bonne demande à transmettre au prestataire est précise : identifier les services exposés, confirmer leur statut de correction et documenter les vérifications effectuées.
Quelles versions corrigent les failles du 21 octobre ?
Les versions publiées le 21 octobre 2026 pour corriger les deux vulnérabilités sont PHP 8.2.35, PHP 8.3.36, PHP 8.4.27 et PHP 8.5.12. Chaque numéro correspond à une branche distincte. La correction peut donc passer par la mise à jour de la branche déjà utilisée, sous réserve de sa maintenance et des recommandations du fournisseur.
PHP 8.1 et les branches antérieures ne reçoivent plus les mises à jour ordinaires du projet. Certaines distributions et certains fournisseurs de support prolongé proposent des correctifs rétroportés, c’est-à-dire adaptés à une ancienne version. Un numéro ancien doit ainsi être examiné avec le bulletin du fournisseur, sans conclure automatiquement que le correctif est absent ou présent.
Demandez une preuve couvrant explicitement CVE-2026-109618 et CVE-2026-109619. Une réponse indiquant simplement que l’hébergement est sécurisé ne permet pas de vérifier le traitement de ces deux failles. Pour un environnement obsolète, faites également préciser le calendrier de migration vers une branche maintenue.
Ce que change l’avis complémentaire du 23 octobre
Le 23 octobre 2026, PHP a signalé un autre scénario pouvant conduire à une exécution de code à distance, référencé CVE-2026-115560. Il concerne une combinaison inhabituelle de configuration et de code applicatif, impliquant un changement du mécanisme de sérialisation des sessions pendant l’exécution et la fonction de suivi de progression des téléversements.
PHP recommande de définir session.upload_progress.enabled=0 jusqu’à la prochaine version corrective régulière pour se protéger de ce scénario. CERT-EU précise de redémarrer les processus PHP concernés. Le projet indique aussi que les applications ne changeant jamais ce mécanisme de sérialisation pendant l’exécution peuvent conserver la fonction activée.
Cette mesure complémentaire doit être évaluée par l’administrateur. Elle ne remplace pas les mises à jour du 21 octobre et ne signifie pas que toutes les applications corrigées sont exploitables par ce nouveau scénario. Il faut traiter séparément les deux vulnérabilités initiales et cette configuration particulière.
Que demander à votre hébergeur ou à votre développeur ?
Commencez par demander l’inventaire des environnements PHP associés à votre activité : site principal, sous-domaines, boutique, espace client et anciennes applications encore accessibles. Faites confirmer la version ou le paquet corrigé utilisé par chaque service. Sur un hébergement administré, demandez qui applique les correctifs et qui valide le fonctionnement après intervention.
Avant la modification, prévoyez une sauvegarde exploitable et un moyen de retour arrière. Après la correction, testez les parcours importants : connexion, formulaire, téléversement, commande et paiement selon votre site. Vérifiez aussi la bonne réception des demandes. Ces contrôles constituent des précautions opérationnelles recommandées ; ils ne remplacent pas la validation de sécurité du serveur.
Si une intrusion est suspectée, demandez une investigation plutôt qu’une simple remise en ligne. Dans un billet publié le 21 octobre, Amazon rapporte avoir détecté une tentative d’exploitation dès le 17 octobre sur son infrastructure leurre MadPot. Amazon précise que la réussite de ces tentatives sur des systèmes réels restait incertaine. Cette observation justifie d’examiner les traces antérieures à l’annonce publique sans présumer que votre site a été compromis.
QUESTIONS FRÉQUENTES
Ce qu’il faut retenir.
01Le cadenas HTTPS protège-t-il contre cette faille PHP ?
Le cadenas concerne la connexion chiffrée entre le navigateur et le site. Il ne confirme pas que le moteur PHP du serveur est corrigé. Demandez à l’hébergeur une confirmation portant explicitement sur les vulnérabilités concernées.
02Faut-il changer d’hébergeur immédiatement ?
Évaluez d’abord sa réponse : identification des installations concernées, disponibilité des correctifs, délai d’intervention et vérification après mise à jour. Si aucune solution documentée n’est proposée pour un environnement obsolète, préparez une migration avec un prestataire capable de maintenir une branche corrigée.
03Désactiver le suivi de progression des téléversements suffit-il ?
Cette mesure ne remplace pas les correctifs des deux vulnérabilités initiales. Pour le scénario particulier CVE-2026-115560 annoncé le 23 octobre 2026, PHP recommande cette désactivation jusqu’à la prochaine version corrective régulière. Faites appliquer et vérifier la configuration par l’administrateur.
04Une sauvegarde permet-elle de remettre un site en ligne sans corriger PHP ?
Une sauvegarde fournit une possibilité de restauration, mais elle ne corrige pas le moteur PHP vulnérable. Avant toute remise en ligne, faites vérifier l’environnement d’exécution et, en cas de suspicion d’intrusion, l’intégrité des éléments restaurés.
05Un site marocain est-il concerné si son serveur est hébergé à l’étranger ?
Le pays du propriétaire ou du serveur ne détermine pas l’exposition à ces vulnérabilités. Les éléments à vérifier sont l’utilisation de PHP, l’environnement technique, l’accessibilité du service et la présence des correctifs applicables.
Transformons cette idée en plan d’action.
Parlez-nous de votre contexte et de votre priorité actuelle.
Recevoir mon plan d’acquisition
Comment gérer l’interruption sans aggraver ses effets ?
Si la correction immédiate est impossible, faites décider l’isolement technique avec le responsable de l’hébergement. Une page de maintenance produite par l’application PHP vulnérable ne constitue pas, à elle seule, une preuve d’isolement. Demandez plutôt comment les requêtes publiques seront empêchées d’atteindre le service concerné et comment une information indépendante pourra être présentée aux visiteurs.
Pour une indisponibilité courte, Google recommande une page informative renvoyant le statut HTTP 503, qui signale une indisponibilité temporaire, avec une indication Retry-After lorsque cela est possible. Sa documentation conseille une page statique et déconseille de remplacer les pages par des erreurs 404 ou des instructions noindex pour une fermeture temporaire. Une interruption prolongée peut néanmoins affecter la présence dans les résultats de recherche.
Côté acquisition, envisagez de suspendre les annonces qui dirigent vers des pages indisponibles. Indiquez un moyen de contact utilisable et évitez de promettre une heure de retour non confirmée. Après rétablissement, contrôlez les pages de destination et les formulaires avant de relancer les campagnes. Conservez enfin la confirmation des correctifs, les résultats des tests et le nom du responsable de la maintenance.