Deux vulnérabilités critiques de PHP, référencées CVE-2026-109618 et CVE-2026-109619, devaient être corrigées le 21 octobre à 16h (heure de Paris), soit 14h00 UTC. Selon la société néerlandaise Sansec, des attaques de masse auraient commencé quinze minutes plus tard. Cet article distingue ce qui est établi, ce qui reste contesté et ce qui concerne réellement les services crypto.
🔑 En bref
- Correctif annoncé pour le 21 octobre à 16h (Paris), soit 14h00 UTC, pour CVE-2026-109618 et CVE-2026-109619 (CVSS v4.0 : 9,2/10).
- Sansec signale des attaques de masse environ 15 minutes après la publication, selon les informations rapportées, sans chiffres vérifiés.
- Le correctif officiel ne couvre que PHP 8.2 et supérieur : PHP 8.1 et 7.4 dépendent de leur hébergeur.
- Aucune exploitation spécifique aux services crypto n’est documentée ; le risque concerne surtout les sites de paiement et les interfaces DeFi.
Une chronologie serrée, mais des dates qui ne concordent pas
Selon le Journal du Coin, source principale de cette chronologie, l’équipe de sécurité de PHP devait publier le correctif le 21 octobre à 16h. Sansec aurait observé les premières attaques quinze minutes plus tard, après avoir comparé l’ancien code avec la version corrigée pour reconstituer l’exploit. Cette rétro-ingénierie transforme un correctif public en mode d’emploi.
La chronologie comporte toutefois des incohérences. L’article situe la divulgation « lundi 20 octobre au matin » et la publication « mercredi 21 octobre à 14h00 UTC », tout en évoquant un « jeudi » et des identifiants CVE portant le millésime 2026. Or le 20 octobre 2025 était un lundi et le 21 octobre 2025 un mardi ; en 2026, ces dates tombent un mardi et un mercredi. Aucune année ne réconcilie l’ensemble des jours cités.
L’alerte initiale aurait été publiée sur Hacker News le lundi matin. Le message a ensuite disparu, mais une capture d’écran conserve un outil baptisé PHP2Shell, attribué à Calif.IO, dont la bannière revendique une compatibilité avec toutes les versions depuis PHP 5.4.0 (2012). Cette revendication décrit l’outil présenté dans l’image ; elle ne confirme pas à elle seule les versions réellement touchées. Les chercheurs de watchTowr auraient confirmé l’existence des deux failles et reproduit la première, mais aucun code d’exploitation public n’était identifié. Huntress n’avait observé aucune attaque chez ses clients le 20 octobre.

