Salut tout le monde,
Tenez à jour votre version php en prod.
https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-014/
Tenez à jour votre version php en prod.
https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-014/
Ah oui , je l'ai vu passer celle-ci. Énorme !
Ou plutôt je LES ai vu passer : deux failles critiques, depuis la version 5 de PHP, au moins une des deux possède un indice de 9.2 / 10 de criticité. On peut contrôler à distance le serveur, rien que ça.
Les versions de PHP inférieures à 7 ne recevront aucun correctif.
Imaginez le nombre de sites WordPress impactés dans le monde. Sans compter bien sûr les autres frameworks PHP comme Symfony, mais pour ces derniers au moins il y a des professionnels qui veillent au grain, dis-moins en principe.
Modifié par Olivier C (22 Oct 2026 - 16:51)
Ou plutôt je LES ai vu passer : deux failles critiques, depuis la version 5 de PHP, au moins une des deux possède un indice de 9.2 / 10 de criticité. On peut contrôler à distance le serveur, rien que ça.
Les versions de PHP inférieures à 7 ne recevront aucun correctif.
Imaginez le nombre de sites WordPress impactés dans le monde. Sans compter bien sûr les autres frameworks PHP comme Symfony, mais pour ces derniers au moins il y a des professionnels qui veillent au grain, dis-moins en principe.
Modifié par Olivier C (22 Oct 2026 - 16:51)
a écrit :
Imaginez le nombre de sites WordPress impactés dans le monde.
Wouai, en effet, j'imagine ; et je pense à tous mes amis qui me disaient que je perdais mon temps à développer des sites statiques alors que c'est si facile avec WordPress.
De plus en plus d'entreprises, fatiguées par les coûts cachés de maintenance de WordPress, sa lenteur et son exposition aux failles de sécurité (PHP...) passent à headless CMS.
Pouvez-vous en dire deux mots ici, qui l'utilise parmi vous ? Et l'intérêt pour des particuliers qui voudraient retrouver les avantages d'un site dynamique, sans les lourdeurs de WordPress ?
Alors attention, car dans ce cas la faille ne concerne pas WordPress directement mais PHP. Mais on se comprends, WordPress est utilisé dans une très grande partie des serveurs web actuels.
L’équipe de sécurité a sorti un correctif en un jour. Mais si la faille avait été découverte par quelqu’un d’autre auparavant, il aurait s’agit d’une Zero Day. On ne peut théoriquement pas le savoir. La cybercriminalité a encore des beaux jours devant elle.
L’équipe de sécurité a sorti un correctif en un jour. Mais si la faille avait été découverte par quelqu’un d’autre auparavant, il aurait s’agit d’une Zero Day. On ne peut théoriquement pas le savoir. La cybercriminalité a encore des beaux jours devant elle.
Peut-être que cette faille avait déjà été découverte par quelqu'un de mal intentionné, mais ça on ne le saura peut-être jamais. L'idée étant de vendre ce genre de faille : un zero-day tel que celui-ci se negocie des centaines de milliers de dollars, voir jusqu'à un million de dollars à des services de renseignements gouvernementaux ou privés.
Maintenant le problème est tout autre. Le correctif est sorti à 16h00, à 16h01 il faut imaginer des armées de hackers penchés sur le DIFF. C'est une course de vitesse entre ceux qui vont hacker et ceux qui vont patcher. Pour sécuriser le laps de temps nécessaire au déploiement du patch, certains sites importants ont pris la décision de passer leur site en mode maintenance durant une heure ou deux, histoire de ne pas se faire hacker dans l'intervalle.
Modifié par Olivier C (23 Oct 2026 - 05:11)
Maintenant le problème est tout autre. Le correctif est sorti à 16h00, à 16h01 il faut imaginer des armées de hackers penchés sur le DIFF. C'est une course de vitesse entre ceux qui vont hacker et ceux qui vont patcher. Pour sécuriser le laps de temps nécessaire au déploiement du patch, certains sites importants ont pris la décision de passer leur site en mode maintenance durant une heure ou deux, histoire de ne pas se faire hacker dans l'intervalle.
Modifié par Olivier C (23 Oct 2026 - 05:11)
Oui, j'ai vu cela entre-temps. Ce que j'en ai compris, c'est que personne n'avait les épaules pour patcher ce problème dans l'équipe PHP, ils n'ont pu mobiliser les moyens que devant l'urgence critique, car bien que la faille ait été découverte, elle semblait ne pas pouvoir exécuter de code, et finalement ils se sont aperçus, au bout de deux ans, que si. Je trouve que cette mésaventure renvoie un signal inquiétant pour l'avenir de l'écosystème à long terme.
Modifié par Olivier C (26 Oct 2026 - 23:45)
Modifié par Olivier C (26 Oct 2026 - 23:45)
Olivier C a écrit :
Oui, j'ai vu cela entre-temps. Ce que j'en ai compris, c'est que personne n'avait les épaules pour patcher ce problème dans l'équipe PHP, ils n'ont plus mobiliser les moyens que devant l'urgence critique, car bien que la faille ait été découverte, elle semblait ne pas pouvoir exécuter de code, et finalement si. C'est inquiétant tout de même pour l'avenir de l'écosystème à long terme.
+1
Pour compléter : le plus utile en prod, c'est de savoir quelle version de PHP tourne vraiment, serveur par serveur. L'hébergeur et le conteneur n'ont pas toujours la même. Un php -v suffit, et si vous avez fait un phpinfo pour vérifier, pensez à le supprimer après. Si le correctif n'est pas encore là chez votre hébergeur, regardez s'il propose un filtrage (WAF) en attendant. Ça ne remplace pas la mise à jour mais ça réduit un peu le risque. Et n'oubliez pas les vieux sites oubliés sur le même serveur, ce sont souvent eux qui restent en retard.
CrayonSEO a écrit :
Passer en maintenance le temps du déploiement, c'est malin. Par contre pour un petit site sur un mutualisé, on dépend entièrement de l'hébergeur : à part vérifier la version dans un phpinfo et croiser les doigts, on ne peut pas faire grand-chose.
Si je ne dis pas de bêtise, un hébergeur sérieux a l'obligation de protéger ses serveurs de son côté (cloisonnement strict des comptes, patchs système, open_basedir, mise à jour de sécurité, etc.). De notre côté (en tant que client), on reste 100 % responsables du code applicatif qu'on y dépose.
Il me semble même que si un client met en péril le serveur en se faisant exploiter une brèche RCE ou en générant du spam/déni de service, l'hébergeur n'hésite pas à prendre des mesures drastiques : c'est la suspension pure et simple du compte, sans préavis.
Niuxe a écrit :
Si je ne dis pas de bêtise, un hébergeur sérieux a l'obligation de protéger ses serveurs de son côté (cloisonnement strict des comptes, patchs système, open_basedir, mise à jour de sécurité, etc.). De notre côté (en tant que client), on reste 100 % responsables du code applicatif qu'on y dépose.
Il me semble même que si un client met en péril le serveur en se faisant exploiter une brèche RCE ou en générant du spam/déni de service, l'hébergeur n'hésite pas à prendre des mesures drastiques : c'est la suspension pure et simple du compte, sans préavis.
Oui, c'est le bon partage des rôles. Du coup, côté client, le plus utile reste de garder le CMS et les extensions à jour, de choisir la version PHP la plus récente dans le panneau, et d'avoir une sauvegarde hors de l'hébergement, au cas où le compte serait justement suspendu.