CERT-EU SA 2026-018 : RCE critique dans le moteur PHP

Le 21 octobre 2026, l'équipe d'intervention en cas d'urgence informatique pour les institutions, organes et organismes de l'Union européenne (CERT-EU) a émis un avis de sécurité prioritaire, l'Avis de sécurité 2026-018 (Security Advisory 2026-018), alertant les organisations sur deux vulnérabilités critiques d'exécution de code à distance (RCE) non authentifiées découvertes dans le cœur du moteur PHP. Identifiées sous les références CVE-2026-109618 et CVE-2026-109619, toutes deux associées à un score de gravité CVSS v3.1 de 9.2, ces vulnérabilités touchent l'ensemble des environnements de déploiement courants, notamment PHP-FPM, Apache avec mod_php, FrankenPHP, LiteSpeed ainsi que les wrappers CGI historiques.

Ce qui rend ces vulnérabilités particulièrement alarmantes pour les infrastructures d'entreprise, c'est que leur exploitation permet une exécution de code arbitraire avant même que le code de l'application cliente ou du framework (WordPress, Laravel, Drupal ou microservices sur mesure) ne s'exécute. Des preuves de concept (PoC) et des analyses de vecteurs d'attaque ont commencé à circuler publiquement immédiatement après la divulgation coordonnée. Pour les directeurs techniques (CTO), responsables de la sécurité de l'information (CISO), architectes de plateformes et ingénieurs SRE gérant des parcs de serveurs Linux d'entreprise et des infrastructures cloud en Europe, considérer cette annonce comme une urgence absolue de mise à niveau et de mitigation défensive est impératif.

Impact opérationnel et business

La surface d'exposition mise en évidence par le bulletin du CERT-EU SA 2026-018 touche le cœur de l'hébergement web d'entreprise et des backends applicatifs. Des millions de services commerciaux, de portails de gestion internes, de moteurs de commerce électronique et d'applications SaaS s'appuient sur PHP, souvent intégré dans des appliances tierces ou des conteneurs où la présence du runtime n'est pas toujours explicitement tracée.

• Prise de contrôle à distance avant authentification (Pre-Auth RCE) : Les deux failles étant déclenchées durant les premières phases de parsing de la requête HTTP et d'initialisation mémoire au sein du Zend Engine, les attaquants n'ont besoin d'aucun identifiant valide, d'aucun jeton de session actif, ni d'autorisation API préalable. Une simple requête HTTP forgée envoyée à un point d'entrée exposé peut corrompre la mémoire et offrir un accès shell interactif sous l'identité du processus serveur web.
• Exigences réglementaires DORA et NIS2 : En vertu du règlement européen sur la résilience opérationnelle numérique (DORA) et de la directive NIS2, les entités financières et les opérateurs de services essentiels sont soumis à des délais stricts pour la neutralisation des vulnérabilités critiques et la notification des incidents de sécurité. L'apparition de PoCs publics pour une faille non authentifiée de sévérité 9.2 sur le périmètre déclenche des obligations immédiates de remédiation et de justification lors des audits de conformité.
• Angles morts des appliances tierces : De nombreux équipements d'entreprise dédiés au monitoring, à la gestion de tickets ou à la sécurité réseau embarquent des versions packagées ou figées de PHP (telles que PHP 8.1 ou des versions antérieures en fin de vie - EOL) qui ne bénéficient pas des canaux de mise à jour automatiques. Ces appliances non corrigées constituent le vecteur d'accès initial privilégié par les attaquants pour pénétrer latéralement les réseaux d'entreprise.
• Risques de rupture de disponibilité lors des déploiements d'urgence : Le redémarrage et la mise à niveau des processus d'exécution au sein de larges fermes de workers PHP-FPM imposent des stratégies rigoureuses de bascule sans interruption de service (zero-downtime rolling restart). Des manœuvres de redémarrage précipitées ou des dérives de configuration peuvent engendrer des cascades de timeouts, des pertes de sessions et une dégradation globale de l'expérience utilisateur.

Analyse architecturale et ingénierie

Comprendre les mécanismes internes des deux vulnérabilités est indispensable pour concevoir des barrières de filtrage fiables au niveau du reverse proxy en attendant l'application complète des correctifs logiciels.

1. CVE-2026-109618 : Corruption mémoire lors de la gestion Out-of-Memory (OOM)

