Faille PHP critique d’octobre 2026, vérifier et mettre à jour WordPress sans panne

Ce que tu dois retenir tout de suite

Les vulnérabilités CVE-2026-109618 et CVE-2026-109619 peuvent permettre une exécution de code à distance sans authentification. Le projet PHP indique que les installations qui traitent des requêtes web sont concernées, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed.

La faille se trouve dans PHP. WordPress n’est donc qu’une application concernée parmi d’autres. Un site PrestaShop, Drupal, Laravel, Joomla ou une application développée sur mesure peut aussi être exposé s’il repose sur un environnement PHP vulnérable.

WordPress.org le confirme dans sa mise à jour de sécurité critique consacrée à PHP. Aucune mise à jour particulière de WordPress n’est requise ni prévue pour corriger ces deux failles.

Sur un hébergement mutualisé ou infogéré, le correctif dépend le plus souvent de l’hébergeur. Sur un VPS ou un serveur que tu administres toi-même, cette responsabilité revient à la personne qui gère le système. Le bon geste n’est donc pas toujours de cliquer sur une nouvelle version PHP. Il consiste d’abord à savoir qui gère la couche serveur et ce qui a réellement été installé.

Les versions publiées par le projet PHP

Le projet PHP a publié quatre versions corrigées le 21 octobre 2026.

Branche PHP	Version officielle corrigée	Ce que cela signifie
PHP 8.5	PHP 8.5.12	Une installation construite directement depuis les versions officielles doit utiliser 8.5.12 ou une version 8.5 plus récente.
PHP 8.4	PHP 8.4.27	Le seuil officiel corrigé est 8.4.27.
PHP 8.3	PHP 8.3.36	Le seuil officiel corrigé est 8.3.36.
PHP 8.2	PHP 8.2.35	Le seuil officiel corrigé est 8.2.35. PHP 8.2 arrive en fin de support le 31 décembre 2026.

Ces numéros sont les versions publiées par le projet PHP. Ils sont exacts, mais ils ne suffisent pas à interpréter tous les hébergements.

Les distributions Linux et les fournisseurs de support longue durée peuvent reprendre le correctif et l’intégrer dans leur propre paquet. On parle de rétroportage. Le numéro principal reste alors identique, tandis qu’un numéro de révision du paquet permet d’identifier la nouvelle construction.

Chez un hébergeur utilisant CloudLinux, comme o2switch, PHP peut par exemple rester affiché en 8.3.35 dans WordPress alors que le paquet installé est 8.3.35-6 et contient le correctif. 8.3.35 et 8.3.35-6 ne désignent pas exactement le même paquet (le 23/10/2026 la version 8.3.36 est bien affichée chez o2switch). Le second nombre après le tiret appartient à la distribution de l’hébergeur. Il ne correspond pas à une version officielle publiée sur php.net.

Oui, il faut parfois vérifier un numéro qu’aucun écran WordPress ne montre. La sécurité adore les petits caractères.

Pourquoi WordPress peut afficher une ancienne version pourtant corrigée

Dans WordPress, la ligne « Version de PHP » indique généralement la version de base. Elle peut afficher 8.3.35 sans montrer la révision 8.3.35-6 du paquet CloudLinux. Tu ne peux donc pas conclure automatiquement que le serveur reste vulnérable à partir de ce seul écran.

Le 22 octobre 2026, o2switch a indiqué avoir déployé les paquets CloudLinux corrigés sur ses serveurs. Pour PHP 8.3, le support mentionne le paquet 8.3.35-6. Pour PHP 8.4, il mentionne 8.4.26-5. Ces versions illustrent le principe du rétroportage mais ne elles ne constituent pas une liste universelle pour tous les hébergeurs.

CloudLinux publie de son côté des révisions différentes selon la famille de paquets, le système et le dépôt utilisés. Un serveur équipé d’ALT-PHP et un serveur équipé d’EA-PHP peuvent donc afficher des références différentes tout en intégrant le même correctif de sécurité.

La date de construction peut aider à contrôler le déploiement. Elle ne remplace toutefois pas une confirmation du fournisseur. Une date récente ne prouve pas à elle seule que les deux CVE ont été corrigées.

Vérifier ton site sans tirer de conclusion trop vite

