Failles PHP2Shell : ce que la QA (et l'IA) aurait pu changer

Le 21 octobre 2026, PHP a publié en urgence des correctifs pour deux failles critiques, vite surnommées PHP2Shell (CVE-2026-109618 et CVE-2026-109619). Une seule requête, sans authentification, pouvait suffire à exécuter du code sur le serveur. Quand on sait la part du web qui tourne encore sur PHP, on comprend pourquoi l’agence américaine de cybersécurité, la CISA, a demandé de corriger immédiatement, en commençant par les serveurs exposés à Internet.

On pourrait ranger cette histoire dans la case « sécurité ». Je pense qu’elle parle aussi, et surtout, de qualité logicielle.

Ce qui s’est passé, en clair

Les deux failles touchent la façon dont PHP gère sa mémoire quand quelque chose tourne mal :

• La première survient quand une requête atteint la limite de mémoire autorisée (memory_limit) pile au mauvais moment. PHP laisse alors derrière lui des données à moitié construites, puis les traite plus tard comme si elles étaient valides.
• La seconde survient après une erreur fatale : PHP garde un pointeur vers de la mémoire appartenant à une requête précédente, déjà libérée. L’un des chemins pour y arriver passe par le suivi de progression des envois de fichiers, une option activée par défaut.

Autrement dit, aucun scénario « normal » ne déclenchait ces bugs. Il fallait pousser PHP dans ses cas d’échec. L’analyse détaillée de Datadog Security Labs montre qu’une simple requête POST bien construite suffisait.

Selon les équipes d’Amazon, des tentatives d’exploitation ont été observées dès le 17 octobre, quatre jours avant la publication des correctifs.

Le détail qui change tout : le problème était connu depuis 2024

En 2024, PHP a bénéficié d’un audit de sécurité réalisé par Quarkslab et financé par la Sovereign Tech Agency allemande. En traitant l’un des problèmes relevés, un développeur du cœur de PHP a repéré les premiers signes du bug de mémoire à l’origine de la première faille.

Il n’a pas été corrigé. Les raisons, données par la PHP Foundation elle-même :

• on avait imaginé une exploitation possible, mais personne n’avait trouvé de scénario concret ;
• les corrections envisagées risquaient de casser la compatibilité, d’ouvrir de nouveaux risques de déni de service ou d’obliger de nombreuses extensions à évoluer ;
• l’équipe ne s’est pas mise d’accord sur la bonne approche.

La Foundation parle d’un « échec structurel », dû à la fois à son processus de décision et à son manque de ressources. Sa directrice générale a expliqué à Reuters que la fondation compte un seul salarié à temps plein et quatorze prestataires, la plupart à temps partiel, et que les propositions de modification du code ont presque doublé en un an, sans que le nombre de contributeurs suive. Même l’audit de 2024 s’était concentré sur les composants les plus critiques faute de budget.

Où la QA aurait pu faire la différence

On imagine souvent la QA comme l’équipe qui vérifie que « le bouton fait ce qu’il doit faire ». C’est précisément le problème. Dans la plupart des équipes que je croise, l’essentiel de l’effort de test porte sur le fonctionnel : les parcours, les règles métier, les régressions visibles. Le non fonctionnel (sécurité, robustesse, performance, comportement sous contrainte) passe après, quand il reste du temps. Il en reste rarement.

PHP2Shell montre ce que coûte ce déséquilibre. Voici quatre pratiques QA qui visent exactement ce type de défaut.

1. Tester les chemins d’échec, pas seulement les chemins heureux

Les deux failles naissent quand quelque chose échoue : une allocation mémoire, une erreur fatale. Une stratégie de test robuste prévoit de provoquer ces échecs exprès :

• l’injection de fautes : simuler une mémoire pleine, un disque saturé, une dépendance qui ne répond plus, et vérifier que le système reste dans un état sain ;
• les tests aux limites : jouer des requêtes qui amènent l’application juste au seuil de memory_limit, de la taille maximale d’envoi, du temps d’exécution ;
• les outils de détection mémoire (les sanitizers) branchés sur la CI, qui signalent une mémoire libérée puis réutilisée même quand le test « passe ».

Rien de cela n’est exotique. C’est du test non fonctionnel classique, simplement rarement financé.

2. Traiter un défaut connu comme un risque, pas comme un ticket

C’est pour moi la leçon principale. Le bug était trouvé. Il a été laissé de côté parce qu’on ne savait pas encore l’exploiter.

En QA, on évalue un défaut sur deux axes : sa probabilité et son impact. Un bug de corruption mémoire dans le moteur d’un langage qui fait tourner une grande partie du web a un impact potentiel maximal. « On n’a pas trouvé d’exploit » ne veut pas dire « il n’y en a pas ». Ça veut dire « on n’a pas encore cherché assez fort ». Une bonne gestion des défauts aurait fixé une échéance, un responsable et une mesure d’atténuation en attendant la correction définitive.

3. Penser comme un attaquant dès la conception

La seconde faille passait par une fonctionnalité activée par défaut et accessible sans authentification. L’analyse de menaces (se demander, pour chaque fonctionnalité, « comment quelqu’un de malveillant l’utiliserait ? ») fait partie des pratiques que la QA peut porter dès l’affinage des besoins. Toute surface accessible sans connexion mérite des tests d’abus, pas seulement des tests d’usage.

4. Surveiller ce qu’on ne maîtrise pas

Pour une équipe qui teste un site web, PHP est une dépendance, comme une bibliothèque ou un hébergeur. Inventorier ces dépendances et leurs versions, être alerté des failles publiées, et vérifier en production que la version corrigée est bien déployée, c’est aussi de la qualité. Ce jour-là, les équipes qui savaient en quelques minutes quels serveurs tournaient sur quelle version de PHP ont eu une longueur d’avance.

Ce que l’IA a changé (et ce qu’elle n’a pas changé)

Ce sont des audits assistés par l’IA qui ont fait ressortir ces failles en 2026. Plusieurs équipes de recherche (Calif, Wiz, OpenAI) ont signalé le même problème de fond durant l’été, dans le cadre d’un programme d’audit de logiciels libres. Le bug que des humains avaient aperçu en 2024 sans pouvoir l’exploiter, des chercheurs outillés d’IA l’ont transformé en exploitation concrète. Et c’est cette preuve qui a débloqué la correction.

Deux enseignements pour la QA :

• L’IA abaisse le coût de l’exploration. Explorer des milliers de chemins d’échec, imaginer des scénarios d’abus, relire du code à la recherche de motifs dangereux : tout ce qui était trop cher pour une petite équipe devient abordable. C’est une chance pour le non fonctionnel, longtemps sacrifié faute de temps.
• L’IA ne remplace pas l’expertise. L’équipe de Calif l’a dit clairement : aucun modèle ne trouve « tous les bugs » avec un simple prompt, et l’essentiel du travail a reposé sur des connaissances que les chercheurs avaient déjà. L’IA amplifie une démarche de test. Elle n’en invente pas une.

Et il y a un revers : ces mêmes outils sont à la portée des attaquants. Si l’IA rend l’exploration moins chère pour les défenseurs, elle la rend aussi moins chère pour ceux qui cherchent des failles à exploiter. Le délai entre « un bug existe » et « quelqu’un l’exploite » va continuer à se réduire. Raison de plus pour ne plus laisser dormir les défauts connus.

Comment anticiper, concrètement

Si vous pilotez la qualité d’un site ou d’une application web, voici par où je commencerais :

1. Réserver une part fixe de l’effort de test au non fonctionnel, inscrite dans la stratégie de test et dans chaque sprint, au lieu d’attendre « quand on aura le temps ».
2. Ajouter des scénarios d’échec à vos tests automatisés : limites de taille, de mémoire, de délai, erreurs serveur volontaires. Vérifiez que l’application reste saine, pas seulement qu’elle affiche un message d’erreur.
3. Brancher un scanner de sécurité dans la CI, qui attaque l’application déployée en environnement de test, et un outil qui surveille les failles de vos dépendances.
4. Utiliser l’IA pour élargir la couverture : générer des cas d’abus à partir des user stories, faire relire les zones sensibles du code, proposer des données de test aux limites. Puis faire valider par un humain.
5. Revoir la gestion des défauts : tout défaut de sécurité ou de robustesse a une échéance et un responsable, même sans exploitation connue.
6. Tenir l’inventaire des versions en production pour savoir, le jour où une faille sort, ce qui est exposé.

En résumé

Les failles PHP2Shell ne sont pas seulement un accident technique. Elles sont en partie le résultat d’un sous-investissement chronique dans la qualité d’un projet dont dépend une grande partie du web, et la PHP Foundation le reconnaît elle-même. Ce n’est pas toute l’histoire pour autant. Le langage C, où ce type d’erreur mémoire est facile à commettre, et la contrainte de ne rien casser chez des millions de sites existants ont aussi pesé.

Pour nous, praticiens de la QA, le message est simple : la sécurité et la robustesse sont des exigences de qualité, au même titre que le bon fonctionnement d’un formulaire. L’IA nous donne enfin les moyens de les tester sérieusement. À nous d’obtenir le temps et le budget pour le faire.