Passer au contenu principal

Neotech Cloud Solutions

Home/Cybersécurité/Faille PHP critique : la mise à jour d’urgence du 21 octobre et votre site web
Code PHP coloré sur un écran sombre, illustrant la faille PHP critique corrigée le 21 octobre

Faille PHP critique : la mise à jour d’urgence du 21 octobre et votre site web

Votre site WordPress, votre boutique WooCommerce, votre portail client : sous le capot, ils roulent presque tous sur PHP, le langage qui fait fonctionner une grande partie du Web. Le 20 octobre, l’équipe PHP a prévenu les administrateurs de se préparer à une mise à jour d’urgence le lendemain, pour deux failles jugées critiques. Chaque faille PHP est notée 9,2 sur 10.

La plupart des propriétaires de PME n’ont jamais choisi leur version de PHP, et c’est justement le problème : c’est souvent quelqu’un d’autre qui doit appliquer le correctif. Voici ce qu’on sait, qui doit agir, et le courriel à envoyer aujourd’hui.

La faille PHP en quatre dates

Mar. 20 oct.

Après-midi

L’équipe PHP annonce une mise à jour de sécurité critique pour le lendemain : deux failles notées 9,2 sur 10.

Mar. 20 oct.

Le même jour

Selon watchTowr, des informations ont fuité avant la date prévue. Il s’agirait d’exécution de code à distance touchant PHP 5 à 8.

Mer. 21 oct.

10 h (HAE)

Correctifs publiés : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.

Jeu. 22 oct.

11 h (HAE)

La date de divulgation prévue au départ, selon watchTowr. Elle a été devancée.

Ce que php.net a publié le 21 octobre

L’avis de sécurité de php.net confirme deux failles critiques qui peuvent permettre l’exécution de code à distance sans authentification :

  • CVE-2026-109618 (exécution de code via une corruption liée au manque de mémoire) : la gestion d’un manque de mémoire peut interrompre PHP alors que des données internes de la requête ne sont que partiellement initialisées.
  • CVE-2026-109619 (exécution de code via un état global périmé) : un état interne propre à une requête peut survivre après la libération de sa mémoire, et être réutilisé par une requête suivante traitée par le même processus.

Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Selon php.net, toutes les installations PHP qui servent des pages Web sont à risque (PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed), et le risque est jugé le plus élevé avec mod_php. Les distributions Linux et les fournisseurs de soutien prolongé ont reçu les correctifs à l’avance : vérifiez leurs paquets à jour.

Pour PHP 7.4, 8.0 et 8.1, le projet PHP ne publie plus de mises à jour. Vu la gravité, l’équipe de sécurité a toutefois fourni des correctifs minimaux sous forme de code source, utiles surtout à ceux qui compilent PHP eux-mêmes. php.net précise que les mesures d’atténuation réduisent certains chemins d’attaque, mais qu’aucune ne remplace la mise à jour. C’est la page de référence pour savoir quoi installer; méfiez-vous des listes qui circulent ailleurs.

📏 9,2 ou 10 sur 10 : ça change quoi?

L’équipe PHP note chaque faille 9,2; les chercheurs de watchTowr parlent de 10. Pour une PME, la nuance compte peu : les deux chiffres veulent dire « critique, à corriger sans attendre ». Le vrai signal, c’est la fuite : quand les détails circulent avant le correctif, le délai avant les premières attaques raccourcit. Le 20 octobre, watchTowr disait n’avoir vu aucune exploitation, mais avoir reproduit une des failles.

Votre version de PHP reçoit-elle encore des correctifs?

PHP ne corrige que les branches encore prises en charge. Si votre site tourne sur une version plus ancienne, aucune mise à jour officielle n’arrivera, même pour une faille critique.

De la plus risquée à la plus sûre (selon php.net)

▲PHP 7.4, 8.0, 8.1 et plus anciennesFin de vie : aucune version officielle corrigée, seulement des correctifs minimaux en code source. À remplacer, pas à « surveiller ».
▲▲PHP 8.2Corrigée en 8.2.35, mais correctifs de sécurité jusqu’au 31 décembre 2026 seulement : planifiez déjà la suite.
▲▲▲PHP 8.3Corrigée en 8.3.36. Correctifs de sécurité jusqu’au 31 décembre 2027.
▲▲▲▲PHP 8.4 et 8.5Corrigées en 8.4.27 et 8.5.12. Les branches les plus récentes, prises en charge jusqu’en 2028 et 2029.

