Le 26 octobre 2026, l’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a ajouté CVE-2026-109618 et CVE-2026-109619 à son catalogue Known Exploited Vulnerabilities (KEV), qui répertorie les vulnérabilités dont l’exploitation est connue. La décision concerne le statut d’exploitation des deux failles ; les informations sur la réponse des organismes argentins relèvent d’un autre volet.

Deux failles PHP aux mécanismes distincts

The PHP Foundation a décrit deux voies distinctes d’exécution de code à distance, c’est-à-dire l’exécution de code sur un serveur à partir d’une requête venue de l’extérieur.

  • CVE-2026-109618 concerne une corruption de mémoire liée à une erreur de mémoire insuffisante. Dans certaines conditions, des données internes partiellement initialisées peuvent ensuite être traitées comme valides. Sur Apache avec mod_php, une requête sans authentification peut déclencher le défaut avant l’exécution du code de l’application. The PHP Foundation a indiqué qu’une exécution de code à distance avait été démontrée avec les paramètres par défaut et que des chemins d’attaque au niveau applicatif avaient aussi été confirmés avec PHP-FPM.
  • CVE-2026-109619 concerne un état interne de requête devenu obsolète. Après une erreur fatale, cet état peut pointer vers une mémoire déjà libérée ; une requête ultérieure traitée par le même processus peut alors réutiliser cette mémoire. The PHP Foundation a fait état d’un accès à la mémoire libérée et d’un plantage de processus confirmés. Un chercheur a démontré une exécution de code à distance sur une application Apache avec mod_php.

The PHP Foundation détaille les deux failles et les correctifs.

Les versions corrigées et le cas des anciennes branches

Le projet PHP a publié les correctifs le 21 octobre 2026 dans quatre versions : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. NeoTeo avait déjà présenté les versions corrigées et les mesures associées.

L’avis de BA-CSIRT indique que PHP 8.1 et les branches antérieures ne sont plus prises en charge par le projet PHP et ne disposent pas d’une nouvelle version officielle équivalente corrigeant ces failles. Pour ces installations, BA-CSIRT recommande de passer à une branche prise en charge ou d’appliquer le correctif de sécurité fourni par le fournisseur ou la distribution concernée. L’avis de BA-CSIRT précise aussi qu’une mesure provisoire ne remplace pas la mise à jour.

Ce qui a été rapporté sur les organismes et sites argentins

Dans un article publié le 30 octobre, Clarín a rapporté qu’Ariel Cessario, ancien coordinateur du CERT argentin, avait indiqué que Argentina.gob.ar et les ministères de la Santé et de l’Économie avaient appliqué les mesures recommandées au 22 octobre. Cessario n’a pas pu confirmer la réponse des autres organismes.

Un relevé de Segu-info, dont Clarín a rapporté les résultats, comptait 13 977 sites analysés sur un inventaire de 35 847 au 29 octobre 2026 à 13 h 53. Il avait détecté des signaux de présence de PHP sur 4 758 sites : 2 354 cas reposaient sur des indices explicites et 2 404 sur la détection d’applications utilisant PHP. Parmi environ 2 350 sites dont la version avait pu être identifiée, 47 % utilisaient PHP 4, 5 ou 7, et 9 % PHP 8.0 ou 8.1.

Les vérifications recommandées par BA-CSIRT

Pour les administrateurs, BA-CSIRT recommande de vérifier la version de PHP, d’installer une version corrigée ou le paquet de sécurité du fournisseur ou de la distribution, puis de contrôler tous les environnements PHP. Si la gestion du serveur dépend d’un hébergeur ou d’une équipe technique, il faut leur demander quelle version ou quel correctif est déployé. Une mesure temporaire peut réduire certains risques, mais l’avis de BA-CSIRT préconise une mise à jour.