Il s'agit apparemment d'une RCE sans authentification nécessaire, donc plutôt ennuyant. Il y aurait deux failles (CVE-2026-109618 et CVE-2026-109619) dont l'une peut être mitigée via configuration.
Une release coordonnée du correctif est prévue à 14h UTC soit 16h CEST
Donc on un exploit qui a été publié il y a plus de 12h, un analyste qui dit qu'il va y avoir des exploitations de masse sous 15 minutes et un fournisseur qui a un correctif mais qui refuse de le publier avant encore 6h. C'est ça qu'on appelle la « divulgation responsable » ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
2024 découverte de la faille via un audit externe
2026-07-30 confirmation que la faille est exploitable
2026-08-11 d'autres personnes découvrent aussi la faille, la fondation PHP décide qu'écrire un correctif est une priorité
2026-10-20 15:00 UTC l'existence des failles fuite publiquement
2026-10-20 19:30 UTC PHP.net confirme l'existence de la faille publiquement
2026-10-20 20:00 UTC certains détails techniques de la faille sont publiés, des exploits commencent à circuler
2026-10-20 23:00 UTC les mitigations recommandées par PHP.net aux ISP fuitent
2026-10-21 07:41 UTC le correctif est publié sans l'accord de PHP.net
2026-10-21 14:00? UTC PHP.net publie le correctif
Ce que j'en déduis c'est qu'un outils IA à dû découvrir une faille, en tout cas elle a été patché par IA (pour être aussi rapide et au regard de la taille du patch)… Et avant de la publier php a voulu la relire un minimum pour éviter de nouvelles failles ou autres régression…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Posté par nud .
Évalué à 3 (+1/-0).
Dernière modification le 23 octobre 2026 à 09:25.
Ben non, la faille a été découverte par des auditeurs en chair et en os il y a deux ans, les hyperscalers ont seulement permis de trouver un exploit en dédiant une quantité faramineuse de puissance de calcul au problème. L'"IA" a servi de fuzzer, en gros.
# Détails
Posté par nud . Évalué à 10 (+8/-0).
Il s'agit apparemment d'une RCE sans authentification nécessaire, donc plutôt ennuyant. Il y aurait deux failles (CVE-2026-109618 et CVE-2026-109619) dont l'une peut être mitigée via configuration.
Une release coordonnée du correctif est prévue à 14h UTC soit 16h CEST
Il y a une vidéo qui tourne et qui montrerait l'exploitation de la faille.
Ailleurs:
# irresponsible disclosure
Posté par Krunch (courriel, site web personnel) . Évalué à 8 (+6/-0). Dernière modification le 21 octobre 2026 à 10:10.
Donc on un exploit qui a été publié il y a plus de 12h, un analyste qui dit qu'il va y avoir des exploitations de masse sous 15 minutes et un fournisseur qui a un correctif mais qui refuse de le publier avant encore 6h. C'est ça qu'on appelle la « divulgation responsable » ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: irresponsible disclosure
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0).
Oui j'ai du mal à comprendre la chronologie des événements.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: irresponsible disclosure
Posté par Krunch (courriel, site web personnel) . Évalué à 7 (+5/-0).
Une explication de PHP.net qui donne plus de détails sur la chronologie : https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
2024 découverte de la faille via un audit externe
2026-07-30 confirmation que la faille est exploitable
2026-08-11 d'autres personnes découvrent aussi la faille, la fondation PHP décide qu'écrire un correctif est une priorité
2026-10-20 15:00 UTC l'existence des failles fuite publiquement
2026-10-20 19:30 UTC PHP.net confirme l'existence de la faille publiquement
2026-10-20 20:00 UTC certains détails techniques de la faille sont publiés, des exploits commencent à circuler
2026-10-20 23:00 UTC les mitigations recommandées par PHP.net aux ISP fuitent
2026-10-21 07:41 UTC le correctif est publié sans l'accord de PHP.net
2026-10-21 14:00? UTC PHP.net publie le correctif
Le correctif pèse plus de 10,000 lignes.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: irresponsible disclosure
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Ce que j'en déduis c'est qu'un outils IA à dû découvrir une faille, en tout cas elle a été patché par IA (pour être aussi rapide et au regard de la taille du patch)… Et avant de la publier php a voulu la relire un minimum pour éviter de nouvelles failles ou autres régression…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: irresponsible disclosure
Posté par nud . Évalué à 3 (+1/-0). Dernière modification le 23 octobre 2026 à 09:25.
Ben non, la faille a été découverte par des auditeurs en chair et en os il y a deux ans, les hyperscalers ont seulement permis de trouver un exploit en dédiant une quantité faramineuse de puissance de calcul au problème. L'"IA" a servi de fuzzer, en gros.
[^] # Re: irresponsible disclosure
Posté par Krunch (courriel, site web personnel) . Évalué à 3 (+1/-0).
Non. C'était un audit externe fait par des professionnels payés pour.
Non. Ils ont eu entre deux mois et deux ans pour écrire le patch.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: irresponsible disclosure
Posté par Krunch (courriel, site web personnel) . Évalué à 2 (+0/-0).
OK apparemment ils ont utilisé Grand Theft Autocomplete quand même pour écrire ce correctif https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065#commitcomment-206067056
C'est PHP après tout…
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Vision de la crise chez Framasoft
Posté par Valentin . Évalué à 3 (+2/-0).
https://status.framasoft.org/incidents/1106
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.