Bien des sites de PME tournent encore sur PHP 7.4 : un thème ou une extension ancienne « ne fonctionnait pas » en PHP 8, et on a remis la mise à niveau à plus tard. Certains hébergeurs maintiennent eux-mêmes de vieilles versions, mais demandez-le par écrit plutôt que de le supposer.

Qui doit appliquer le correctif de la faille PHP?

Votre site est… Qui installe le correctif PHP Votre rôle
Sur un hébergement partagé (cPanel, Plesk…) L’hébergeur met à jour PHP sur ses serveurs Vérifier la branche choisie pour votre site (ex. 7.4 ou 8.3) et demander la date d’application
Sur un hébergement WordPress géré L’hébergeur, en général automatiquement Obtenir une confirmation écrite, surtout si vous avez demandé une ancienne version
Sur un serveur privé virtuel (VPS) ou dédié Vous, ou la personne qui gère le serveur Planifier la mise à jour aujourd’hui, après une sauvegarde
Chez une agence web qui « s’occupe de tout » Ça dépend du contrat Demander qui est responsable, par écrit, et avant la fin de la journée
Sur une plateforme SaaS (Shopify, Wix, Squarespace…) La plateforme Rien à faire pour PHP

Le courriel à envoyer aujourd’hui

Pas besoin d’être technique. Copiez, adaptez, envoyez à votre hébergeur ou à votre agence :

À : soutien@votre-hebergeur.example

Objet : Mise à jour de sécurité PHP du 21 octobre : notre site

Bonjour,

1Notre site votre-entreprise.example est hébergé chez vous (compte n° ____).

2Pouvez-vous nous confirmer quelle version de PHP il utilise exactement?

3Quand appliquerez-vous la mise à jour de sécurité PHP du 21 octobre (8.5.12, 8.4.27, 8.3.36 ou 8.2.35, CVE-2026-109618 et CVE-2026-109619) sur nos serveurs?

4Si notre site est sur une version qui ne reçoit plus de correctifs, quelle version recommandez-vous, et pouvez-vous faire une sauvegarde avant le changement?

Merci de nous répondre par écrit.

Pourquoi ces questions

  • 1Le numéro de compte évite les allers-retours.
  • 2« Une version récente » n’est pas une réponse : il faut le numéro exact.
  • 3Une date précise vous dit si l’hébergeur prend la chose au sérieux.
  • 4Sur une version en fin de vie, il n’y aura pas de correctif officiel : il faut changer de version, et une sauvegarde d’abord.

Cinq étapes, dans l’ordre

ÉTAPE 1

Trouver la version

Dans WordPress : Outils, Santé du site, Infos, Serveur.

➜

ÉTAPE 2

Écrire à l’hébergeur

Le courriel ci-dessus, aujourd’hui.

➜

ÉTAPE 3

Sauvegarder

Fichiers et base de données, copie gardée hors du serveur.

➜

ÉTAPE 4

Mettre à jour

PHP, puis WordPress, thème et extensions.

➜

ÉTAPE 5

Tester

Formulaire de contact, paiement, connexion.

Une fois PHP à jour, profitez-en pour faire le ménage : extensions inutilisées, anciens comptes administrateurs, sauvegardes jamais testées. On a vu avec la faille Magento BlockStrap à quelle vitesse une boutique en ligne devient une cible, et nos 8 questions à poser à votre hébergeur web restent d’actualité.

Chez NeoTech, nous gérons des sites WordPress et des serveurs pour des PME : notre service de création de sites web inclut les mises à jour, et notre gestion des serveurs couvre les VPS. Avec nos services de cybersécurité : une surveillance automatisée signale les comportements anormaux sur vos serveurs.

Réservez votre Bilan cyber gratuit

Vous ne savez pas quelle version de PHP fait tourner votre site, ni qui est responsable des mises à jour? Le Bilan cyber gratuit commence par là : on vérifie votre site et votre hébergement, on clarifie qui fait quoi, puis on vous remet un plan clair.

👉 Réservez votre Bilan cyber gratuit

Appelez-nous au 438-476-2322 ou écrivez à info@neotechcloudsolutions.com.

Sources

Photo : Pixabay, Pexels (licence Pexels).

One thought on “Faille PHP critique : la mise à jour d’urgence du 21 octobre et votre site web”

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *