PHP a publié le 21 octobre 2026 des correctifs d’urgence pour CVE-2026-109618 et CVE-2026-109619. Ces deux vulnérabilités critiques touchent la mémoire et ont obtenu une note CVSS v4.0 de 9.2. Elles permettent une exécution de code à distance sans authentification sur les installations PHP qui traitent des requêtes Web. Sont concernés PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est maximal avec mod_php, car l’exploitation intervient avant l’exécution du code applicatif.

agent.conf
<agent_config>
  <localfile>
    <log_format>full_command</log_format>
    <command>ps -u www-data -o comm=,args= 2>/dev/null | grep -Ev '^(php-fpm|php-fpm[0-9.]+|apache2|htcacheclean|nginx) ' | grep -Ev 'front/cron\.php' || true</command>
    <alias>web-children</alias>
    <frequency>60</frequency>
  </localfile>
  <syscheck>
    <directories realtime="yes" check_all="yes" restrict=".php$|.php5$|.php7$|.phtml$|.phar$|.inc$">/var/www</directories>
    <ignore type="sregex">/cache/|/_cache/|/sessions/|/_sessions/|/_tmp/|/_log/|/wp-content/upgrade/</ignore>
  </syscheck>
</agent_config>

Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les distributions Linux ont publié leurs propres paquets le même jour. PHP 8.1 et les versions antérieures n’ont pas reçu de correctif officiel. Les workers déjà actifs doivent malgré tout être redémarrés après la mise à jour, notamment php-fpm et le serveur Web.

La contribution communautaire présente trois règles locales Wazuh et un groupe d’agents destiné à couvrir le délai entre l’annonce et le déploiement complet des correctifs. La configuration a été testée en production. Elle ne détecte pas de manière fiable l’exploitation elle-même, car les deux failles interviennent avant l’application et ne laissent pas de trace exploitable dans les journaux applicatifs. Elle recherche plutôt les processus lancés par l’utilisateur du serveur Web et les fichiers PHP créés ou modifiés ensuite. La méthode vise toute exécution de code à distance sur un serveur Web PHP, pas uniquement ces deux CVE.

Le 21 octobre, Wazuh CTI ne référençait encore aucun des deux CVE. Vulnerability Detection ne pouvait donc pas signaler les agents concernés. NVD avait publié les deux entrées le même jour. Ubuntu mentionnait USN-8948 pour php8.3 version 8.3.6-0ubuntu0.24.04.13 sur Ubuntu 24.04. Debian citait DSA-6574-1 et DLA-4848-1 pour trixie et bookworm. Bullseye, qui utilise PHP 7.4, n’avait pas de correctif. Aucun des deux CVE ne figurait dans CISA KEV. Aucun indicateur de compromission n’était confirmé, mais une preuve de concept non vérifiée circulait et pouvait contenir un logiciel malveillant.

La configuration proposée place uniquement les machines qui servent du PHP dans un groupe tel que web_php. Les commandes centralisées doivent être autorisées avec logcollector.remote_commands=1, puis l’agent doit être redémarré. La configuration du groupe échantillonne toutes les 60 secondes les processus appartenant à www-data. Elle exclut les processus normaux de php-fpm, Apache, htcacheclean et nginx, ainsi que l’exemple de tâche front/cron.php. Le contrôle d’intégrité des fichiers surveille en temps réel /var/www pour les extensions .php, .php5, .php7, .phtml, .phar et .inc. Les répertoires de cache, de sessions, temporaires et de journaux, ainsi que celui des mises à niveau WordPress, sont ignorés.

Les chemins et les comptes doivent être adaptés à chaque système. Debian et Ubuntu utilisent souvent www-data, alors que les dérivés de RHEL peuvent employer apache ou nginx. Les tâches légitimes exécutées sous le compte Web doivent être exclues. Certaines applications servent du PHP en dehors de /var/www, par exemple l’interface Zabbix sous /usr/share/zabbix. Wazuh ne suit pas les liens symboliques pour cette surveillance. Le répertoire cible doit donc être ajouté directement.

Les règles locales utilisent les identifiants 100972, 100973 et 100976, qui correspondent au déploiement présenté. Les nouveaux identifiants doivent être pris dans la plage locale libre 100000 à 120000. La règle 100972, de niveau 12, recherche dans la sortie web-children des shells, des outils de téléchargement, des utilitaires réseau, des interpréteurs de scripts et des commandes comparables. Elle associe l’activité aux techniques MITRE ATT&CK T1190, T1059.004 et T1505.003. La règle 100973, également de niveau 12, signale l’apparition d’un fichier PHP sous /var/www et utilise T1505.003. La règle 100976, de niveau 8, signale la modification d’un fichier de ces types et demande de vérifier s’il s’agit d’une mise à jour.

