Chargement…

Faille critique PHP : vous avez jusqu'à 16h

Faille critique PHP : vous avez jusqu'à 16h

Hier, l'équipe sécurité de PHP a publié un préavis : une release de sécurité est programmée aujourd'hui, mercredi 21 octobre, à 14h UTC (16h à Paris).

Elle corrige deux vulnérabilités critiques, toutes les deux notées 9.2 en CVSS v4.0.

Un préavis de ce genre, ce n'est pas de la routine. Et quand on sait que PHP fait encore tourner environ 70 % des sites dont le langage serveur est connu (chiffres W3Techs), je vous laisse imaginer la surface d'attaque.

Pour l'instant, rien n'est publié : ni les détails, ni les versions touchées.

Mais il faut bien retenir une chose : à 16h, le correctif devient public, et le diff avec.

Un attaquant un minimum sérieux n'a qu'à comparer deux tags sur GitHub pour savoir exactement où taper, et avec un LLM pour lui mâcher la lecture du patch, l'exploit ne se compte plus en semaines mais en heures.

Donc ceux qui comptent patcher "la semaine prochaine" laissent la porte ouverte pile au moment où les scans de masse démarrent.

Et les plus mal barrés, ce ne sont pas ceux qui sont sur une version maintenue.

Ce sont ceux qui tournent encore sur PHP 8.1 ou plus ancien : les dernières releases de sécurité de septembre ne couvraient que les branches 8.2 à 8.5, donc pour les autres, il n'y aura probablement aucun correctif.

Pour rappel, W3Techs comptait encore 6,6 % des sites web sur PHP 5 en début d'année.

Ceux-là n'ont pas une mise à jour à faire, ils ont une migration en retard.

Je vous le demande sans détour, faites ça aujourd'hui :

  • Inventoriez toutes vos machines, conteneurs et images Docker qui embarquent PHP, avec leur version exacte.
  • Préparez votre montée de version et bloquez un créneau de déploiement dès 16h.
  • Gardez un œil sur php.net : l'équipe se réserve le droit de sortir le patch plus tôt si une exploitation active apparaît.
  • Si vous dépendez des paquets de votre distribution ou de votre hébergeur mutualisé, vérifiez dès maintenant quand ils backportent, car ce délai devient votre délai d'exposition.
  • Si vous êtes sur une version en fin de vie, considérez que vous êtes déjà exposé et planifiez la migration cette semaine.

Reste une question que je pose à chaque fois et à laquelle peu de boîtes savent répondre : si un patch critique tombait à 16h, combien de temps vous faudrait-il, honnêtement, pour qu'il soit en production partout ?

FAQ

À quelle heure exactement sort le correctif et faut-il s'y préparer dès maintenant ?

Le correctif est prévu à 14h UTC, soit 16h à Paris. Oui, il faut s'y préparer avant, car dès la publication, le diff devient public et exploitable rapidement par des attaquants.

Pourquoi deux failles notées 9.2 en CVSS v4.0 sont-elles si préoccupantes ?

Ce score reflète une criticité très élevée, proche du maximum, combinée au fait que PHP fait tourner environ 70 % des sites dont le langage serveur est identifiable. La surface d'attaque potentielle est donc énorme.

Quelles versions de PHP sont concernées par ce correctif ?

Les détails précis ne sont pas encore publiés, mais les dernières releases de sécurité de septembre ne couvraient que les branches 8.2 à 8.5. Les versions antérieures comme PHP 8.1 ou plus ancien risquent de ne recevoir aucun correctif.

Que risque-t-on concrètement si on tourne encore sur une version en fin de vie comme PHP 5 ou 7 ?

Ces versions ne bénéficieront probablement d'aucun patch, ce qui signifie une exposition permanente dès que la faille sera publique. Dans ce cas, il ne s'agit plus d'une mise à jour à planifier mais d'une migration urgente à entamer.

Combien de temps a-t-on réellement avant qu'un exploit circule ?

Très peu, potentiellement quelques heures seulement après la publication du patch à 16h. Un attaquant peut comparer les tags GitHub avant/après et s'appuyer sur un LLM pour analyser rapidement le correctif et en déduire la faille exploitable.

Que faire concrètement aujourd'hui avant la publication du patch ?

Il faut inventorier toutes les instances PHP (serveurs, conteneurs, images Docker) avec leur version exacte, bloquer un créneau de déploiement dès 16h, et vérifier les délais de backport de sa distribution ou de son hébergeur. Si on est sur une version en fin de vie, il vaut mieux considérer qu'on est déjà exposé et agir dans la semaine.


Poursuivre la lecture

Que dit le rapport du hack de la DGFIP ? News
#sécurité#gouv

Que dit le rapport du hack de la DGFIP ?

L'ANSSI a détaillé la compromission de la DGFIP : mots de passe volés, MFA absent, alerte ignorée. J'ai lu le rapport pour en tirer une checklist applicable à votre propre système.

Alexandre P.
OpenAI piraté en 72 heures News
#openai#hacking

OpenAI piraté en 72 heures

Un HEIF piégé, une lib non patchée, un SSO trop permissif : Hacktron a percé le forum d'OpenAI et remonté jusqu'au monorepo interne. Le détail de la chaîne d'attaque.

Alexandre P.