Ce que php2shell nous a appris sur la vitesse de correction

Une fuite, un correctif et des attaques, le tout en une journée

Le 20 octobre, les détails de deux failles critiques de PHP ont fuité en ligne. PHP est le langage derrière environ 70 % du Web, dont WordPress, WooCommerce et Magento. Ces failles, surnommées php2shell, permettent à des attaquants d'exécuter leur propre code sur un serveur web, sans se connecter.

L'équipe PHP a publié le correctif en catastrophe le lendemain matin. Des tentatives d'attaque ont été signalées le jour même.

Les détails techniques concernent ceux qui gèrent des serveurs PHP. Les leçons, elles, s'appliquent à toute entreprise qui a un site, une boutique en ligne ou un outil interne, peu importe la technologie. Voici ce que nous en retenons.

Leçon 1 : La fenêtre se compte maintenant en heures, et l'IA en est la cause

Il y a deux ans, une entreprise avait des semaines entre la publication d'une faille et son exploitation. Cette marge a disparu.

Ceux qui cherchent des failles travaillent maintenant avec l'IA. L'équipe de renseignement sur les menaces de Google a recensé 5 045 nouvelles vulnérabilités divulguées en janvier 2026, et 10 740 en août. Plus du double en huit mois. Et les failles trouvées avec l'aide de l'IA sont souvent graves : la moitié permettent à un attaquant d'exécuter du code sur le serveur. Pour les autres, c'est environ le quart.

Les attaquants se servent de l'IA pour transformer un correctif en attaque. Chaque mise à jour de sécurité montre exactement ce qui était brisé. Un attaquant peut confier ce changement à un modèle d'IA et obtenir du code d'attaque fonctionnel bien plus vite qu'en l'écrivant à la main. Selon Google, les attaquants le font probablement déjà. Dans un cas, six groupes distincts exploitaient une faille moins d'une semaine après sa publication.

L'IA abaisse la barre. Écrire une attaque fonctionnelle demandait autrefois des compétences rares et des jours de travail. Avec l'IA qui fait une bonne partie du travail, beaucoup plus de gens en sont capables, et en quelques heures. Plus d'attaquants, chacun plus rapide, ça veut dire plus de balayages sur vos systèmes, plus tôt après chaque correctif.

Vous n'êtes pas une cible. Vous êtes à portée. La plupart de ces attaques ne visent personne en particulier. Les attaquants balaient tout Internet à la recherche de ce qui roule encore la version vulnérable, et frappent automatiquement chaque résultat. Le site d'une petite entreprise est aussi facile à trouver que celui d'une banque, et souvent plus facile à percer. Ne pas être à jour suffit pour faire partie de la liste.

php2shell a suivi le même scénario. Du code prétendant l'exploiter circulait dès la fuite des détails. Notre propre travail repose sur ces mêmes modèles, et nous voyons à quelle vitesse ils lisent et écrivent du code. Partez du principe que quiconque veut entrer dans vos systèmes a cette vitesse aussi.

Leçon 2 : La vitesse de correction se décide avant le jour J

Les équipes qui corrigent une faille critique en quelques heures ne sont pas plus rapides ce jour-là. Elles ont tout mis en place pour qu'un correctif soit une mise à jour comme les autres.

Dans une installation bien pensée, chaque reconstruction intègre automatiquement les derniers correctifs de sécurité. La nouvelle version démarre à côté de l'ancienne, elle est vérifiée, et c'est seulement ensuite qu'elle prend le relais. Les visiteurs ne voient rien. Ça peut se faire un mardi à 14 h.

Dans une installation typique, le correctif demande une modification du code, des tests, une fenêtre de maintenance et quelqu'un qui pense à le faire. Ça prend des jours. Quand les attaques commencent en quelques heures, des jours, c'est trop long.

Leçon 3 : Ce sont les sites oubliés qui vous rattrapent

Votre site principal reçoit de l'attention. Le risque est ailleurs.

La copie de test, la vieille page de campagne, l'outil d'administration qu'une agence a monté en 2022. Ils ont été installés à la main, personne ne les met à jour, et les attaquants les trouvent avec les mêmes balayages automatisés que votre site principal. Si un outil n'est mis à jour que lorsque quelqu'un touche à son code, il peut tourner avec des années de retard.

La solution n'a rien d'excitant : chaque application se construit de la même façon, et chaque application se reconstruit selon un horaire, même quand personne n'y a touché.

Leçon 4 : Un pare-feu fait gagner du temps. Ce n'est pas la solution.

Des fournisseurs comme Cloudflare ont déployé des règles de pare-feu d'urgence pour php2shell en quelques heures. Ça aide. Mais ces règles peuvent être contournées, et le trafic à l'intérieur de votre propre réseau n'y passe jamais. Seule la mise à jour referme la brèche.

Et la mise à jour ne vous dit pas si quelqu'un est entré avant. Pour tout ce qui était exposé avant d'être mis à jour, quelqu'un devrait chercher des fichiers ajoutés ou modifiés, repérer toute activité inhabituelle dans les journaux et regarder ce que le pare-feu a bloqué. Si un système contient des mots de passe ou des clés d'API, les changer est la décision prudente.

Les questions à poser à la personne qui gère vos systèmes

Pas besoin des détails techniques. Il vous faut des réponses à ces questions.

1. Avons-nous la liste de chaque site et outil en service, avec la technologie sur laquelle il roule? Y compris ceux auxquels personne n'a touché depuis un an.
2. Combien de temps faudrait-il pour appliquer un correctif de sécurité urgent à tous? La réponse à viser : quelques heures.
3. Pouvez-vous mettre à jour sans rien mettre hors ligne? Si la réponse parle de fenêtre de maintenance, demandez pourquoi.
4. Lesquels de nos systèmes sont accessibles à n'importe qui sur Internet? Les panneaux d'administration et les sites de test devraient exiger une connexion avant même d'être visibles.
5. Si quelqu'un était entré avant le correctif, le saurions-nous? Ça suppose des journaux conservés à un endroit qui survit à une mise à jour.

Un bon développeur ou une bonne agence répond aux cinq en moins d'une heure. Si ça demande une semaine d'enquête, le problème dépasse cette faille.

Notre approche

Nous concevons des agents IA sur mesure et les applications qui les entourent. Ces applications traitent des données clients, se connectent aux CRM et aux boîtes courriel, et roulent tous les jours. Pour elles, une mise à jour de sécurité doit être une routine, pas un projet d'urgence.

Chaque application que nous livrons suit donc les leçons ci-dessus. Chaque reconstruction intègre les derniers correctifs de sécurité. Les applications se reconstruisent selon un horaire, même quand personne n'a touché au code, pour que les outils tranquilles restent à jour eux aussi. Les mises à jour se font sans interruption. Et nous pouvons lister chaque application en service avec sa version exacte en une seule étape, alors « sommes-nous touchés? » se règle en quelques minutes.

Rien de tout ça n'est exotique. C'est du travail de mise en place que la plupart des équipes reportent parce que rien n'a encore mal tourné. Nous avons écrit sur le même phénomène avec le code généré par l'IA : la vitesse sans le travail de sécurité finit toujours par vous rattraper.

php2shell ne sera pas la dernière faille critique de l'année. Avec l'IA des deux côtés, la prochaine arrivera avec une fenêtre encore plus serrée. Ce qui décide de votre exposition, c'est l'installation que vous avez en place avant qu'elle arrive.