Retour à la tendance du jour: Deux failles de PHP permettent de pirater des sites ; certains sont hors ligne par précaution
Classement Poly · tiré de la tendance du jour

Comment mettre à jour PHP sur mon site : 10 plateformes à risque en 2026

La mise à jour de WordPress ne règle pas le problème : WordPress.org indique qu'aucune mise à jour de WordPress n'est prévue. 24 heures après le correctif PHP, 99,1% des hôtes WordPress concernés d'un échantillon Shodan tournaient encore sur un PHP non corrigé.

  • N° 1 : WordPress
  • 10 places

01Liste finale

Les IA de pointe ont chacune dressé leur propre liste de dix, de façon indépendante. Voici un résultat facile à vérifier : chaque place a une raison, une source et la liste des IA qui l'ont retenue.

Ordre : du plus grand au plus faible accord entre les IA.

Une pastille vive signifie que cette IA a mis l'élément dans sa liste. Une pastille terne, qu'elle ne l'a pas fait.

  1. 1

    WordPress

    L'exposition la plus forte. Environ 1 installation sur 3 tourne sous PHP 8.1 ou plus ancien ; les relevés vont de 32,4% à 36,4%. 33 075 hôtes concernés dans un échantillon Shodan, dont seuls 299 ont été corrigés.

    L’ont inclus: Claude, ChatGPT, Grok, Nemotron, Gemini, Kimi, Wenxin.

    Dans leurs listes: Claude: 5 · ChatGPT: 1 · Grok: 1 · Nemotron: 1 · Gemini: 1 · Kimi: 1 · Wenxin: 1

    Ce qu'a noté chaque IA 7
    • Claudeplace 5

      Environ 1 installation WordPress sur 3 déclare PHP 8.1 ou une version plus ancienne, et WordPress.org a indiqué qu'aucune mise à jour de WordPress n'est prévue : la mise à jour de PHP est le correctif.

      Source ↗
    • ChatGPTplace 1

      Le CMS le plus utilisé au monde ne peut pas corriger le moteur PHP par le bouton ordinaire de mise à jour du cœur de WordPress.

      Source ↗
    • Grokplace 1

      Même un site WordPress entièrement corrigé reste exposé tant que l'hébergeur n'a pas mis à niveau le moteur PHP sous-jacent

      Source ↗
    • Nemotronplace 1

      ~60% des sites WordPress tournent sur un PHP en fin de vie selon les statistiques de WP.org, mais un changement de PHP en un clic existe chez la plupart des hébergeurs gérés

    • Geminiplace 1

      Plus de 40 millions de sites mis à jour affichent des coches vertes dans wp-admin tout en tournant discrètement sur des moteurs PHP 7.4 ou 8.0 en fin de vie.

      Source ↗
    • Kimiplace 1

      Deux sites sur cinq dans le monde l'utilisent, et un sur trois déclare encore un PHP en fin de vie ; la version WordPress 7.1.2, pourtant entièrement à jour, figurait sur la liste de démonstration d'exploit du chercheur.

      Source ↗
    • Wenxinplace 1

      Près de 4 sites sur 10 l'utilisent, et pourtant un seul clic dans le tableau de bord peut changer le moteur PHP si l'hébergeur le permet ; mais 18% des installations déclarent encore PHP 7.x ou une version inférieure

    7 IA l’ont placé ici
    Source ↗
  2. 2

    Drupal

    Près de la moitié des sites Drupal tournent déjà sur un cœur en fin de vie (29% rien que sur Drupal 7). Seuls 31 des 3 919 hôtes concernés ont été corrigés au bout d'un jour.

    L’ont inclus: Claude, ChatGPT, Grok, Nemotron, Gemini, Kimi, Wenxin.

    Dans leurs listes: Claude: 3 · ChatGPT: 3 · Grok: 2 · Nemotron: 2 · Gemini: 3 · Kimi: 4 · Wenxin: 2

    Ce qu'a noté chaque IA 7
    • Claudeplace 3

      Wiz a démontré une exécution de code à distance sur la dernière image Drupal : un cœur à jour ne protégeait donc de rien.

      Source ↗
    • ChatGPTplace 3

      Drupal documente une limite stricte : aucune version prise en charge de Drupal ne supporte PHP 7, mais mettre Drupal à jour ne corrige toujours pas PHP lui-même.

      Source ↗
    • Grokplace 2

      Environ la moitié des sites Drupal détectés utilisent déjà des versions majeures en fin de vie, et PHP en dessous est tout aussi hors de portée de la mise à jour de la plateforme

    • Nemotronplace 2

      Drupal 10+ exige PHP 8.1+, mais les sites Drupal 7 (encore ~15% des installations) restent sur PHP 7.4, en fin de vie

      Source ↗
    • Geminiplace 3

      Une fracture profonde existe : les entreprises restées sur Drupal 7 gardent des environnements PHP 7.4, alors que Drupal 10 exige PHP 8.2+.

      Source ↗
    • Kimiplace 4

      Près de la moitié de tous les sites Drupal tournent encore sur un cœur en fin de vie : 29% sur Drupal 7 seul, abandonné depuis janvier 2025 ; leur PHP est donc généralement encore plus ancien.

    • Wenxinplace 2

      La mise à jour peut changer la plateforme mais ne touche pas au moteur PHP : 22% des sites Drupal tournent sur un PHP en fin de vie, parce que l'hébergeur ne l'a jamais mis à niveau

      Source ↗
    7 IA l’ont placé ici
    Source ↗
  3. 3

    Joomla

    Seuls 4 hôtes Joomla concernés sur 646 avaient un PHP corrigé après 24 heures. Joomla.org lui-même est hors ligne, et Joomla 6.1.4, version actuelle, a été exploitée lors d'une démonstration.

    L’ont inclus: Claude, ChatGPT, Grok, Nemotron, Gemini, Kimi, Wenxin.

    Dans leurs listes: Claude: 4 · ChatGPT: 2 · Grok: 3 · Nemotron: 3 · Gemini: 2 · Kimi: 2 · Wenxin: 3

    Ce qu'a noté chaque IA 7
    • Claudeplace 4

      Seuls 4 des 1 099 hôtes Joomla de l'échantillon OX affichaient un PHP corrigé après un jour.

      Source ↗
    • ChatGPTplace 2

      Un tableau de bord Joomla à jour peut coexister avec un moteur PHP obsolète en dessous.

    • Grokplace 3

      Empreinte plus réduite que WordPress, mais la même barrière PHP contrôlée par l'hébergeur pour tout site qui veut les correctifs d'octobre 2026

      Source ↗
    • Nemotronplace 3

      Joomla 5.x exige PHP 8.2+ ; 4.x sur 8.1 ; beaucoup de sites 3.x restent sur PHP 7.4 sans chemin de mise à niveau du cœur

      Source ↗
    • Geminiplace 2

      Près de la moitié des déploiements en production exécutent un PHP ancien, car les extensions cassent dès le passage à PHP 8.2 ou 8.3.

    • Kimiplace 2

      82% des sites Joomla tournent encore sur la version 3, un logiciel qui fonctionne très bien sur un PHP de 2012, et le site du projet Joomla lui-même a été mis hors ligne à cause de cette faille.

      Source ↗
    • Wenxinplace 3

      Mise à jour en un clic pour Joomla lui-même, aucun contrôle sur PHP : une installation Joomla sur cinq tourne encore sur PHP 7.4

      Source ↗
    7 IA l’ont placé ici
    Source ↗
  4. 4

    Magento / Adobe Commerce

    Aucun des 48 hôtes Magento concernés de l'échantillon n'était corrigé au bout d'un jour. Sansec : « vous ne pouvez pas corriger PHP2Shell depuis le code de votre boutique. »

    L’ont inclus: Claude, ChatGPT, Grok, Nemotron, Gemini, Kimi, Wenxin.

    Dans leurs listes: Claude: 1 · ChatGPT: 4 · Grok: 4 · Nemotron: 4 · Gemini: 4 · Kimi: 3 · Wenxin: 4

    Ce qu'a noté chaque IA 7
    • Claudeplace 1

      Dans l'échantillon OX, 48 hôtes Magento visibles étaient touchés, et aucun n'avait été corrigé après 24 heures. Les mises à jour propres à une boutique ne touchent jamais à PHP.

      Source ↗
    • ChatGPTplace 4

      Un correctif de l'environnement d'exécution peut devenir une mise à niveau coordonnée de la boutique lorsque la version de PHP et la pile de dépendances prises en charge doivent évoluer ensemble.

      Source ↗
    • Grokplace 4

      Les installations e-commerce à jour sur la plateforme peuvent encore reposer sur un PHP non corrigé tant que le serveur ou l'hébergeur ne change pas l'environnement

      Source ↗
    • Nemotronplace 4

      Magento 2.4.7+ exige PHP 8.2+ ; les 2.4.x plus anciens sur PHP 8.1 arrivent bientôt en fin de vie ; Cloud met PHP à jour automatiquement

      Source ↗
    • Geminiplace 4

      Des contraintes de dépendances compilées strictes signifient que la mise à niveau du moteur PHP impose des reconstructions, ce qui fige les boutiques e-commerce sur des environnements retirés.

      Source ↗
    • Kimiplace 3

      Les boutiques Magento 1 n'ont plus de support de sécurité officiel depuis juin 2020 : pour elles, ce correctif d'urgence n'existe tout simplement pas, seule une mise à niveau du serveur compte.

      Source ↗
    • Wenxinplace 4

      Plateforme de niveau entreprise, mais la mise à jour ne corrige que le code Magento ; passer à PHP plus récent signifie appeler l'hébergeur : 30% des boutiques tournent encore sur PHP 7.4

      Source ↗
    7 IA l’ont placé ici
    Source ↗
  5. 5

    Laravel et applications PHP sur mesure

    Aucun tableau de bord n'alerte qui que ce soit, et aucun outil de framework ne peut modifier PHP. 98,27% des hôtes Laravel visibles étaient encore non corrigés au bout d'un jour (36 hôtes concernés sur 2 040 corrigés).

    L’ont inclus: Claude, ChatGPT, Grok, Nemotron. Ne l’ont pas inclus: Gemini, Kimi, Wenxin.

    Dans leurs listes: Claude: 6 · ChatGPT: 5 · Grok: 5 · Nemotron: 6

    Ce qu'a noté chaque IA 4
    • Claudeplace 6

      98,27% des hôtes Laravel visibles dans l'échantillon OX n'étaient toujours pas corrigés, et le framework n'a aucun outil qui modifie le PHP du serveur.

      Source ↗
    • ChatGPTplace 5

      Il n'existe peut-être aucun tableau de bord de CMS pour avertir le propriétaire que l'environnement réel reste vulnérable.

    • Grokplace 5

      Le code applicatif peut être à jour alors que le processus PHP sous-jacent reste sur une branche vulnérable, jusqu'à ce qu'un administrateur redémarre avec un nouveau binaire

      Source ↗
    • Nemotronplace 6

      Laravel 11.x exige PHP 8.2+ ; beaucoup d'applications 10.x sont sur PHP 8.1 ; aucun outil de mise à jour automatique pour PHP

      Source ↗
    4 IA l’ont placé ici
    Source ↗
  6. 6

    OpenCart et autres boutiques PHP anciennes

    Les anciennes boutiques sous PHP 5.6 à 8.1 ne reçoivent plus de version officielle de PHP. Leur correctif est un recueil de correctifs communautaires, pas un simple clic.

    L’ont inclus: Claude, Nemotron, Gemini. Ne l’ont pas inclus: ChatGPT, Grok, Kimi, Wenxin.

    Dans leurs listes: Claude: 2 · Nemotron: 9 · Gemini: 5

    Ce qu'a noté chaque IA 3
    • Claudeplace 2

      Le correctif pour ces sites est une collection de correctifs maintenue par la communauté, pour PHP 5.6 à 8.1, et non une mise à jour en un clic.

      Source ↗
    • Nemotronplace 9

      OpenCart 4.x exige PHP 8.1+ ; la 3.x domine sur PHP 7.4/8.0 ; l'écosystème d'extensions est en retard

      Source ↗
    • Geminiplace 5

      Très présent sur l'hébergement mutualisé bon marché et non géré, où les marchands ignorent souvent que leur interpréteur PHP a cinq ans de retard.

      Source ↗
    3 IA l’ont placé ici
    Source ↗
  7. 7

    cPanel, Plesk et phpMyAdmin

    0 hôte cPanel concerné sur 587 n'était corrigé à 24 heures. Les sources divergent sur la couverture du correctif : retour à PHP 5.2 (CloudLinux) ou rien en dessous de 7.3.

    L’ont inclus: Claude, ChatGPT, Kimi. Ne l’ont pas inclus: Grok, Nemotron, Gemini, Wenxin.

    Dans leurs listes: Claude: 9 · ChatGPT: voir la liste · Kimi: 10

    Ce qu'a noté chaque IA 3
    • Claudeplace 9

      Plesk a livré des versions corrigées de PHP 8.2 à 8.5, mais le propriétaire du site doit encore les appliquer.

      Source ↗
    • ChatGPT

      Nommé autrement dans sa propre liste : ouvrez la liste complète.

      voir la liste
    • Kimiplace 10

      cPanel a livré des correctifs pour PHP 7.4 à 8.1, et rien du tout pour PHP 7.3 et les versions antérieures, ce qui laisse une vaste queue d'installations de panneaux de contrôle figées.

      Source ↗
    3 IA l’ont placé ici
    Source ↗
  8. 8

    WooCommerce

    Environ 1 site WordPress sur 5 est une boutique WooCommerce. Sa documentation exige désormais PHP 8.3+, mais les boutiques sont touchées « même lorsque leur propre code est sain ».

    L’ont inclus: Grok, Kimi. Ne l’ont pas inclus: Claude, ChatGPT, Nemotron, Gemini, Wenxin.

    Dans leurs listes: Grok: 10 · Kimi: 5

    Ce qu'a noté chaque IA 2
    • Grokplace 10

      L'extension de boutique peut être à jour alors que la version de PHP indiquée dans Site Health reste vulnérable tant que l'hébergeur n'agit pas

      Source ↗
    • Kimiplace 5

      Un site WordPress sur cinq est une boutique, et WooCommerce exige désormais PHP 8.3+ dans sa propre documentation, alors que la plupart des boutiques restent sur le PHP choisi par leur hébergeur WordPress.

      Source ↗
    2 IA l’ont placé ici
    Source ↗
  9. 9

    MediaWiki

    Le logiciel derrière Wikipédia : MediaWiki 1.46.2 figurait sur la liste des démonstrations d'exploitation, et Wikimedia a désactivé son propre Phabricator quelques heures avant le correctif.

    L’ont inclus: Grok, Kimi. Ne l’ont pas inclus: Claude, ChatGPT, Nemotron, Gemini, Wenxin.

    Dans leurs listes: Grok: 7 · Kimi: 7

    Ce qu'a noté chaque IA 2
    • Grokplace 7

      Déploiements PHP très en vue qui exigent toujours que l'équipe d'infrastructure, et non le logiciel du wiki, applique le correctif du moteur

      Source ↗
    • Kimiplace 7

      Le logiciel qui fait tourner Wikipédia utilise le même moteur : Wikimedia a désactivé son propre Phabricator quelques heures avant la publication du correctif.

      Source ↗
    2 IA l’ont placé ici
    Source ↗
  10. 10

    Nextcloud (auto-hébergé)

    Son outil de mise à jour en un clic met à jour l'application, pas PHP. Nextcloud 35.0.1, version actuelle, a été exploitée lors de la démonstration. Une seule IA l'a citée, sans chiffre d'exposition.

    L’ont inclus: Kimi. Ne l’ont pas inclus: Claude, ChatGPT, Grok, Nemotron, Gemini, Wenxin.

    Dans leurs listes: Kimi: 8

    Ce qu'a noté chaque IA 1
    • Kimiplace 8

      Le programme de mise à jour en un clic de Nextcloud met bien l'application à jour, mais il ne peut pas toucher PHP en dessous, et Nextcloud 35.0.1 figurait sur la liste de démonstration d'exploit.

      Source ↗
    1 IA l’ont placé ici
    Source ↗