La configuration doit être contrôlée avec GET /cluster/configuration/validation ou wazuh-analysisd -t avant le redémarrage. Les chemins des règles doivent correspondre à ceux de agent.conf. Cinq détails techniques sont signalés. L’attribut restrict et le motif d’exclusion sregex ne sont pas des expressions PCRE. Les motifs avec groupes peuvent donc échouer sans message, et les alternatives doivent être séparées par |. $(agent.name) n’est pas développé dans la description d’une règle. Le premier balayage établit la référence, donc les fichiers créés avant le début de la surveillance en temps réel ne déclenchent pas d’alerte. Sans activation des commandes distantes, l’agent ignore silencieusement la commande du groupe. Dans un conteneur LXC non privilégié, le FIM temps réel avec inotify fonctionne, mais pas auditd. L’audit execve doit être réalisé sur l’hôte avec l’UID mappé, par exemple 100033 au lieu de 33.

Les alertes 100972 et 100973 doivent être traitées comme un incident probable jusqu’à explication. Il faut examiner full_log pour connaître le processus et ses arguments, notamment des formes comme curl envoyé vers bash, /dev/tcp, nc -e et mkfifo. Un processus inconnu justifie l’isolement du site via le WAF ou le pare-feu. Avant tout redémarrage, les journaux du serveur Web et de PHP, ps -ef, ss -tnp et un instantané de la VM ou du conteneur doivent être conservés. La recherche de persistance porte sur les nouveaux fichiers PHP, la crontab de l’utilisateur Web, les nouveaux comptes et les clés SSH. Une compromission confirmée doit être signalée à l’autorité nationale de cybersécurité compétente.

Pour un nouveau fichier PHP, le responsable de l’application doit confirmer qu’une mise à jour l’a créé. Dans le cas contraire, il faut rechercher eval, base64_decode, system, shell_exec et une exécution alimentée par $_POST, sans ouvrir le fichier dans un navigateur. Les faux positifs attendus comprennent les tâches cron de l’application exécutées sous le compte Web, PHP mail(), qui appelle sh -c sendmail, ainsi que les mises à jour de CMS ou de plugins, susceptibles de générer de nombreuses alertes 100976.

La validation exige que group_config_status = synced confirme la synchronisation du groupe. Le fichier ossec.log doit aussi montrer la surveillance en temps réel du répertoire cible. Dans logtest, un événement utilisant log_format = full_command et location = web-children doit correspondre à la règle 100972 lorsqu’il contient un shell. Une liste de processus vide doit rester au niveau 0. Pour un test de bout en bout, un processus sans danger peut être lancé sous l’utilisateur Web pendant plus longtemps que l’intervalle de 60 secondes. Il faut aussi créer un fichier .php vide dans la racine Web. L’équipe doit vérifier la réception dans le tableau de bord, par e-mail ou dans le système SOAR, puis noter l’heure du test.

La vérification des processus n’a lieu qu’une fois par minute. Une commande terminée en quelques secondes peut donc passer inaperçue. Une couverture plus complète exige auditd sur l’hôte. Avec IIS, le signal équivalent est le lancement de cmd.exe ou powershell.exe par w3wp.exe ou php-cgi.exe. Cette détection nécessite Sysmon ou l’événement Windows 4688 avec journalisation de la ligne de commande.

Le correctif et le redémarrage restent prioritaires. L’installation d’un nouveau paquet ne répare pas les workers déjà lancés. Pour PHP 7.4 à 8.1, qui ne disposent d’aucun correctif officiel, les services concernés devraient être retirés d’Internet. La contribution propose comme mesures partielles session.upload_progress.enabled=0 et memory_limit=-1 via des paramètres php_admin_*. Elle recommande aussi de contrôler le routage du WAF et les filtres SNI. Une requête portant le SNI d’un site public et l’en-tête Host d’un site interne peut atteindre ce dernier. Les requêtes externes visant des noms non publics doivent être bloquées au niveau du WAF.

Les références citées comprennent les archives PHP News Archive 2026, l’avis GitHub GHSA-w8hw-w9fx-j79w pour CVE-2026-109618, la page Ubuntu consacrée à CVE-2026-109618, le Debian Security Tracker ainsi que les analyses de Huntress et Tenable. Ces règles proviennent d’une contribution communautaire indépendante. Wazuh Inc. ne les a ni examinées, ni validées, ni approuvées. Elles ne font pas partie du jeu de règles officiel de Wazuh et doivent être testées dans chaque environnement avant un usage en production.