PHP applique sa directive memory_limit en utilisant l'instruction standard C longjmp() pour interrompre brutalement l'exécution de la requête dès qu'une allocation dépasse le plafond défini. Lorsqu'un client envoie un flux multipart/form-data complexe ou volumineux (téléversement de fichiers), le moteur alloue dynamiquement des structures de suivi internes.

Si une allocation atteint le seuil limite de mémoire en cours d'analyse, PHP interrompt immédiatement le traitement par un saut non local (longjmp()). Cette rupture court-circuite le nettoyage nominal et laisse les structures de données dans un état partiellement initialisé. Lors de la phase de destruction de la requête qui s'ensuit, le ramasse-miettes suppose que les structures sont valides et tente de libérer des blocs mémoire qui n'ont jamais été alloués correctement. Les attaquants capables d'ordonnancer l'état du tas (heap grooming) via des requêtes préalables peuvent positionner des pointeurs contrôlés, ouvrant la voie à des primitives d'écriture arbitraire en mémoire et à l'exécution de code à distance.

2. CVE-2026-109619 : Rémanence de l'état global entre requêtes

Dans les architectures à processus persistants telles que PHP-FPM, chaque worker traite séquentiellement plusieurs requêtes consécutives pour optimiser les performances. La CVE-2026-109619 résulte de la persistance de structures mémoire appartenant à une requête antérieure après une erreur fatale ou une exception non gérée.

Lorsqu'une nouvelle requête est confiée au même processus worker, certains sous-systèmes internes accèdent à ces variables globales résiduelles avant que le cycle normal de réinitialisation ne soit finalisé. Deux vecteurs d'exploitation majeurs ont été confirmés :

• L'activation du suivi de progression de session (session.upload_progress.enabled), où l'état d'un téléversement précédent est réévalué de manière erronée.
• La génération automatique des traces de débogage d'erreurs fatales sous PHP 8.5 (fatal_error_backtraces).

[Requête 1 Attaquant : Préparation du Tas / Erreur Fatale]
                       │
                       ▼
┌────────────────────────────────────────────────────────┐
│ Processus Worker PHP (PHP-FPM / mod_php)               │
│ 1. Parsing du flux multipart                           │
│ 2. Dépassement de memory_limit -> interruption longjmp │
│ 3. État global résiduel / tas altéré conservé          │
└────────────────────────────────────────────────────────┘
                       │
                       ▼
[Requête 2 Attaquant : Déclenchement de la charge utile]
                       │
                       ▼
┌────────────────────────────────────────────────────────┐
│ Nettoyage et réinitialisation du worker                │
│ 1. Évaluation de pointeurs non initialisés             │
│ 2. Détournement du flux d'exécution (EIP/RIP / ROP)    │
│ 3. Obtention d'un shell distant non authentifié        │
└────────────────────────────────────────────────────────┘

Matrice des versions et correctifs

Les équipes de sécurité du projet PHP et des distributions Linux majeures ont publié les correctifs le 21 octobre 2026. Les équipes d'infrastructure doivent s'assurer que leurs serveurs tournent sur une version égale ou supérieure au niveau recommandé :

| Branche PHP | Versions vulnérables | Version minimale corrigée | | :--- | :--- | :--- | | PHP 8.5 | < 8.5.12 | 8.5.12 | | PHP 8.4 | < 8.4.27 | 8.4.27 | | PHP 8.3 | < 8.3.36 | 8.3.36 | | PHP 8.2 | < 8.2.35 | 8.2.35 | | PHP 8.1 et antérieures (EOL) | Toutes versions | Rétroportages éditeurs / Patchs sources |

Note pour les administrateurs Red Hat / Enterprise Linux : Le dépôt tiers bénévole Remi (rpms.remirepo.net) ne fournit pas de paquet le jour même pour cette version. Il convient d'utiliser les rétroportages officiels des distributions (Ubuntu USN, Debian Security, RHEL/Rocky/AlmaLinux) ou de compiler des binaires durcis depuis les sources.

Mesures de protection immédiates (Contournements pré-correctifs)

Si la mise à jour des paquets ne peut être appliquée immédiatement sur l'intégralité du parc, les mesures compensatoires suivantes réduisent considérablement la surface d'attaque :

Filtrage des requêtes au niveau du reverse proxy NGINX