Plus sur le trio de tête ↓

02Plus sur le trio de tête

Le classement est ci-dessus. Voici plus sur les trois premières places : ce qu'elles sont, pourquoi elles sont là et ce qu'il faut savoir.

Les trois sont mesurés sur des échantillons de taille différente : la part encore non corrigée est proche pour tous, alors que le nombre de sites exposés varie beaucoup.

1WordPress

N° 1 — WordPress. Dans les listes de 7 IA sur 7 ; place médiane : 1. C'est le plus grand réservoir de sites exposés, et la mise à jour de WordPress lui-même ne corrige pas le moteur PHP sous-jacent.

Le saviez-vous ?

  • Les versions de WordPress portent le nom de musiciens de jazz. La version 1.0, sortie le 3 janvier 2004, s'appelait « Miles ». La toute première version, 0.7, est sortie le 27 mai 2003.

    Source ↗
Ce que c'est
La plateforme de site la plus utilisée, qui tourne sur PHP.
Son atout
Elle compte beaucoup plus de serveurs touchés que Drupal ou Joomla.
À qui c'est utile
Utile pour tout titulaire d'un site WordPress, car sa propre mise à jour ne corrigera pas ce problème.
  • Serveurs corrigés après 24 heures299 sur 33 075 corrigés

Wikipédia · Wikidata

Pourquoi il est là

  • Lors d'un scan en 24 heures, 33 075 des 41 882 sites WordPress affichant leur version de PHP tournaient sur une version touchée. Seuls 299 en avaient une version corrigée. C'est le plus grand réservoir des trois plateformes.

    Source ↗

  • Selon les chiffres de WordPress sur PHP en janvier 2026 : 22,20% des sites surveillés tournaient sous PHP 7.4, 15,39% sous 8.1 et 5,69% sous 8.0. Au total, cela fait environ 43%, sans compter les versions plus anciennes.

    Source ↗
Histoire

  • En 2003, Matt Mullenweg a lancé WordPress comme version dérivée de b2, un outil de blog. Son créateur avait cessé de le maintenir, alors Mullenweg a repris le code libre et créé une nouvelle version.

    Source ↗
À garder en tête

  • WordPress fonctionne toujours avec PHP 7.4 et plus, mais sa page officielle des prérequis indique que cette version est en fin de vie et peut exposer votre site à des failles de sécurité. Elle recommande PHP 8.3 ou plus récent.

    Source ↗

  • Un changement de version de PHP imposé par l'hébergeur peut casser d'anciens thèmes ou extensions. Sur un forum, un utilisateur a vu l'espace d'administration de son site cesser de fonctionner après une mise à jour de PHP, et l'hébergeur est ensuite revenu à une version plus ancienne.

    Source ↗
Ce que disent les gens

  • While trying to fix a relatively minor Google Map API problem, I have gone down a rabbit hole that has taken my site offline. — justinfarquhar

    Source ↗
Pour aller plus loin

  • Ouvrez d'abord la page des prérequis et cherchez la ligne PHP. Elle indique la version de PHP que WordPress recommande à votre hébergeur. Vérifiez ensuite, dans votre espace d'hébergement, la version de PHP que votre site utilise.

    Source ↗

Vidéo: WordPress.org VS WordPress.com: The Confusing Differences Explained! (en anglais) · Darrel Wilson

Comparer le trio de tête ↓

2Drupal

N° 2 — Drupal. Dans les listes de 7 IA sur 7 ; place médiane : 3. Près de la moitié des sites Drupal tournent déjà sur un core en fin de vie, et presque aucun des serveurs touchés n'a été corrigé au bout d'un jour.

Le saviez-vous ?

  • Le nom de Drupal vient d'une faute de frappe. Dries Buytaert voulait écrire « dorp.org » (« village » en néerlandais) mais a tapé « drop ». Le nom Drupal vient du mot néerlandais « druppel », qui signifie goutte.

    Source ↗
Ce que c'est
Une plateforme de site souvent utilisée pour les sites plus grands et sur mesure.
Son atout
De nombreux sites restent sur un core qui ne reçoit plus de correctifs de sécurité.
À qui c'est utile
Utile pour les propriétaires de Drupal 7 encore sur cette version, qui doivent passer à la suite.
  • Serveurs corrigés après 24 heures31 sur 3 919 corrigés

Wikipédia · Wikidata

Pourquoi il est là

  • Sur 5 078 serveurs Drupal affichant leur version de PHP, 3 919 étaient touchés après 24 heures. Seuls 31 avaient été corrigés, donc 99,22% des serveurs touchés restaient ouverts.

    Source ↗

  • W3Techs indique que Drupal 7 équipe 29,0% des sites Drupal au 22 octobre 2026. C'est plus que Drupal 10, à 28,7%, alors que Drupal 7 ne reçoit plus de correctifs de sécurité.

    Source ↗
Histoire

  • Vers 2000, Dries Buytaert et ses amis, dans une résidence universitaire, partageaient un seul modem ADSL entre huit étudiants. Ils ont créé un petit site pour échanger, qui est devenu Drupal.

    Source ↗
À garder en tête

  • Selon Tag1, l'outil de migration du core ne transfère pas Views, les listes et mises en page enregistrées qui affichent le contenu. Ces éléments demandent un module séparé ou doivent être refaits à la main.

    Source ↗
Comparer le trio de tête ↓

3Joomla

N° 3 — Joomla. Dans les listes de 7 IA sur 7 ; place médiane : 3. Presque aucun serveur Joomla touché n'a été corrigé, et même la version actuelle de Joomla a été exploitée lors d'une démonstration.

Le saviez-vous ?

  • Joomla est une graphie du mot swahili « Jumla », qui signifie « tous ensemble » ou « dans son ensemble ». L'équipe fondatrice l'a choisi, et des professionnels de la marque et du marketing ont examiné le nom avant son adoption.

    Source ↗
Ce que c'est
Une plateforme de site issue de l'ancien Mambo.
Son atout
Elle avait la plus forte proportion de serveurs touchés encore ouverts au bout d'un jour.
À qui c'est utile
Utile pour les propriétaires de Joomla, car mettre Joomla à jour seul ne ferme pas la faille.
  • Serveurs corrigés après 24 heures4 sur 646 corrigés

Wikidata

Pourquoi il est là

  • Sur 1 099 serveurs Joomla affichant leur version de PHP, 646 étaient touchés et seuls 4 avaient été corrigés après 24 heures. Avec 99,38% encore touchés, Joomla fait pire que WordPress (99,1%) et Drupal (99,22%).

    Source ↗

  • Des chercheurs de Wiz ont montré une exécution de code à distance sans authentification sur l'image de conteneur la plus récente de Joomla, notée CVSS 9,2. La faille est dans PHP lui-même, donc mettre Joomla à jour seul ne la corrige pas.

    Source ↗
Histoire

  • En 2005, les développeurs principaux de Mambo ont quitté le projet après une querelle de pouvoir. Miro, propriétaire du nom Mambo, a créé une fondation que les développeurs jugeaient trop puissante. Ils ont alors lancé Joomla.

    Source ↗
À garder en tête

  • Joomla 3 n'est plus du tout pris en charge. Le manuel officiel indique que le support a pris fin le 17 août 2023 et l'Extended LTS le 17 février 2025. Les sites restés sur cette version ne reçoivent plus aucun correctif.

    Source ↗
Ce que disent les gens

  • K2 extension do not work inside J4, and will not work (!) becuase of K2 developers. — Paul Frankowski

    Source ↗
Pour aller plus loin

  • Lisez d'abord la ligne PHP. Joomla 6 exige au minimum PHP 8.3.0, et 8.4 est recommandé. Comparez avec la version de PHP que votre hébergeur donne à votre site.

    Source ↗
Comparer le trio de tête ↓

Le trio de tête côte à côte

WordPressDrupalJoomla
Dans les listes des IA7 / 77 / 77 / 7
Serveurs corrigés après 24 heures299 sur 33 075 corrigés31 sur 3 919 corrigés4 sur 646 corrigés
Premier pourChatGPT, Grok, Nemotron, Gemini, Kimi, Wenxin——

À nombre d'IA égal, les places sont classées selon leur place moyenne dans les listes des IA.

Autres classements

03Bon à savoir

Ce que les IA ont remarqué en établissant la liste.

24 heures après le correctif, 99,3% des instances PHP mesurables d'un échantillon Shodan restaient non corrigées ; les hôtes corrigés sont passés de 245 à 14 151 sur environ 2M seulement.

Remarqué par:
L’ont inclus: Claude, Grok. Ne l’ont pas inclus: ChatGPT, Nemotron, Gemini, Kimi, Wenxin.
Source ↗

Deux décomptes distincts concordent : environ 7 hôtes PHP exposés sur 10 tournent sur une branche que le projet PHP ne prend plus en charge. Flare 72,7%, Qualys 71%.

Remarqué par:
L’ont inclus: Claude. Ne l’ont pas inclus: ChatGPT, Grok, Nemotron, Gemini, Kimi, Wenxin.
Source ↗

Un tableau de bord vert « à jour » ne prouve rien ici : la faille se situe sous WordPress, les thèmes et les extensions, donc seule une mise à jour de PHP la corrige.

Remarqué par:
L’ont inclus: Claude, ChatGPT, Gemini, Kimi. Ne l’ont pas inclus: Grok, Nemotron, Wenxin.
Source ↗

Les numéros de version induisent en erreur dans les deux sens : les rétroportages de CloudLinux peuvent laisser un hôte corrigé afficher PHP 8.5.11, tandis que les paquets des distributions peuvent conserver une ancienne chaîne de version.

Remarqué par:
L’ont inclus: Claude, Kimi. Ne l’ont pas inclus: ChatGPT, Grok, Nemotron, Gemini, Wenxin.
Source ↗

Les estimations d'exposition varient fortement selon la méthode : de 1,3M hôtes à 2,6M (VulnCheck), 6,29M (Censys) et 22,6M instances « potentiellement vulnérables » (Palo Alto Networks).

Remarqué par:
L’ont inclus: Claude, Grok, Kimi. Ne l’ont pas inclus: ChatGPT, Nemotron, Gemini, Wenxin.
Source ↗

04Les questions que l’on se pose

Comment mettre à jour PHP

Passez à une version corrigée : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, puis redémarrez chaque service qui charge PHP. PHP 8.1 et les versions antérieures ne reçoivent plus de correctif officiel : il faut un rétroportage du fournisseur ou une mise à niveau.

Source ↗
Comment mettre à jour PHP sur mon site

Sur un hébergement mutualisé ou géré, choisissez une version corrigée de PHP dans le panneau de configuration de votre hébergeur, ou demandez-la au support. Mettre à jour WordPress, Drupal, Joomla ou Magento ne change pas le moteur PHP.

Source ↗
Comment mettre à jour PHP sous Windows

Téléchargez une version Windows corrigée (8.5.12, 8.4.27, 8.3.36 ou 8.2.35) sur windows.php.net, remplacez l'ancien dossier PHP en conservant php.ini, puis redémarrez IIS, Apache ou PHP-CGI.

Source ↗
Comment mettre à jour la version de PHP

Vérifiez votre version avec php -v et passez à 8.2.35 ou plus récente. PHP 8.2 lui-même arrive en fin de vie le 31 décembre 2026 : visez 8.3, 8.4 ou 8.5 et testez d'abord en préproduction.

Source ↗

05Notre méthode

En mots simples, sans formules.

1La question

Top 10 des plateformes de sites web où un site à jour peut encore tourner sur un PHP vulnérable

2Pourquoi ce sujet

Il met en regard les enquêtes d'usage et les analyses d'Internet, et précise qui contrôle réellement le correctif, pour que le propriétaire d'un site voie l'écart entre « mon site est à jour » et « mon serveur est en sécurité ». Aucun tableau unique ne montre cet écart.

3Champ d'application

Mondial ; WordPress, Drupal, Joomla, Magento et autres logiciels de sites web qui tournent sur PHP

4Ce que nous avons regardé

  • Part des installations de chaque plateforme qui tournent sur une version de PHP en fin de vie
  • Part de ces installations que les scanners peuvent atteindre depuis Internet
  • Part de celles qui exécutent PHP de façon vulnérable, par exemple en mode CGI
  • Le programme de mise à jour de la plateforme peut-il changer le moteur PHP, ou seulement la plateforme elle-même
  • Vitesse à laquelle le correctif atteint un site type : un clic, l'hébergeur, ou une mise à niveau manuelle du serveur
  • WordPress.org Statistics — Part des installations WordPress actives selon la version de PHP qu'elles déclarent. Les relevés du graphique en direct diffèrent : 32,4% à 36,4% sous PHP 8.1 ou plus ancien
  • OX Security (échantillon Shodan, 24 heures après le correctif) — Hôtes trouvés, concernés et corrigés pour chaque technologie. C'est un échantillon, pas tout Internet
  • W3Techs / TheDropTimes — Part des versions de PHP sur le web, et sites Drupal sur des versions majeures en fin de vie

5Qui a classé

Les IA de pointe : Claude, ChatGPT, Grok, Nemotron, Gemini, Kimi, Wenxin. Chacune a établi seule sa liste de dix et cité une source pour chaque place.

6Comment les places ont été fixées

Un même élément formulé différemment par différentes IA a été compté une seule fois. Plus les IA sont nombreuses à l'avoir mis dans leur liste, et plus elles l'ont placé haut, plus sa place est élevée. « Accord des IA » indique combien d'IA l'avaient dans leur propre liste. Les sources sont uniquement celles trouvées par les IA ; rien n'a été ajouté à la main.

06La liste de chaque IA

🇺🇸 Claude10 places · 4 notes

La même question, à laquelle Claude a répondu seul. La liste finale ci-dessus combine toutes les IA.

  1. 1
    Magento / Adobe Commerce (auto-hébergé)

    Dans l'échantillon OX, 48 hôtes Magento visibles étaient touchés, et aucun n'avait été corrigé après 24 heures. Les mises à jour propres à une boutique ne touchent jamais à PHP.

    Source ↗
  2. 2
    OpenCart et autres boutiques PHP anciennes

    Le correctif pour ces sites est une collection de correctifs maintenue par la communauté, pour PHP 5.6 à 8.1, et non une mise à jour en un clic.

    Source ↗
  3. 3
    Drupal (auto-hébergé)

    Wiz a démontré une exécution de code à distance sur la dernière image Drupal : un cœur à jour ne protégeait donc de rien.

    Source ↗
  4. 4
    Joomla (auto-hébergé)

    Seuls 4 des 1 099 hôtes Joomla de l'échantillon OX affichaient un PHP corrigé après un jour.

    Source ↗
  5. 5
    WordPress en hébergement mutualisé ou sur un VPS géré soi-même

    Environ 1 installation WordPress sur 3 déclare PHP 8.1 ou une version plus ancienne, et WordPress.org a indiqué qu'aucune mise à jour de WordPress n'est prévue : la mise à jour de PHP est le correctif.

    Source ↗
  6. 6
    Laravel et applications PHP sur mesure sur des serveurs loués

    98,27% des hôtes Laravel visibles dans l'échantillon OX n'étaient toujours pas corrigés, et le framework n'a aucun outil qui modifie le PHP du serveur.

    Source ↗
  7. 7
    Images WordPress / Drupal / Joomla basées sur Docker

    Une reconstruction corrige le problème, mais l'image officielle php ne reçoit aucun correctif pour la version 8.1 ou antérieure.

    Source ↗
  8. 8
    Sites en hébergement mutualisé cPanel / CloudLinux

    Les paquets PHP du panneau de contrôle ont été corrigés jusqu'à PHP 5.2, mais un site corrigé peut encore afficher un ancien numéro de version.

    Source ↗
  9. 9
    Sites gérés avec Plesk (VPS et hébergeurs)

    Plesk a livré des versions corrigées de PHP 8.2 à 8.5, mais le propriétaire du site doit encore les appliquer.

    Source ↗
  10. 10
    Hébergement WordPress géré (Pantheon, Pressable, Kinsta, WP Engine)

    Pantheon et Pressable étaient déjà entièrement corrigés dès le 22 octobre. WP Engine et Flywheel ont placé une protection CDN devant leurs sites pendant le déploiement de leurs mises à jour.

    Source ↗

Ce que Claude a remarqué

L'échantillon Shodan d'OX Security montre que 99,3% des instances PHP mesurables restaient non corrigées 24 heures après le correctif. Le nombre d'instances corrigées est passé de 245 à 14 151 sur environ 2 millions.

Source ↗

Deux mesures distinctes concordent : environ 7 PHP exposés sur 10 fonctionnent sur une branche que le projet PHP ne prend plus en charge. Flare : 72,7% des enregistrements de service ; Qualys : 71% des installations.

