Le 21 octobre 2026, deux vulnérabilités critiques, PHP2Shell (CVE-2026-109618 et CVE-2026-109619), ont été divulguées publiquement. Toutes deux affichent un score de 9,2 et permettent l'exécution de code à distance sur les serveurs vulnérables. Des portails gouvernementaux, des services publics et des sites commerciaux dans plusieurs pays ont été mis hors ligne par précaution pendant que les équipes se précipitaient pour appliquer les correctifs.
Mais les failles étaient connues dès le 20 octobre, et le correctif n'a été déployé que le 21. C'est dans cet intervalle que les attaquants opèrent, ce qui soulève la question que toute équipe de sécurité se pose : comment protéger les systèmes lorsqu'une vulnérabilité est connue mais que le correctif n'est pas encore disponible ?
Les limites de la protection basée sur les signatures
Les WAF traditionnels reposent, au moins en partie, sur des signatures. Cela les rend prévisibles, mais introduit également un délai. Quelqu'un doit analyser l'exploit, rédiger la règle et la diffuser ; dans bien des cas, les clients doivent encore effectuer des manipulations manuelles avant d'être protégés.
Et que se passe-t-il si un exploit circule avant que votre fournisseur ne mette à jour ses systèmes ? Que se passe-t-il si l'attaquant modifie la charge utile pour qu'elle ne corresponde plus à la signature ? Avec l'IA qui aide les attaquants à analyser les failles et à générer des variantes d'exploits en quelques heures, cette fenêtre ne cesse de se réduire.
PHP2Shell complique encore la donne. Les deux CVE proviennent de failles de gestion de la mémoire dans le moteur PHP lui-même, et non de la logique d'une application spécifique. Cela signifie qu'il existe de multiples vecteurs d'exploitation avec des structures de requêtes et des conditions de déclenchement différentes. Une signature qui détecte une variante ne garantit pas la protection contre la suivante.
À quoi ressemble l'attaque
Une chaîne ciblant la CVE-2026-109618 inclut un champ PHP_SESSION_UPLOAD_PROGRESS dans un téléchargement multipart, alors même que le point de terminaison de l'application ne le définit jamais. Pour un moteur de signature, la requête peut sembler être un téléchargement ordinaire. (La charge utile dans cet exemple est omise.)
Comment Salt perçoit la situation
Salt n'a pas besoin de connaître l'exploit. Salt apprend la structure de vos API, de vos appels MCP et de vos points de terminaison d'application : quels champs, paramètres et formats chaque point de terminaison attend. Une requête contenant un champ PHP_SESSION_UPLOAD_PROGRESS vers un point de terminaison qui n'en a jamais accepté est une anomalie, et aucune signature n'est nécessaire pour la détecter.
Mais repérer une anomalie ne suffit pas. De nombreuses requêtes inhabituelles sont inoffensives : une nouvelle version de client, une intégration mal configurée, un développeur en phase de test. Si chaque anomalie déclenche une alerte, les défenseurs sont submergés par le bruit et les véritables attaques passent inaperçues.
L'élément manquant est l'intention. La détection de l'intention comportementale de Salt apporte le contexte nécessaire pour déterminer si une anomalie est liée à une activité malveillante. Salt examine la manière dont le consommateur a effectué les requêtes, la compare à l'utilisation normale du point de terminaison de l'application, et surveille des centaines d'autres attributs comportementaux. Un champ inhabituel provenant d'un client connu est très différent du même champ envoyé par un consommateur qui sonde les points de terminaison, fait varier les charges utiles et ne se comporte en rien comme un utilisateur légitime.
L'anomalie vous indique que quelque chose est différent. L'intention vous indique s'il s'agit d'une attaque.
Nous avons déjà vu ce scénario
Ce n'est pas un cas isolé. Lors de l'apparition de Log4Shell, Salt a détecté des tentatives d'exploitation contre ses clients avant même la publication de la moindre signature. La vulnérabilité était différente, mais le principe restait le même : les attaques contre les failles au niveau de l'infrastructure doivent toujours se présenter sous forme de requêtes, et les consommateurs qui les envoient se comportent différemment des utilisateurs légitimes de vos API et points de terminaison d'application.
La détection comportementale est efficace précisément là où les signatures échouent. Lorsqu'une faille réside dans l'infrastructure plutôt que dans le code de l'application, une seule requête peut suffire à prendre le contrôle d'un système légitime. Une protection qui ne s'active qu'une fois la signature rédigée intervient trop tard.
En résumé : les failles zero-day ne sont qu'un échauffement.
Les failles zero-day continueront d'apparaître. Ce qui change, c'est la surface sur laquelle elles se manifestent.
À mesure que les entreprises poursuivent leur transformation par l'IA, le trafic machine à machine connaît une croissance rapide. Les API, les serveurs MCP et les agents sollicitant d'autres agents et services se multiplient, et ces appels impliquent de moins en moins d'intervention humaine. Cela signifie davantage de cibles, davantage de consommateurs et davantage d'opportunités d'exploiter une faille unique.
Parallèlement, les acteurs malveillants et les agents corrompus ne se contentent plus de frapper à la porte. Ils ont pénétré à l'intérieur. Une fois sur place, ils se fondent dans la masse des charges de travail effectuant des appels API, et les outils de périmètre conçus pour inspecter le trafic à l'entrée ne les détectent souvent jamais. Dans un tel environnement, une signature n'a rien à comparer et une simple anomalie structurelle ne suffit pas, car presque tout, à l'intérieur, ressemble à une machine communiquant avec une autre.
C'est pourquoi l'intention compte plus que jamais. La question n'est plus seulement « cette requête semble-t-elle inhabituelle ? », mais « qui l'effectue, comment se comporte-t-il et que cherche-t-il à faire ? ». PHP2Shell est une illustration claire du délai de correction, mais le problème majeur est que ce fossé existe désormais partout où les machines communiquent entre elles.
Les défenseurs ont besoin d'une protection capable de comprendre leurs propres API et l'intention de quiconque les sollicite, afin de stopper les attaques dès le premier jour, avant le correctif, avant la signature et avant même que la variante ne soit documentée.
C'est précisément la mission de Salt.