·
Devclic
 

PHP : deux failles critiques corrigées en urgence, notre infrastructure est à jour

Actualité|mercredi 21 octobre 2026

Les deux failles critiques de PHP publiées le 21 octobre 2026 sont corrigées sur l’infrastructure Devclic. Les serveurs d’hébergement et les environnements que nous administrons tournent désormais sur des versions de PHP qui intègrent les correctifs. Voici le détail des vulnérabilités, et la démarche à suivre si vous administrez vous-même des serveurs PHP.

Les faits : une publication avancée en urgence

  • 20 octobre : des informations sur deux failles fuitent en ligne. Le projet PHP publie dans la foulée un préavis de mise à jour de sécurité critique et avance la date prévue.
  • 21 octobre : sortie de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2 en CVSS v4.0.

Côté technique, d’après l’avis officiel :

  • CVE-2026-109618 : une condition de manque de mémoire (OOM) peut interrompre PHP pendant que les données d’une requête ne sont que partiellement initialisées ; la phase de nettoyage les traite ensuite comme valides, ce qui permet l’exécution de code.
  • CVE-2026-109619 : un état propre à une requête peut survivre à la libération de sa mémoire ; une requête ultérieure sur le même worker peut l’utiliser avant sa réinitialisation (use-after-free, fuite de mémoire, exécution de code avec les droits du worker web).

Le risque le plus élevé concerne Apache avec mod_php, pour lequel une exécution de code à distance non authentifiée a été démontrée en configuration par défaut. PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont aussi concernés. Le projet PHP précise qu’aucune mesure de contournement n’est complète : seule la mise à jour protège réellement.

Sur l’infrastructure Devclic : correctifs appliqués

Nous avons déployé les versions corrigées de PHP sur l’ensemble de notre infrastructure, puis redémarré les services PHP concernés pour que les nouveaux binaires soient bien chargés. Les sites et applications hébergés chez Devclic sont protégés contre ces deux failles, sans action de votre part.

Vous administrez vos propres serveurs ? La procédure

1. Inventorier toutes les versions de PHP installées, y compris celles qu’aucun site n’utilise :

ls /etc/php
dpkg -l 'php*' | awk '/^ii/ {print $2, $3}' | grep -E '^php[0-9.]+-(fpm|cli|common)'

2. Mettre à jour (Debian / Ubuntu), en conservant vos fichiers de configuration :

sudo apt-get update
apt-cache policy php8.4-fpm          # vérifiez la version "Candidate"
sudo apt-get install --only-upgrade -y \
  -o Dpkg::Options::="--force-confold" \
  $(dpkg -l 'php8.4*' | awk '/^ii/ {print $2}')

Si vous utilisez les paquets de votre distribution plutôt que ceux du projet PHP, le numéro de version peut rester identique : c’est le changelog du paquet qui doit mentionner les deux CVE.

3. Redémarrer et vérifier :

sudo systemctl restart php8.4-fpm     # ou apache2 si mod_php
php-fpm8.4 -v
systemctl status php8.4-fpm --no-pager

Pensez aussi aux processus PHP lancés en ligne de commande (workers de files, démons, tâches longues) : ils continuent d’utiliser l’ancien binaire jusqu’à leur redémarrage. Et aux images de conteneurs, à reconstruire avec docker build --pull --no-cache.

4. Automatiser sur un parc. Avec Ansible, une tâche suffit pour l’ensemble des serveurs :

- name: Mettre à jour PHP (correctifs CVE-2026-109618 / 109619)
  ansible.builtin.apt:
    name: "php8.4*"
    state: latest
    only_upgrade: true
    update_cache: true
  notify: restart php-fpm

Versions en fin de vie : limiter l’exposition

PHP 8.1 et les versions antérieures ne sont plus maintenues par le projet PHP. Pour un serveur qui ne peut pas être mis à jour immédiatement, l’avis officiel cite des atténuations partielles, à considérer comme temporaires :

; php.ini
session.upload_progress.enabled = 0
post_max_size = 8M        ; valeur plus basse qu'actuellement

Le plus sûr reste de retirer ces serveurs d’Internet ou de les placer derrière un VPN ou un pare-feu applicatif, le temps de migrer. Rappel : PHP 8.2 arrivera lui-même en fin de vie le 31 décembre 2026.

Surveiller les signes de compromission

Si un serveur est resté exposé avant la mise à jour, surveillez notamment les processus PHP qui lancent des shells ou des outils réseau, l’apparition de fichiers inconnus dans les racines web et les nouvelles tâches cron :

ps -eo pid,ppid,user,cmd --forest | grep -A3 -E 'php-fpm|apache2|httpd'
find /var/www -type f -name '*.php' -newermt '2026-10-20' -ls
crontab -l -u www-data

En cas de doute, isolez le serveur et conservez les journaux du serveur web et de PHP avant toute remise en état.

Vous souhaitez que nous prenions en charge l’administration de vos serveurs, ou un audit des versions de PHP de votre parc ? Contactez l’équipe Devclic.

Sources