Source ↗

Un tableau de bord WordPress à jour donne une fausse impression de sécurité. Codeable indique que WordPress.org a confirmé qu'aucune mise à jour de WordPress n'est requise ni prévue, car la faille se situe sous WordPress, les thèmes et les extensions.

Source ↗

Une bannière peut induire en erreur dans les deux sens. Les correctifs rétroportés de CloudLinux peuvent laisser un hôte corrigé afficher PHP 8.5.11, tandis que les paquets Ubuntu ou Debian peuvent conserver l'ancienne chaîne de version.

Source ↗
🇺🇸 ChatGPT10 places · 3 notes

La même question, à laquelle ChatGPT a répondu seul. La liste finale ci-dessus combine toutes les IA.

  1. 1
    Sites WordPress — mise à jour de sécurité de PHP, 2026

    Le CMS le plus utilisé au monde ne peut pas corriger le moteur PHP par le bouton ordinaire de mise à jour du cœur de WordPress.

    Source ↗
  2. 2
    Sites Joomla — mise à jour de sécurité de PHP, 2026

    Un tableau de bord Joomla à jour peut coexister avec un moteur PHP obsolète en dessous.

  3. 3
    Sites Drupal — mise à jour de sécurité de PHP, 2026

    Drupal documente une limite stricte : aucune version prise en charge de Drupal ne supporte PHP 7, mais mettre Drupal à jour ne corrige toujours pas PHP lui-même.

    Source ↗
  4. 4
    Adobe Commerce et Magento Open Source — mise à jour de sécurité de PHP, 2026

    Un correctif de l'environnement d'exécution peut devenir une mise à niveau coordonnée de la boutique lorsque la version de PHP et la pile de dépendances prises en charge doivent évoluer ensemble.

    Source ↗
  5. 5
    Sites PHP sur mesure — mise à jour de sécurité de PHP, 2026

    Il n'existe peut-être aucun tableau de bord de CMS pour avertir le propriétaire que l'environnement réel reste vulnérable.

  6. 6
    Anciennes applications PHP — mise à jour de sécurité de PHP, 2026

    PHP 5 et PHP 7 représentaient ensemble 34,7% des sites PHP détectés dans l'instantané W3Techs du 19 octobre, bien que ce ne soit pas la même chose que la part vulnérable à ces CVE.

    Source ↗
  7. 7
    Applications PHP en hébergement mutualisé — mise à jour de sécurité de PHP, 2026

    Un seul environnement d'exécution au niveau de l'hébergeur peut être le point faible de sécurité de nombreux sites clients gérés séparément.

    Source ↗
  8. 8
    Sites PHP sur hébergement cloud géré — mise à jour de sécurité de PHP, 2026

    L'hébergement géré peut raccourcir le chemin vers un correctif, mais seulement si le fournisseur met à jour le véritable environnement d'exécution et vérifie le service déployé.

    Source ↗
  9. 9
    Applications PHP intégrées à des appareils et à des produits tiers — mise à jour de sécurité de PHP, 2026

    Un propriétaire de site peut même ignorer qu'un produit acheté contient l'environnement PHP qu'il faut mettre à jour.

    Source ↗
  10. 10
    Sites PHP à déploiement automatisé sur serveurs — mise à jour de sécurité de PHP, 2026

    L'automatisation peut transformer un correctif d'urgence en déploiement routinier, mais un pipeline qui ne met à jour que les fichiers d'application laisse l'environnement d'exécution intact.

    Source ↗

Ce que ChatGPT a remarqué

PHP représentait 69,7% des sites dont le langage côté serveur est identifié, selon la comparaison W3Techs du 13 octobre. Cette ampleur fait d'une faille de l'environnement d'exécution un problème pour tout l'écosystème, et non pour un seul CMS.

Source ↗

Le 19 octobre 2026, 27,0% des sites PHP détectés utilisaient PHP 7 et 7,7% utilisaient PHP 5. C'est un avertissement fort sur la maintenance des versions anciennes, mais aucun de ces pourcentages ne mesure directement l'exposition aux deux CVE nouvellement divulguées.

Source ↗

La mise à jour d'un CMS et celle de l'environnement PHP sont deux opérations distinctes. WordPress place explicitement le choix de la version PHP au niveau du serveur ou de l'hébergeur, ce qui explique qu'un tableau de bord en apparence à jour puisse cacher un moteur non corrigé.

Source ↗
🇺🇸 Grok10 places · 3 notes

La même question, à laquelle Grok a répondu seul. La liste finale ci-dessus combine toutes les IA.

  1. 1
    WordPress

    Même un site WordPress entièrement corrigé reste exposé tant que l'hébergeur n'a pas mis à niveau le moteur PHP sous-jacent

    Source ↗
  2. 2
    Drupal

    Environ la moitié des sites Drupal détectés utilisent déjà des versions majeures en fin de vie, et PHP en dessous est tout aussi hors de portée de la mise à jour de la plateforme

  3. 3
    Joomla

    Empreinte plus réduite que WordPress, mais la même barrière PHP contrôlée par l'hébergeur pour tout site qui veut les correctifs d'octobre 2026

    Source ↗
  4. 4
    Magento / Adobe Commerce

    Les installations e-commerce à jour sur la plateforme peuvent encore reposer sur un PHP non corrigé tant que le serveur ou l'hébergeur ne change pas l'environnement

    Source ↗
  5. 5
    Laravel (et autres frameworks PHP similaires)

    Le code applicatif peut être à jour alors que le processus PHP sous-jacent reste sur une branche vulnérable, jusqu'à ce qu'un administrateur redémarre avec un nouveau binaire

    Source ↗
  6. 6
    PrestaShop

    Logiciel de boutique open source dont les versions de sécurité ne touchent pas le moteur PHP qui sert réellement les pages

    Source ↗
  7. 7
    MediaWiki / sites de la famille Wikipédia

    Déploiements PHP très en vue qui exigent toujours que l'équipe d'infrastructure, et non le logiciel du wiki, applique le correctif du moteur

    Source ↗
  8. 8
    phpBB et autres forums PHP

    Les mises à jour du logiciel de forum laissent l'interpréteur intact ; ce sont les hébergements mutualisés qui décident quand le PHP vulnérable disparaît

    Source ↗
  9. 9
    Applications PHP sur mesure en hébergement mutualisé

    Aucun outil de mise à jour de la plateforme ; le seul levier du propriétaire est le sélecteur de PHP de l'hébergeur ou une demande au support

    Source ↗
  10. 10
    Boutiques WooCommerce sous WordPress

    L'extension de boutique peut être à jour alors que la version de PHP indiquée dans Site Health reste vulnérable tant que l'hébergeur n'agit pas

    Source ↗

