Deux incidents, une même leçon d’infrastructure
Le titre de travail ne doit pas être compliqué: Ivanti and PHP hit critical systems. Côté Ivanti, CISA a ajouté deux vulnérabilités de Connect Secure, CVE-2026-111357 et CVE-2026-118527, à son catalogue Known Exploited Vulnerabilities après des constats d’exploitation active . Côté PHP, les failles PHP2Shell restent un problème de résilience pour le secteur public, avec des analyses récentes rappelant l’épisode britannique durant lequel 32 services gouvernementaux étaient indisponibles et quatre partiellement indisponibles pendant l’application de mesures de protection .
Ces deux dossiers ne décrivent pas le même type de faille. Ivanti Connect Secure est une passerelle VPN en périphérie: exposée par nature, fortement privilégiée, et souvent connectée à l’identité, aux annuaires et aux réseaux internes. PHP est un environnement d’exécution web: moins spectaculaire, mais présent dans des sites, portails, CMS, applications internes et produits tiers. Le point commun est la dépendance systémique. Quand une passerelle d’accès distant tombe, l’attaquant peut obtenir un pont vers l’intérieur. Quand une couche web très répandue doit être corrigée en urgence, les défenseurs peuvent devoir couper l’accès public avant même de pouvoir démontrer que tout est sûr.
Ivanti: la chaîne compte plus que le score
Le dossier Ivanti est passé du statut de vulnérabilité sérieuse à celui de priorité d’intervention parce que les failles sont chaînées. The Hacker News a rapporté le 31 octobre que CISA avait ajouté CVE-2026-111357 et CVE-2026-118527 à KEV après exploitation dans la nature, et que ces deux failles appartenaient à une chaîne documentée avec CVE-2026-104935, une faille de contournement d’authentification déjà ajoutée à KEV le 13 octobre .
L’effet combiné compte davantage qu’un score isolé. D’après ce reporting, CVE-2026-111357 est une absence d’authentification sur une fonction critique pouvant permettre une élévation de privilèges, tandis que CVE-2026-118527 concerne des identifiants prévisibles permettant de téléverser du contenu contrôlé par l’attaquant vers un emplacement connu sur disque . Associée au contournement d’authentification et à l’exécution de code à distance, cette chaîne donne aux attaquants ce que les défenseurs redoutent sur une passerelle VPN: une exécution de code non authentifiée avec privilèges root .
C’est pourquoi la réponse ne peut pas se limiter à “installer le correctif du CVE”. Le Centre canadien pour la cybersécurité a mis à jour son avis Ivanti le 30 octobre et indique que les versions de Connect Secure antérieures à 25.1.1.3, antérieures à 25.1.3.1 et antérieures à 22.8R2.6 sont touchées . Le même avis précise que CISA a ajouté CVE-2026-111357 et CVE-2026-118527 à KEV le 30 octobre . En clair, certaines organisations qui ont corrigé après la première alerte d’octobre doivent corriger de nouveau.
Un accès root sans implant bruyant
L’aspect le plus gênant de l’activité Ivanti est qu’elle peut ne pas ressembler à une compromission classique avec web shell persistant sur disque. The Stack a rapporté le 29 octobre qu’Ivanti avait publié des correctifs pour deux CVE supplémentaires de la chaîne exploitée, après avoir corrigé CVE-2026-104935 le 13 octobre . L’article résume aussi l’observation de Volexity selon laquelle l’attaquant réexécutait la chaîne et faisait passer commandes et résultats dans des requêtes HTTPS, plutôt que d’utiliser un canal de commande et contrôle séparé .
Ce mode opératoire change le travail des équipes de défense. S’il n’y a pas de balise persistante, l’absence de balise n’est pas une preuve d’absence de compromission. Si l’attaquant peut atteindre root puis nettoyer, l’appliance en périphérie devient à la fois le point d’entrée et le coffre à preuves. The Stack rapporte que l’acteur suivi par Volexity sous le nom UTA0576 s’est concentré sur le vol d’identifiants, l’exfiltration de données, l’altération de journaux, la reconnaissance réseau, le password spraying et l’inspection de journaux d’authentification .
Le reporting du 31 octobre ajoute une contrainte de calendrier: les agences civiles fédérales américaines doivent appliquer les correctifs pour CVE-2026-111357 avant le 2 novembre et pour CVE-2026-118527 avant le 13 novembre . Même hors administration fédérale américaine, ces dates donnent une mesure utile de l’urgence. Les passerelles VPN en périphérie doivent être gérées comme des actifs critiques, pas comme de simples équipements de fond de baie.
PHP2Shell: la disponibilité fait partie de la sécurité
Le volet PHP raconte une autre histoire, mais tout aussi systémique. AWS a mis à jour son bulletin PHP le 30 octobre et décrit CVE-2026-109618 et CVE-2026-109619 comme deux problèmes critiques pouvant permettre à un acteur non authentifié d’exécuter du code sur des systèmes affectés . AWS indique qu’un appelant distant peut envoyer des requêtes web spécialement conçues à des workers PHP vulnérables afin d’exécuter du code arbitraire, de lire des données accessibles au processus ou de provoquer un déni de service .
Les branches corrigées sont clairement identifiées: PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 . Le message le plus difficile concerne les parcs anciens. AWS précise que PHP 5.4 à 8.1 ne disposent d’aucun correctif amont prévu, car ces branches sont en fin de vie, et recommande une migration vers une branche supportée . Les recommandations publiées par Microsoft le 30 octobre traduisent la même réalité opérationnelle dans le cloud: l’automatisation de plateforme peut aider lorsqu’elle existe, mais les systèmes gérés manuellement, les conteneurs, les images personnalisées et les installations PHP sur Windows demandent toujours une action du propriétaire, avec redémarrage ou redéploiement .
C’est là que l’indisponibilité de services gouvernementaux britanniques devient l’avertissement principal. Le sujet n’est pas que PHP serait ancien, ni que les gouvernements seraient seuls fragiles. Le sujet est qu’un runtime omniprésent devient une infrastructure critique partagée lorsque des dizaines de services aux citoyens en dépendent. La mise à jour d’ITLab du 30 octobre cite le cas britannique des 32 services indisponibles et quatre partiellement indisponibles, tout en rappelant que plusieurs gouvernements ont mis des sites hors ligne par précaution pendant les correctifs . Voilà à quoi ressemble un incident de sécurité lorsque la meilleure atténuation immédiate consiste à retirer l’accès public.
Ce que les responsables doivent faire maintenant
Pour les opérateurs Ivanti, la première étape est la vérification de version. Il faut confirmer que les appliances Connect Secure sont en 25.1.1.3, 25.1.3.1 ou 22.8R2.6 selon la branche, en priorisant tout déploiement exposé à Internet . La deuxième étape est l’évaluation de compromission. Comme la chaîne rapportée implique collecte d’identifiants, altération de journaux et accès root, un système corrigé n’est pas nécessairement un système sain . Les identifiants stockés, comptes de service, liaisons LDAP et journaux d’authentification doivent être considérés comme pertinents pour l’enquête.
Pour les opérateurs PHP, la première étape est l’inventaire réel des runtimes. Savoir qu’un serveur “utilise PHP” ne suffit pas; il faut connaître la version effectivement exécutée par chaque application, conteneur, image de plateforme et produit tiers. AWS et Microsoft insistent tous deux sur le fait que la mise à niveau vers des versions PHP corrigées est la vraie correction, tandis que les règles WAF et changements de configuration sont des mesures compensatoires, pas des substituts .
Pour les dirigeants, la leçon est la cartographie des dépendances. Ivanti illustre un problème de confiance en périphérie; PHP illustre un problème de dispersion d’un runtime. Les deux cas punissent les organisations qui n’ont ni inventaire à jour, ni processus de changement d’urgence, ni bascule testée. La disponibilité publique fait partie de la sécurité, et couper un service peut être responsable si l’alternative consiste à exposer citoyens, identifiants ou réseaux internes. Mais la dégradation contrôlée doit être conçue avant l’urgence.
Dans la chaîne Ivanti, les attaquants ont atteint la partie du système qui peut dire “oui” à tout. Dans l’incident PHP, une couche partagée a fait dire “indisponible” à de nombreux services publics en même temps. Technologies différentes, conclusion identique: les systèmes critiques reposent souvent sur des composants ordinaires jusqu’au jour où tout le monde doit les corriger immédiatement.
Commentaires
Sois le premier à commenter.