Dans l’administration WordPress, ouvre Outils, puis Santé du site. Va dans Informations et déplie la rubrique Serveur. Tu trouveras la version PHP utilisée par le site.

Note cette version, mais considère-la comme un premier indice. Ouvre ensuite le panneau de ton hébergeur et cherche la rubrique consacrée à PHP. Selon le service, elle peut s’appeler Configuration PHP, Sélecteur PHP, MultiPHP Manager ou Paramètres du site.

Si l’interface montre une révision complète du paquet, compare-la au bulletin de ton fournisseur. Si elle montre seulement 8.3.35 ou 8.4.26, demande une confirmation écrite. La question utile tient en deux phrases.

« Pouvez-vous me confirmer que les correctifs contre CVE-2026-109618 et CVE-2026-109619 sont actifs sur l’environnement PHP de mon site ? Quelle révision de paquet est installée pour la branche que j’utilise ? »

Une réponse qui indique seulement « nous utilisons PHP 8 » reste trop vague. Il faut obtenir la branche, la révision du paquet ou une confirmation explicite du rétroportage.

Qui doit effectuer la mise à jour PHP

Ton site est sur un hébergement mutualisé ou infogéré

Dans ce cas, l’hébergeur maintient généralement le système et installe les paquets PHP. Il peut déployer le correctif sans intervention de ta part. Certains panneaux te laissent choisir une branche PHP, mais ce réglage ne signifie pas que tu gères les correctifs du serveur.

Commence donc par consulter l’état du service, les annonces de sécurité et la réponse du support. Ne change pas de branche uniquement parce que WordPress affiche encore 8.3.35. Si l’hébergeur confirme que le paquet 8.3.35-6 est actif et corrigé, passer immédiatement en 8.4 n’est pas nécessaire pour fermer cette faille.

Tu administres ton serveur ou ton VPS

Dans ce cas, la mise à jour te revient. Installe les correctifs proposés pour le système de ton serveur. Si tu utilises une ancienne branche de PHP maintenue par un service de support prolongé, applique les correctifs fournis par ce service.

Une installation compilée directement depuis les sources officielles doit utiliser au minimum PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon la branche installée.

Après la mise à jour, redémarre PHP et le serveur web pour qu’ils chargent le nouveau code. Vérifie ensuite la version du paquet installé, son journal de modifications et l’état des services.

Si ce passage ressemble déjà à une langue étrangère, confie l’intervention à l’administrateur du serveur. Le bouton magique « réparer PHP » n’existe pas encore.

L’interface de ton hébergement te demande de choisir toi-même une version de PHP

Certains hébergements te laissent sélectionner la branche utilisée par chaque site. Vérifie d’abord si le fournisseur a corrigé la branche actuelle. Un changement dans la même branche produit généralement moins d’effets qu’une migration de PHP 8.1 vers PHP 8.4.

Si ta branche n’est plus maintenue et que l’hébergeur ne propose pas de correctif rétroporté, prépare une migration. Mon guide sur la migration de WordPress vers PHP 8.3 explique comment vérifier les incompatibilités avant la mise en production.

Correctif de sécurité et changement de branche ne sont pas le même chantier

Installer une révision corrigée de PHP 8.3 conserve la même branche. Le risque de compatibilité reste en général limité, même si un contrôle du site demeure nécessaire.

Passer de PHP 8.1 à PHP 8.4, c’est une migration. Une extension ancienne, un thème abandonné ou un développement sur mesure peut utiliser du code qui n’est plus accepté. L’urgence consiste à fermer la faille. La migration consiste à remettre l’ensemble du site sur une base maintenue. Les deux opérations peuvent se suivre, mais elles ne demandent pas le même travail et niveau de test.

PHP 8.1 et les versions antérieures ne sont plus maintenus par le projet PHP. Certains hébergeurs peuvent néanmoins continuer à sécuriser ces anciennes branches en y intégrant des correctifs spécifiques. Ton site peut donc être protégé contre ces deux failles sans disposer d’une version de PHP encore officiellement maintenue. Cette protection ponctuelle ne remplace pas une migration préparée vers une branche récente, qui reste nécessaire pour recevoir l’ensemble des correctifs et préserver la compatibilité du site.

La méthode pour intervenir sans couper WordPress