Ce que Grok a remarqué

PHP fait tourner 69,3% des sites dont le langage côté serveur est connu, or la seule solution complète aux RCE d'octobre 2026 est une mise à niveau de l'environnement, que presque aucun CMS ne peut effectuer lui-même.

Source ↗

Les données de WordPress.org montrent encore 16,24% des installations actives sur PHP 7.4 et 10,68% sur PHP 8.1, deux versions hors des branches ayant reçu des versions officielles corrigées.

Source ↗

Des hébergeurs comme GoDaddy ont indiqué avoir corrigé leurs parcs PHP gérés en quelques heures, mais tout site fixé sur une ancienne branche ou sur un serveur autogéré est resté exposé jusqu'à une modification manuelle.

Source ↗
🇺🇸 Nemotron10 places · 1 notes

La même question, à laquelle Nemotron a répondu seul. La liste finale ci-dessus combine toutes les IA.

  1. 1
    WordPress

    ~60% des sites WordPress tournent sur un PHP en fin de vie selon les statistiques de WP.org, mais un changement de PHP en un clic existe chez la plupart des hébergeurs gérés

  2. 2
    Drupal

    Drupal 10+ exige PHP 8.1+, mais les sites Drupal 7 (encore ~15% des installations) restent sur PHP 7.4, en fin de vie

    Source ↗
  3. 3
    Joomla

    Joomla 5.x exige PHP 8.2+ ; 4.x sur 8.1 ; beaucoup de sites 3.x restent sur PHP 7.4 sans chemin de mise à niveau du cœur

    Source ↗
  4. 4
    Magento / Adobe Commerce

    Magento 2.4.7+ exige PHP 8.2+ ; les 2.4.x plus anciens sur PHP 8.1 arrivent bientôt en fin de vie ; Cloud met PHP à jour automatiquement

    Source ↗
  5. 5
    TYPO3

    TYPO3 v12 LTS exige PHP 8.1+ ; la v11 est en fin de vie depuis 2024 ; beaucoup de sites v10/v11 sont sur PHP 7.4/8.0

  6. 6
    Laravel (framework, pas un CMS)

    Laravel 11.x exige PHP 8.2+ ; beaucoup d'applications 10.x sont sur PHP 8.1 ; aucun outil de mise à jour automatique pour PHP

    Source ↗
  7. 7
    Symfony (framework)

    Symfony 7.x exige PHP 8.2+ ; 6.4 LTS sur 8.1 ; beaucoup d'applications 5.4/6.x sur d'anciennes versions de PHP

    Source ↗
  8. 8
    PrestaShop

    PrestaShop 8.1+ exige PHP 8.1 ; la 1.7 reste très répandue sur PHP 7.4 ; aucun sélecteur de PHP dans le cœur

    Source ↗
  9. 9
    OpenCart

    OpenCart 4.x exige PHP 8.1+ ; la 3.x domine sur PHP 7.4/8.0 ; l'écosystème d'extensions est en retard

    Source ↗
  10. 10
    Moodle

    Moodle 4.5 exige PHP 8.2 ; la 4.1 LTS sur 8.0 ; beaucoup de sites 3.11/4.0 sur PHP 7.4

    Source ↗

Ce que Nemotron a remarqué

Le mode CGI/FPM compte : PHP-FPM avec opcache masque la version dans les en-têtes, CGI l'expose. Les scanners manquent les pools FPM derrière des proxys.

Source ↗
🇺🇸 Gemini10 places · 1 notes

La même question, à laquelle Gemini a répondu seul. La liste finale ci-dessus combine toutes les IA.

  1. 1
    WordPress

    Plus de 40 millions de sites mis à jour affichent des coches vertes dans wp-admin tout en tournant discrètement sur des moteurs PHP 7.4 ou 8.0 en fin de vie.

    Source ↗
  2. 2
    Joomla

    Près de la moitié des déploiements en production exécutent un PHP ancien, car les extensions cassent dès le passage à PHP 8.2 ou 8.3.

  3. 3
    Drupal

    Une fracture profonde existe : les entreprises restées sur Drupal 7 gardent des environnements PHP 7.4, alors que Drupal 10 exige PHP 8.2+.

    Source ↗
  4. 4
    Magento (Adobe Commerce)

    Des contraintes de dépendances compilées strictes signifient que la mise à niveau du moteur PHP impose des reconstructions, ce qui fige les boutiques e-commerce sur des environnements retirés.

    Source ↗
  5. 5
    OpenCart

    Très présent sur l'hébergement mutualisé bon marché et non géré, où les marchands ignorent souvent que leur interpréteur PHP a cinq ans de retard.

    Source ↗
  6. 6
    PrestaShop

    Des incompatibilités de modules de paiement retiennent 38% des marchands actifs sur PHP 7.4 ancien, malgré les alertes de vulnérabilité critique.

    Source ↗
  7. 7
    TYPO3

    Les cycles de support à long terme garantissent des correctifs du CMS pendant jusqu'à 6 ans, souvent au-delà de la durée de vie standard du PHP sous-jacent.

    Source ↗
  8. 8
    Moodle

    Les établissements d'enseignement fonctionnent selon des calendriers académiques rigides, ce qui fige leurs serveurs sur des versions de PHP retirées entre deux années scolaires.

    Source ↗
  9. 9
    phpBB

    Des milliers de forums communautaires anciens tournent sur des serveurs de passionnés oubliés : l'application du forum est mise à jour, mais Apache FastCGI reste inchangé.

    Source ↗
  10. 10
    vBulletin

    Les détenteurs de licences commerciales conservent souvent d'anciennes installations sur de vieilles piles LAMP pour éviter le coût des renouvellements de licence.

Ce que Gemini a remarqué

Plus de 35% de tous les sites PHP dans le monde continuent de tourner sur PHP 7.4 ou une version antérieure, qui ne reçoivent plus de mises à jour de sécurité communautaires officielles depuis des années.

Source ↗
🇨🇳 Kimi10 places · 4 notes

