Contexte des incidents de la semaine du 16 octobre 2026

Entre le 16 et le 23 octobre 2026, six composants majeurs – PHP, Node.js, GitLab, LiteLLM, OpenCode et l’autorité de certification eMudhra – ont fait l’objet de vulnérabilités critiques. Les correctifs de PHP, Node.js et GitLab ont été publiés le 21 octobre, le même jour où la version compromise de LiteLLM a été diffusée. La tentative d’exploitation PHP2Shell a été enregistrée par les honeypots MadPot d’Amazon quatre jours avant la divulgation officielle, montrant que l’« exposure window » était déjà ouverte avant que les équipes ne puissent appliquer les correctifs.

Le rapport de Mandiant indique que le délai moyen entre divulgation et exploitation est passé de 63 jours (2018‑2019) à seulement cinq jours en 2023, avec 70 % des vulnérabilités exploitées comme zero‑day. Selon Drew Silcock, les modèles LLM accélèrent encore ce processus, réduisant le passage d’une faille RCE à une attaque automatisée à quelques heures.

Mécanismes d’inventaire et détection sur AWS et Azure

Identifier les actifs affectés reste la partie la plus chronophage. Sur AWS, la recherche des fonctions Lambda exécutant un runtime Node.js obsolète ou une image conteneurisée se fait avec la boucle suivante :

for region in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  echo "== $region"
  aws lambda list-functions --region "$region" \
    --query "Functions[?PackageType=='Image' || (Runtime && starts_with(Runtime, 'nodejs'))].[FunctionName, Runtime || PackageType]" \
    --output text
done

Les fonctions basées sur des images ne révèlent pas leur contenu ; un scanner d’images ou une reconstruction du conteneur est alors nécessaire.

Pour les applications PHP sur Azure App Service, la requête Azure Resource Graph suivante liste les sites Linux dont la pile indique PHP 8.1 ou antérieure :

az graph query -q "
resources
| where type =~ 'microsoft.web/sites'
| mv-expand setting = properties.siteProperties.properties
| where setting.name =~ 'LinuxFxVersion' and tostring(setting.value) startswith 'PHP'
| project name, resourceGroup, subscriptionId, stack = tostring(setting.value)
" --first 1000 -o table

Les machines virtuelles et conteneurs restent invisibles aux plans de contrôle cloud ; ils ne sont découverts que via AWS Systems Manager Inventory, Amazon Inspector ou Microsoft Defender for Cloud, ce qui crée un « coverage gap » critique.

Analyse des lacunes et recommandations opérationnelles

Les contrôles CIS 1 et 2 insistent sur l’inventaire des actifs, alors que la gestion des vulnérabilités n’apparaît qu’au contrôle 7. La directive CISA BOD 23‑01 impose une découverte automatisée tous les 7 jours et un inventaire des vulnérabilités tous les 14 jours pour les agences fédérales américaines. En pratique, l’absence de visibilité sur les serveurs auto‑gérés (ex. GitLab on‑prem) signifie que les correctifs ne sont jamais appliqués, même si le code source est à jour.

Pour réduire la première partie de la fenêtre d’exposition (détection), les organisations doivent :

1. Centraliser les métadonnées d’infrastructure : tags cohérents, CloudTrail/Azure Activity Log archivés au-delà de 90 jours, et corrélation avec les bases d’inventaire internes.

2. Activer les agents de découverte sur chaque VM et conteneur : cela comble le vide laissé par les API de service qui ne voient que les ressources gérées.

3. Automatiser la corrélation entre les alertes de vulnérabilité et les actifs découverts : un pipeline CI/CD qui déclenche un scan d’image dès le push d’un conteneur et crée un ticket d’attente de mise à jour.

En l’absence de ces mesures, même les équipes les plus agiles en CI/CD restent dépendantes de listes manuelles, de fils Slack et de recherches ad‑hoc, ce qui prolonge inutilement le temps de réponse face à des exploits qui se propagent en quelques heures.