Une fois la responsabilité et le paquet confirmés, adapte le niveau de précaution au changement réel.

Prépare une sauvegarde restaurable

Sauvegarde les fichiers et la base de données et garde une copie en dehors de ton hébergement. Note la branche PHP actuelle et le réglage et modules choisi dans le panneau. Une sauvegarde que personne n’a jamais essayé de restaurer reste une promesse, pas encore un plan. Le guide sur la sauvegarde et la restauration de WordPress t’aide à préparer ce filet de sécurité.

Mets les composants du site à niveau si tu changes de branche

Avant une migration, installe les versions maintenues de WordPress, du thème et des extensions. Vérifie surtout les composants qui touchent au paiement, aux formulaires, à l’espace membre, au cache et aux connexions avec d’autres services.

N’en profite pas pour changer de thème ou refaire le tunnel de commande. Quand cinq changements arrivent ensemble, le diagnostic devient une partie de Cluedo où tout le monde a touché au serveur.

Utilise un staging lorsque la compatibilité est incertaine

Pour un changement de branche ou un site doté de code sur mesure, teste d’abord sur une copie privée. Un site de staging WordPress permet de repérer une erreur sans l’afficher aux visiteurs.

Un correctif déployé par l’hébergeur dans le même paquet ne demande pas toujours une bascule manuelle. Il faut tout de même vérifier que le site fonctionne après l’intervention.

Contrôle les parcours qui comptent vraiment

Regarder la page d’accueil ne suffit pas. Teste l’administration, les formulaires et la réception des e-mails. Vérifie l’espace client, la recherche et les tâches planifiées. Si le site vend en ligne, réalise une commande complète avec paiement, stock, facture et message de confirmation.

Consulte aussi les journaux d’erreurs PHP et serveur. Une page qui s’affiche peut cacher une tâche planifiée ou un webhook en échec.

Surveille après la correction

Observe les erreurs et les fonctions importantes pendant les heures qui suivent. Note la branche, la révision du paquet et la réponse de l’hébergeur. Cette trace te fera gagner du temps lors de la prochaine alerte.

Que faire si le changement provoque une erreur critique

Si le site tombe après une migration de branche, reviens temporairement à la configuration précédente afin de rétablir le service. Consulte ensuite les journaux pour identifier l’extension, le thème ou le code incompatible.

Ce retour arrière ne doit pas laisser durablement le serveur sur un paquet vulnérable. Si le problème apparaît après un correctif appliqué dans la même branche, contacte l’hébergeur. Le fournisseur pourra vérifier les modules, le cache d’opcode et le redémarrage des processus PHP.

Mon guide sur l’erreur critique WordPress détaille les bons réflexes pour reprendre la main sans ajouter une panne à la panne.

Et si le serveur a déjà été attaqué

La mise à jour ferme les chemins connus, mais elle ne retire pas un fichier ou un compte ajouté avant la correction. Si les journaux montrent une activité suspecte, si des administrateurs inconnus apparaissent ou si le site redirige ses visiteurs, traite la situation comme un incident majeur.

Conserve les journaux du serveur et limite temporairement les accès non indispensables. Vérifie les comptes, les fichiers récemment modifiés, les tâches automatisées et les connexions inhabituelles. Si l’analyse révèle qu’un accès a pu être dérobé, renouvelle les mots de passe et les clés concernés depuis un ordinateur dont tu es certain qu’il n’a pas été compromis. Sur un serveur que tu administres toi-même, fais-toi accompagner si tu ne peux pas déterminer précisément ce qui a été touché.

En conclusion

Ces failles concernent PHP et toutes les applications web qui l’utilisent, pas seulement WordPress. Sur un hébergement mutualisé, demande d’abord à l’hébergeur si le correctif est installé. Ne te fie pas uniquement au numéro visible dans Santé du site.

Si tu administres le serveur, applique les mises à jour de sécurité disponibles et redémarre les services concernés. Dans les deux cas, distingue le correctif urgent d’une migration vers une nouvelle branche de PHP. Une mise à jour PHP réussie commence par la bonne question, pas par le premier bouton disponible.

Tu ne sais pas si ton site est réellement protégé ou tu crains de provoquer une panne en changeant de version ? Contacte-moi. Je peux vérifier ta configuration et t’accompagner dans la mise à jour.