Cybersécurité 
Votre entreprise doit-elle agir ?
Si votre site ou application utilise PHP, demandez à votre hébergeur ou prestataire de confirmer le correctif appliqué. Deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, ont reçu des correctifs le 21 octobre 2026. Un site qui fonctionne normalement peut encore nécessiter une vérification. La priorité est de connaître les environnements exposés, de traiter ceux qui sont concernés et de conserver une preuve de l’intervention.
Les trois décisions à prendre
- 01Identifier les services qui exécutent réellement PHP et leur responsable.
- 02Obtenir la version ou le paquet correctif appliqué à chaque environnement.
- 03Vérifier les parcours utiles après intervention et organiser le suivi.
01
Ce qui a été annoncé les 20 et 21 octobre 2026
Après une annonce préalable le 20 octobre, des correctifs PHP ont été publiés le 21 octobre. Les deux vulnérabilités peuvent permettre une exécution de code à distance sans authentification. L’avis CERT-EU a été actualisé après la publication des versions corrigées.
Ce point de situation est vérifié au 22 octobre 2026. L’existence d’une vulnérabilité ne démontre pas qu’un site particulier a été compromis. Une capture d’un ancien avis annonçant un correctif à venir ne remplace pas la consultation de l’état actuel publié par l’éditeur.
Sources consultées
02
Quelles versions PHP corrigent ces vulnérabilités ?
L’avis actualisé répertorie quatre versions correctives. Le numéro de branche seul, par exemple « PHP 8.4 », ne permet pas de conclure : il faut identifier la version précise ou le paquet fournisseur effectivement installé.
Les distributions et fournisseurs LTS peuvent livrer leurs propres paquets corrigés. Pour une branche ancienne, faites confirmer le support disponible et la trajectoire de mise à niveau. Le résultat d’un scanner doit être rapproché de la référence du correctif fournisseur.
| Branche PHP | Version corrective annoncée | Preuve à demander |
|---|---|---|
| 8.5 | 8.5.12 | Version active ou référence fournisseur |
| 8.4 | 8.4.27 | Version active ou référence fournisseur |
| 8.3 | 8.3.36 | Version active ou référence fournisseur |
| 8.2 | 8.2.35 | Version active ou référence fournisseur |
03
WordPress, application métier, portail : dresser le bon inventaire
Le nom du CMS ne décrit pas toute la pile technique. Une entreprise peut exploiter un site vitrine, une boutique, un portail client et une interface d’administration sur plusieurs hébergements. Demandez qui maintient chaque service et quelle technologie l’exécute.
L’ENISA recommande d’identifier les applications basées sur PHP, de coordonner les interventions avec les fournisseurs et de prioriser les systèmes exposés à Internet. Certains produits embarquent PHP sans que cela soit évident pour leur utilisateur.
| À renseigner | Exemple d’information utile |
|---|---|
| Service et usage | Site public, boutique, portail ou outil interne |
| Environnement | Hébergeur, serveur ou service managé, production et préproduction |
| Responsable | Personne qui peut confirmer le runtime et appliquer le correctif |
| État vérifié | Correctif, date, preuve et action restant à traiter |
04
Les cinq réponses à obtenir de votre hébergeur ou agence
Pour passer d’une alerte à une décision, demandez un état propre à votre environnement. Un message générique indiquant que l’hébergeur suit la situation ne précise pas nécessairement le statut de votre site.
La grille suivante organise le dialogue. Elle permet de suivre les responsabilités et les preuves ; elle ne réalise pas de diagnostic automatique et ne constitue pas un certificat de sécurité.
05
HTTPS et pare-feu : comprendre leur rôle dans la sécurisation web
HTTPS protège les échanges ; sa présence n’atteste pas que le runtime PHP est corrigé. Un pare-feu web peut participer à la protection d’un service, mais ne doit pas être présenté comme la preuve que ces vulnérabilités sont supprimées.
PHP indique que la mise à jour est la solution complète. Les mesures temporaires décrites dans son avis ont des limites. Faites examiner leur pertinence et leurs effets par le responsable de l’environnement, en conservant le traitement du correctif comme action prioritaire.
Sources consultées
06
Si le correctif ne peut pas être appliqué immédiatement
L’ENISA recommande d’envisager l’isolement des applications exposées lorsque la remédiation immédiate n’est pas possible. Cette décision doit associer les responsables techniques et métier : services concernés, conséquences, communication et conditions du retour en ligne.
Préparez également ce qui permettra de vérifier le rétablissement. Pour une boutique, cela peut comprendre une commande de validation ; pour un portail, la connexion et l’accès aux bons documents. Un retour en ligne doit s’appuyer sur des éléments vérifiés, et pas seulement sur l’expiration d’une fenêtre de maintenance.
Sources consultées
07
Après l’urgence : organiser la maintenance et l’audit de sécurité
Cette alerte est aussi l’occasion de clarifier qui suit les dépendances, le serveur, les accès et les changements de votre produit. Le contrat doit décrire les environnements couverts, les interventions et la manière de vérifier les corrections.
Pour une entreprise en Belgique, Gaspa peut cadrer une demande de sécurisation web et le suivi des actions à examiner. Précisez les services concernés et les accès disponibles lors du premier échange. Aucun mot de passe ni secret de production ne doit être communiqué dans le formulaire de contact.
Approfondir la protection de votre environnement
- Sécuriser un site WordPress professionnelAccès, extensions, sauvegardes et responsabilités de maintenance.
- Audit cyber, pentest ou revue d’infrastructure ?Définir le périmètre, les preuves attendues et la vérification des corrections.
- Préparer la maintenance de votre applicationOrganiser les mises à jour et le suivi de votre produit.