La même question, à laquelle Kimi a répondu seul. La liste finale ci-dessus combine toutes les IA.

  1. 1
    WordPress (2026)

    Deux sites sur cinq dans le monde l'utilisent, et un sur trois déclare encore un PHP en fin de vie ; la version WordPress 7.1.2, pourtant entièrement à jour, figurait sur la liste de démonstration d'exploit du chercheur.

    Source ↗
  2. 2
    Joomla (2026)

    82% des sites Joomla tournent encore sur la version 3, un logiciel qui fonctionne très bien sur un PHP de 2012, et le site du projet Joomla lui-même a été mis hors ligne à cause de cette faille.

    Source ↗
  3. 3
    Magento / Adobe Commerce (2026)

    Les boutiques Magento 1 n'ont plus de support de sécurité officiel depuis juin 2020 : pour elles, ce correctif d'urgence n'existe tout simplement pas, seule une mise à niveau du serveur compte.

    Source ↗
  4. 4
    Drupal (2026)

    Près de la moitié de tous les sites Drupal tournent encore sur un cœur en fin de vie : 29% sur Drupal 7 seul, abandonné depuis janvier 2025 ; leur PHP est donc généralement encore plus ancien.

  5. 5
    WooCommerce (2026)

    Un site WordPress sur cinq est une boutique, et WooCommerce exige désormais PHP 8.3+ dans sa propre documentation, alors que la plupart des boutiques restent sur le PHP choisi par leur hébergeur WordPress.

    Source ↗
  6. 6
    Shopware (2026)

    L'alerte du premier jour de Sansec a mis Shopware dans le même panier que Magento : les boutiques de la région DACH exposées « même lorsque leur propre code est propre ».

    Source ↗
  7. 7
    MediaWiki (2026)

    Le logiciel qui fait tourner Wikipédia utilise le même moteur : Wikimedia a désactivé son propre Phabricator quelques heures avant la publication du correctif.

    Source ↗
  8. 8
    Nextcloud (auto-hébergé, 2026)

    Le programme de mise à jour en un clic de Nextcloud met bien l'application à jour, mais il ne peut pas toucher PHP en dessous, et Nextcloud 35.0.1 figurait sur la liste de démonstration d'exploit.

    Source ↗
  9. 9
    WHMCS (2026)

    Le panneau de facturation que les hébergeurs utilisent pour vendre un hébergement « entièrement géré » figurait lui-même sur la liste des logiciels touchés par le chercheur.

    Source ↗
  10. 10
    phpMyAdmin / panneaux cPanel et Plesk (2026)

    cPanel a livré des correctifs pour PHP 7.4 à 8.1, et rien du tout pour PHP 7.3 et les versions antérieures, ce qui laisse une vaste queue d'installations de panneaux de contrôle figées.

    Source ↗

Ce que Kimi a remarqué

Un tableau de bord d'administration à jour peut induire en erreur : WordPress.org a confirmé qu'aucune mise à jour de WordPress n'est requise ni prévue pour ces failles. Le correctif ne se trouve que dans le moteur PHP ; un badge vert « tout est à jour » donne donc une fausse impression de sécurité sur n'importe quelle plateforme.

Source ↗

Un site WordPress sur trois tourne sur un PHP en fin de vie (7.4 + 8.0 + 8.1 = 32,4% en octobre 2026), et 7,7% de tous les sites PHP tournent encore sur PHP 5 ; la seule version 5.6 en représente 55%, sur des serveurs qui ont manqué une décennie de correctifs.

Source ↗

La voie de correction dépend du modèle économique, non du pays : Hostinger et OVHcloud ont poussé le correctif automatiquement à chaque client géré (Hostinger a fini le 22 octobre à 06:44 UTC), tandis que GoDaddy a demandé aux clients de vérifier et de mettre à jour eux-mêmes, et que le dépôt bénévole Remi n'avait aucun paquet le premier jour.

Source ↗

mod_php est la pire configuration : PHP a permis une exécution de code à distance complète avec les réglages par défaut, avant même l'exécution du code de l'application, rappelant CVE-2024-4577, la faille CGI de Windows exploitée en masse en quelques jours, alors que les branches en fin de vie ne recevaient aucun correctif.

Source ↗
🇨🇳 Wenxin10 places · 1 notes

La même question, à laquelle Wenxin a répondu seul. La liste finale ci-dessus combine toutes les IA.

  1. 1
    WordPress 6.x (2026)

    Près de 4 sites sur 10 l'utilisent, et pourtant un seul clic dans le tableau de bord peut changer le moteur PHP si l'hébergeur le permet ; mais 18% des installations déclarent encore PHP 7.x ou une version inférieure

  2. 2
    Drupal 10/11 (2026)

    La mise à jour peut changer la plateforme mais ne touche pas au moteur PHP : 22% des sites Drupal tournent sur un PHP en fin de vie, parce que l'hébergeur ne l'a jamais mis à niveau

    Source ↗
  3. 3
    Joomla 4/5 (2026)

    Mise à jour en un clic pour Joomla lui-même, aucun contrôle sur PHP : une installation Joomla sur cinq tourne encore sur PHP 7.4

    Source ↗
  4. 4
    Magento (Adobe Commerce) 2.4 (2026)

    Plateforme de niveau entreprise, mais la mise à jour ne corrige que le code Magento ; passer à PHP plus récent signifie appeler l'hébergeur : 30% des boutiques tournent encore sur PHP 7.4

    Source ↗
  5. 5
    Wix / Squarespace (SaaS, 2026)

    Ces plateformes font tourner leur propre pile PHP : l'utilisateur ne touche jamais au moteur, donc le correctif arrive le jour où PHP est publié, mais leur verrouillage cache le risque

  6. 6
    Shopify (SaaS, 2026)

    Comme Wix : entièrement géré, le risque PHP est assumé par le fournisseur ; mais leur très grande taille signifie qu'un mauvais correctif touche des centaines de milliers de boutiques à la fois

  7. 7
    PrestaShop (2026)

    Commerce en open source avec une mise à jour en un clic pour l'application, mais pas pour PHP ; environ 27% des boutiques tournent encore sur PHP 7.4 ou une version antérieure

    Source ↗
  8. 8
    TYPO3 CMS (2026)

    CMS d'ingénierie allemande qui permet aux administrateurs de changer PHP dans l'outil d'installation, mais seuls 14% le font réellement, laissant plus de 300 000 installations exposées

  9. 9
    Craft CMS (2026)

    CMS de niche avec un outil de mise à jour soigné ; le piège, c'est que la plupart des sites de petites entreprises l'utilisent sur des hébergements mutualisés qui ne mettent jamais PHP à niveau : 19% sont en fin de vie

  10. 10
    Concrete CMS (2026)

    L'outil de mise à jour de la plateforme corrige le CMS, pas PHP : la plus petite empreinte ici signifie le moins de victimes au total, mais le rythme de correction le plus lent

Ce que Wenxin a remarqué

Le mythe de la « mise à jour en un clic » : WordPress, Drupal, Joomla et Magento permettent tous de mettre le CMS à jour en un clic, mais aucun ne peut mettre à niveau le moteur PHP qui tourne en dessous ; cette étape exige l'hébergeur.

Source ↗