Limitez strictement la taille des corps de requêtes et appliquez des règles strictes sur les limites de buffers afin d'entraver les tentatives de manipulation de mémoire :

# /etc/nginx/conf.d/php_security_mitigation.conf
client_max_body_size 16M;
client_body_buffer_size 128k;
large_client_header_buffers 4 16k;

location ~* \.php$ {
    fastcgi_pass unix:/run/php/php-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_buffers 16 16k;
    fastcgi_buffer_size 32k;
}

Durcissement de la configuration PHP-FPM

Ajoutez les directives d'administration suivantes dans le fichier de pool (/etc/php/*/fpm/pool.d/www.conf) pour neutraliser les conditions déclenchantes :

; Supprime l'interruption artificielle par longjmp liée à memory_limit
; ATTENTION : Doit impérativement être couplé à une limite cgroup/systemd !
php_admin_value[memory_limit] = -1

; Restreint les volumes POST et upload pour bloquer la manipulation du tas
php_admin_value[post_max_size] = 16M
php_admin_value[upload_max_filesize] = 8M

; Désactive la progression d'upload pour neutraliser le vecteur CVE-2026-109619
php_admin_value[session.upload_progress.enabled] = 0

; Pour les instances PHP 8.5 : désactive les traces d'erreurs fatales
php_admin_value[fatal_error_backtraces] = 0

Encadrement des ressources par Systemd et Cgroups

Puisque memory_limit = -1 retire le garde-fou applicatif, l'OS doit assurer la protection contre le déni de service par épuisement de mémoire :

# /etc/systemd/system/php8.3-fpm.service.d/override.conf
[Service]
MemoryMax=2G
MemoryHigh=1.8G
OOMPolicy=kill

Appliquez les changements sans délai :

systemctl daemon-reload
systemctl restart php8.3-fpm

Ce que cela change en pratique

1. Inventorier sans délai l'ensemble des dépendances : Listez toutes les machines virtuelles, conteneurs Docker, pods Kubernetes et serveurs de rebond exécutant PHP via php -v et analysez les processus actifs (ps aux | grep -E 'php-fpm|apache2|httpd|frankenphp').
2. Déployer les correctifs de manière progressive et automatisée : Intégrez immédiatement les versions validées (8.5.12, 8.4.27, 8.3.36, 8.2.35) dans vos playbooks Ansible ou configurations Terraform, en vérifiant que le rechargement s'effectue sans perte de connexions actives.
3. Contrôler les appliances et logiciels tiers : Contactez les éditeurs d'outils internes (gestion de parc, CRM, observabilité) pour obtenir confirmation de leur version de PHP embarquée et de leur calendrier de mise à disposition des correctifs.
4. Renforcer la périphérie réseau : Configurez vos reverse proxies (NGINX, Envoy, HAProxy) pour bloquer les méthodes et en-têtes inhabituels sur les points de terminaison qui ne nécessitent pas de transfert de fichiers.
5. Surveiller activement la télémétrie système : Scrutez les journaux HTTP et les métriques de segmentation mémoire pour identifier toute anomalie ou tentative d'exploitation répétée (dmesg -T | grep segfault).

L'approche d'Ali Run AIOps

Chez Ali Run AIOps, nous considérons la gestion des vulnérabilités critiques non pas comme une contrainte subie, mais comme une discipline d'ingénierie et de résilience des systèmes. Notre expertise couvre l'administration avancée des systèmes Linux, l'orchestration conteneurisée sur Kubernetes et Docker, l'architecture haute performance de reverse proxies et l'automatisation des cycles de livraison sécurisée CI/CD.

Face à des menaces d'ampleur telles que l'avis CERT-EU SA 2026-018, nous accompagnons les entreprises, institutions financières et organisations technologiques européennes dans l'audit exhaustif de leur surface d'exposition, le durcissement sur mesure de leurs passerelles NGINX et HAProxy, et le déploiement automatisé de correctifs sans interruption d'activité. Nous veillons à ce que vos infrastructures respectent scrupuleusement les exigences de NIS2 et DORA, transformant un risque opérationnel immédiat en un renforcement durable de votre posture de sécurité.

Sources

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• GitHub Advisory: CVE-2026-109618 OOM Memory Corruption in PHP
• GitHub Advisory: CVE-2026-109619 Stale Global State in PHP
• PHP Project Security Release Announcement (October 2026)