Certes, certes… Mais tout de même, deux réflexions me viennent :
si personne n'avait réagi immédiatement et qu'un piratage avait eu lieu, qu'en aurions nous pensé ? Pour ma part : qu'ils ont été encore une fois un peu légers malgré les récentes attaques.
si c'est si peu grave, peut être que les gars de PHP se sont payé un peu de pub pour pas trop cher ?
Quoiqu'il en soit, malgré le nombre de sites qui ont stoppé leurs serveurs le temps de faire la mise à jour (et l'inconfort induit), on ne va tout de même pas se plaindre de ce soi-disant excès de prudence, si ?
La réaction à l'annonce est la bonne, vu le score élevé et le risque d'exécution de code arbitraire. Mais il y a eu pas mal de site hors ligne pendant une demi journée.
La question est, est-ce que l'annonce elle-même n'était pas un peu exagérée? Est-ce que finalement la réaction de tout mettre hors ligne ne cause pas plas d'ennuis que la faille qui finalement n'est pas si simple à exploiter que ça?
Est-ce que si on commence à avoir des failles annoncées comme ça tous les jours, alors que inalement ce n'est pas exploitable, les gens vont arrêter de mettre leur site hors ligne à chaque fois?
Est-ce que si on commence à avoir des failles annoncées comme ça tous les jours, alors que inalement ce n'est pas exploitable, les gens vont arrêter de mettre leur site hors ligne à chaque fois?
Des RCE avec un CVSS supérieur à 9 touchant plus de 65% des sites web, c'est quand même pas tous les jours :-)
Certes, il semble qu'il faille (oh oh) s'aider d'un LLM pour l'exploiter mais je suppose que les attaquants utilisent massivement ce genre d'outil.
Un LLM est peut-être négessaire, mais pas suffisant.
L'article de Sansec qui prévoyait la fin du monde une exploitation massive dans les 15 minutes suivant la publication a été mis à jour avec un bandeau expliquant que finalement, l'attaque nécessite de très bien connaître l'intérieur du serveur cible, et que l'exploit publié ne fonctionne pas de façon aussi générule qu'annoncé. Les exploits publiés, soit ont besoin d'un fichier déjà vulnérable à une attaque par inclusion de fichier local, soit sont générées par un LLM qui injecte lui-même une telle vulnérabilité dans le système qu'on lui demande de tester.
Recorded future (qui existe depuis 2012) annonce de nombreuses tentatives de scan et d'attaque, mais pas de chiffres disponibles sur le succès des attaquants.
Les vendeurs de solution de sécurité semble profiter un peu de la panique pour se faire de la publicité, avec un argument infaillible du genre "ce type d'attaque est irréalisable si votre serveur est équipé de notre solution" (sans préciser que c'est irréalisable aussi sur les serveurs non équipés de leur solution).
En attendant on est noyés sous les tentatives de proof of concept ne fonctionnant pas vraiment, dont certains prétendant exploiter une faille basée sur des rumeurs avant publication des détails et qui n'existe tout simplement pas. Malheureusement, la déconnexion avec la réalité rend difficile de trouver et de faire confiance à des vraies informations.
Cela ne démontre pas que l'exploitation est impossible, mais, soit qu'elle coûte plus de 2000 dollars de token de LLM, soit que c'est suffisament compliqué pour être hors de portée du premier script kiddie venu, et qu'une attaque éventuelle reste entre les mains de gens qui préfèrent garder leurs attaques sous la main pour des cibles plus intéressantes
J'avais pas compris qu'il n'y avait pas besoin de publier l'exploit en lui-même, seulement de, j'imagine, trouver la clé d'un wallet, un CTF en somme. C'est moins intéressant du coup.
En résumé: la faille permet d'abord d'extraire l'adresse de base du code et du tas pour l'allocation mémoire (qui sont toutes les deux choisies aléatoirement au démarrage d'un worker PHP). à partir de ces deux valeurs et en connaissant exactement le binaire de PHP utilisé (en l'occurence, celui compilé par Alpine Linux), on peut arriver, en utilisant la faille une troisième fois, à injecter une structure de données qui sera appelée par la fonction cleanup de php. On peut à ce niveau exécuter le code révélant l'adresse du portefeuille bitcoin (mais en principe on pourrait exécuter n'importe quelle autre commande sur le serveur).
Il reste donc la contrainte que ce script ne s'applique qu'à une version compilée spécifique de PHP, mais il est adaptable à d'autres versions (il y a plusieurs valeurs codées en dur dans le script pour correspondre à ce build spécifique de PHP, mais ça peut être ajusté pour cibler un autre build et probablement pour essayer d'en reconnaître plusieurs différents).
L'attaque se déroule au total en une vingtaine de requêtes HTTP, et réussit environ 7 fois sur 10 (ça dépend entre autres du fait d'arriver à exécuter plusieurs requêtes sur le même worker, en fonction de la configuration et de la charge de la cible, cela peut être plus compliqué sur un site qui reçoit beaucoup plus de traffic).
On peut donc être "rassuré", la faille est bien exploitable et l'estimation de risque plutôt correcte.
Déjà j'aurais tendance à dire que non, il n'y a pas eu panique, mais une réponse rapide à un problème grave.
Une faille permettant d'exécuter du code à distance, c'est un risque non négligeable de voir son serveur transformé en relai. Un fois infecté il peut être difficile de trouver une backdoor installée, et cela peut nécessiter une réinstallation complète et un audit des bases (ou une restauration pré-datant l'infection)
Bref des procédure lourde, avec un risque de 'et si', si on laisse le truc tel quel.
À l'inverse, couper les serveurs le temps que le correctif arrive, ce qui au passage permet de faire les autres maintenances qu'on avait procrastiné en se disant que bof, y'a pas le feu au lac… Et pour certain mettre à jour avec le dernier PHP.
Le monde ne va pas s'arrêter de tourné parce que des serveur se sont coupé 24H (et encore je suis large)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Oui mais...
Posté par Bernie . Évalué à 10 (+11/-0).
Certes, certes… Mais tout de même, deux réflexions me viennent :
Quoiqu'il en soit, malgré le nombre de sites qui ont stoppé leurs serveurs le temps de faire la mise à jour (et l'inconfort induit), on ne va tout de même pas se plaindre de ce soi-disant excès de prudence, si ?
# a-t-on paniqué ?
Posté par steph1978 . Évalué à 10 (+15/-0).
Est-ce de la panique ou de la bonne hygiène ?
On t'annonce une faille permettant un RCE sur un de tes services exposé sur Internet.
Plus tard, tu cherches les preuves d'une éventuelle compromission.
[^] # Re: a-t-on paniqué ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 23 octobre 2026 à 16:16.
La réaction à l'annonce est la bonne, vu le score élevé et le risque d'exécution de code arbitraire. Mais il y a eu pas mal de site hors ligne pendant une demi journée.
La question est, est-ce que l'annonce elle-même n'était pas un peu exagérée? Est-ce que finalement la réaction de tout mettre hors ligne ne cause pas plas d'ennuis que la faille qui finalement n'est pas si simple à exploiter que ça?
Est-ce que si on commence à avoir des failles annoncées comme ça tous les jours, alors que inalement ce n'est pas exploitable, les gens vont arrêter de mettre leur site hors ligne à chaque fois?
[^] # Re: a-t-on paniqué ?
Posté par bbo . Évalué à 4 (+2/-0).
Des RCE avec un CVSS supérieur à 9 touchant plus de 65% des sites web, c'est quand même pas tous les jours :-)
Certes, il semble qu'il faille (oh oh) s'aider d'un LLM pour l'exploiter mais je suppose que les attaquants utilisent massivement ce genre d'outil.
[^] # Re: a-t-on paniqué ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8 (+5/-0). Dernière modification le 25 octobre 2026 à 10:14.
Un LLM est peut-être négessaire, mais pas suffisant.
L'article de Sansec qui prévoyait
la fin du mondeune exploitation massive dans les 15 minutes suivant la publication a été mis à jour avec un bandeau expliquant que finalement, l'attaque nécessite de très bien connaître l'intérieur du serveur cible, et que l'exploit publié ne fonctionne pas de façon aussi générule qu'annoncé. Les exploits publiés, soit ont besoin d'un fichier déjà vulnérable à une attaque par inclusion de fichier local, soit sont générées par un LLM qui injecte lui-même une telle vulnérabilité dans le système qu'on lui demande de tester.Recorded future (qui existe depuis 2012) annonce de nombreuses tentatives de scan et d'attaque, mais pas de chiffres disponibles sur le succès des attaquants.
Les vendeurs de solution de sécurité semble profiter un peu de la panique pour se faire de la publicité, avec un argument infaillible du genre "ce type d'attaque est irréalisable si votre serveur est équipé de notre solution" (sans préciser que c'est irréalisable aussi sur les serveurs non équipés de leur solution).
En attendant on est noyés sous les tentatives de proof of concept ne fonctionnant pas vraiment, dont certains prétendant exploiter une faille basée sur des rumeurs avant publication des détails et qui n'existe tout simplement pas. Malheureusement, la déconnexion avec la réalité rend difficile de trouver et de faire confiance à des vraies informations.
[^] # Re: a-t-on paniqué ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Il y a maintenant un défi avec
votre poids2000 dollars en bitcoin à la clé si vous êtes capables d'exploiter cette faille.Cela ne démontre pas que l'exploitation est impossible, mais, soit qu'elle coûte plus de 2000 dollars de token de LLM, soit que c'est suffisament compliqué pour être hors de portée du premier script kiddie venu, et qu'une attaque éventuelle reste entre les mains de gens qui préfèrent garder leurs attaques sous la main pour des cibles plus intéressantes
[^] # Re: a-t-on paniqué ?
Posté par steph1978 . Évalué à 4 (+2/-0).
Soit que ceux qui ont su l'exploiter ne sont pas prêts à vendre la mèche pour deux mille dollars.
[^] # Re: a-t-on paniqué ?
Posté par nud . Évalué à 5 (+3/-0).
Visiblement ça n'a pas tenu très longtemps.
[^] # Re: a-t-on paniqué ?
Posté par steph1978 . Évalué à 3 (+1/-0).
J'avais pas compris qu'il n'y avait pas besoin de publier l'exploit en lui-même, seulement de, j'imagine, trouver la clé d'un wallet, un CTF en somme. C'est moins intéressant du coup.
[^] # Re: a-t-on paniqué ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Le gagnant a quand même publié le script utilisé et quelques explications:
https://github.com/KillaBoi/StealMyBitcoin-PoC
En résumé: la faille permet d'abord d'extraire l'adresse de base du code et du tas pour l'allocation mémoire (qui sont toutes les deux choisies aléatoirement au démarrage d'un worker PHP). à partir de ces deux valeurs et en connaissant exactement le binaire de PHP utilisé (en l'occurence, celui compilé par Alpine Linux), on peut arriver, en utilisant la faille une troisième fois, à injecter une structure de données qui sera appelée par la fonction cleanup de php. On peut à ce niveau exécuter le code révélant l'adresse du portefeuille bitcoin (mais en principe on pourrait exécuter n'importe quelle autre commande sur le serveur).
Il reste donc la contrainte que ce script ne s'applique qu'à une version compilée spécifique de PHP, mais il est adaptable à d'autres versions (il y a plusieurs valeurs codées en dur dans le script pour correspondre à ce build spécifique de PHP, mais ça peut être ajusté pour cibler un autre build et probablement pour essayer d'en reconnaître plusieurs différents).
L'attaque se déroule au total en une vingtaine de requêtes HTTP, et réussit environ 7 fois sur 10 (ça dépend entre autres du fait d'arriver à exécuter plusieurs requêtes sur le même worker, en fonction de la configuration et de la charge de la cible, cela peut être plus compliqué sur un site qui reçoit beaucoup plus de traffic).
On peut donc être "rassuré", la faille est bien exploitable et l'estimation de risque plutôt correcte.
# C'est qui qui dit ça ?
Posté par coquecignux . Évalué à 6 (+5/-0). Dernière modification le 23 octobre 2026 à 14:11.
Un site, deux articles depuis début octobre.
Qui est l'auteur, quelle légimité −validée par des pairs− a-t-il à raconter ce qu'il dit ?
Peut-on se fier à son appartenance à une entreprise du domaine de la sécurité ?
IA pas question
# Bof
Posté par fearan . Évalué à 10 (+12/-0).
Déjà j'aurais tendance à dire que non, il n'y a pas eu panique, mais une réponse rapide à un problème grave.
Une faille permettant d'exécuter du code à distance, c'est un risque non négligeable de voir son serveur transformé en relai. Un fois infecté il peut être difficile de trouver une backdoor installée, et cela peut nécessiter une réinstallation complète et un audit des bases (ou une restauration pré-datant l'infection)
Bref des procédure lourde, avec un risque de 'et si', si on laisse le truc tel quel.
À l'inverse, couper les serveurs le temps que le correctif arrive, ce qui au passage permet de faire les autres maintenances qu'on avait procrastiné en se disant que bof, y'a pas le feu au lac… Et pour certain mettre à jour avec le dernier PHP.
Le monde ne va pas s'arrêter de tourné parce que des serveur se sont coupé 24H (et encore je suis large)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Bof
Posté par orfenor . Évalué à 3 (+1/-0).
Et puisqu'on ne sait pas si on a été compromis, personne ne peut dire que c'était beaucoup de bruit pour rien.
# Curieux lien
Posté par Voltairine . Évalué à 4 (+2/-0).
Il est bizarre ce site homonyme d'un personnage d'une vieille série de SF américaine où il n'y a que deux articles…
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.