Une exécution de code à distance notée 9,2/10
Les deux failles sont décrites comme des vulnérabilités d’exécution de code à distance (RCE, remote code execution) : une requête web correctement formée suffirait à exécuter une commande arbitraire sur le serveur visé. Chacune reçoit un score CVSS v4.0 de 9,2/10, ce qui la place dans la catégorie critique. L’équipe PHP s’était réservé le droit de publier plus tôt en cas de nouvelles informations.
« si les détails devenaient publics ou si une exploitation active apparaissait »
Équipe de sécurité de PHP, cité par le Journal du Coin
Quelles versions sont réellement visées ?
Selon l’article, le correctif officiel devait couvrir les branches 8.2 et supérieures, seules encore maintenues par PHP. Les serveurs sous PHP 8.1 ou 7.4 ne devaient donc recevoir aucun correctif amont : ils dépendraient d’un backport de leur hébergeur ou d’une migration le jour même.
| Branche PHP | Statut annoncé | Action recommandée |
|---|---|---|
| 8.2 et supérieures | Correctif officiel prévu | Appliquer la mise à jour du 21 octobre |
| 8.1 | Pas de correctif amont attendu | Backport hébergeur ou migration |
| 7.4 | Pas de correctif amont attendu | Backport hébergeur ou migration |
| 5.4 à 5.6 | Revendiquée par Sansec, non confirmée officiellement | Vérifier auprès de l’éditeur et isoler |
Portée : la revendication de Sansec face au périmètre officiel
Sansec affirme que les failles touchent tous les serveurs web exécutant PHP 5.4 ou plus récent, un périmètre bien plus large que celui du correctif officiel. Le changelog de PHP 5 consulté atteste que cette branche a reçu des correctifs de sécurité par le passé, notamment CVE-2016-5114 (fuite mémoire et dépassement de tampon dans fpm_log.c) et CVE-2016-1903 (lecture mémoire liée à un index de tableau hors limites dans gdImageRotateInterpolated). Il recense aussi une désérialisation WDDX avec use-after-free, une confusion de type dans XMLRPC et une gestion stricte des sessions contre la fixation de session.
Ce document ne contient cependant aucune entrée concernant CVE-2026-109618, CVE-2026-109619 ou PHP2Shell. Il illustre la longue maintenance de la branche sans corroborer l’incident de 2026. Restent non documentés : le nombre de serveurs touchés, le volume de requêtes, les pays concernés, l’identité des attaquants et les détails techniques des exploits.
Un risque opérationnel pour les paiements crypto, sans cible avérée
PHP alimente WordPress, WooCommerce, Magento, de nombreux back-offices ainsi que des pages de paiement et d’espaces clients. La source indique que « presque toujours » les boutiques acceptant l’USDC reposent sur WooCommerce, Magento ou Shopware, et que les sites d’exchanges et les systèmes de support sont fréquemment basés sur PHP. Il s’agit d’une surface d’exposition, non d’une campagne ciblée : rien n’indique que ces failles ont été utilisées contre des services crypto en particulier.
Les conséquences décrites restent hypothétiques. Après accès au serveur, un attaquant pourrait remplacer une adresse de dépôt affichée au paiement, injecter un faux formulaire de connexion ou installer un keylogger. Les groupes Magecart suivis par Sansec pourraient afficher une fausse page sur le domaine légitime, avec un certificat de sécurité authentique. Pour les interfaces DeFi, le danger principal serait la redirection des utilisateurs.
Mesures recommandées
- Inventorier toutes les installations PHP, y compris celles intégrées dans des logiciels tiers.
- Déconnecter d’internet les systèmes utilisant une version en fin de vie.
- Réserver la fenêtre 16h-17h et préparer la commande de mise à jour à l’avance.
- Surveiller les processus php-fpm ou apache2 qui lanceraient soudainement un shell ou curl.
Le CERT-EU formule des recommandations similaires dans son avis 2026-018, publié le lundi soir : retirer du réseau public les applications exposées si la correction ne peut être appliquée à temps. Un pare-feu applicatif (WAF) n’est pas jugé suffisant, car l’attaque viserait PHP lui-même, en amont du code du site. Aucun indicateur de compromission n’était encore publié.
À titre de comparaison, Log4Shell (décembre 2021) avait provoqué, selon l’article, des centaines de milliers de tentatives en 72 heures. Ici, les défenseurs connaissaient à l’avance l’heure du correctif. Aucune réaction de marché chiffrée (cours, volumes, impact sur les cryptoactifs ou pertes) n’est rapportée.
Des failles distinctes à ne pas confondre
CVE-2024-4577, une injection d’arguments affectant PHP sous Windows, a été massivement exploitée après sa divulgation en juin 2024. GreyNoise a relevé des tentatives provenant de 1 089 adresses IP uniques en janvier, et plus de 40 % des adresses attaquantes des 30 jours précédents étaient basées en Allemagne et en Chine.
« Les données de GreyNoise confirment que l’exploitation de CVE-2024-4577 dépasse largement les premiers rapports. »
GreyNoise, cité par Cybersecurity Dive
Cisco Talos a par ailleurs documenté un acteur inconnu utilisant des plug-ins TaoWu pour Cobalt Strike contre des organisations japonaises des télécoms, de la technologie et de l’éducation. Talos juge avec une confiance modérée que l’objectif dépasse le vol d’identifiants, des mécanismes de persistance et une élévation de privilèges au niveau SYSTEM ayant été observés.
Deux avis 2026 concernent aussi PHP. CVE-2026-12184 est un déni de service distant dans le wrapper de flux HTTP lorsque la négociation TLS échoue, pouvant faire tomber PHP-FPM ; il est corrigé dans les versions 8.3.32, 8.4.21 et 8.5.6. CVE-2026-14355 est une erreur de calcul de taille de tampon dans AES-WRAP-PAD de l’extension OpenSSL, avec une complexité d’attaque élevée et sans authentification requise ; il est corrigé dans les versions 8.2.32, 8.3.32, 8.4.23 et 8.5.8.
Sur le plan stratégique, New Relic estime que les applications PHP représentent plus de 77 % des applications web. TuxCare rappelle que PHP reste parmi les projets les plus ciblés par nombre de CVE, avec des branches en fin de vie allant de 5.2 à 8.0 encore en circulation.
Ces informations sont présentées séparément de la campagne d’octobre 2026, dont les failles RCE restent le sujet central de cet article.
Perspective et scénarios à surveiller
Trois scénarios restent ouverts. Le plus probable à ce stade : les mises à jour sont appliquées rapidement sur les branches supportées et les incidents restent concentrés sur les serveurs non corrigés. Un deuxième scénario verrait une exploitation étendue toucher les déploiements en 7.4 et 8.1, dépourvus de correctif amont, obligeant les hébergeurs à multiplier les backports. Un troisième supposerait la compromission confirmée de pages de paiement ou d’interfaces DeFi ; rien de tel n’est documenté aujourd’hui.
Les informations à suivre sont les versions corrigées précisées par l’avis officiel de PHP, les indicateurs de compromission publiés et des données quantifiées sur les serveurs touchés. Jusqu’à leur publication, la chronologie et le périmètre annoncés doivent être considérés comme partiellement vérifiés.
Sources
- Journal du Coin, failles critiques PHP et PHP2Shell
- PHP.net, ChangeLog PHP 5
- Cybersecurity Dive, critical PHP vulnerability under widespread cyberattack
- TuxCare, blog PHP vulnerability
- Cybersecurity News, multiple PHP vulnerabilities DoS
- New Relic, PHP vulnerabilities to watch for
Cet article est publié à titre informatif et éducatif. Il ne constitue en aucun cas un conseil en investissement. Faites vos propres recherches (DYOR) avant toute décision.


