Contexte
Deuxième article de veille sur mon propre serveur. En septembre, j'avais traité CVE-2026-93485 (XSS stocké dans wpautop(), WordPress 7.1.1). Cette fois, j'ai choisi une faille volontairement « petite » et facile à comprendre : CVE-2026-91768, dans PHP-FPM, le moteur qui exécute le PHP de mon portfolio (WordPress) et de ce blog (Dotclear).
Retour sur la CVE de septembre
Le vrai problème découvert en septembre n'était pas la faille elle-même : les mises à jour automatiques de WordPress étaient cochées mais ne tournaient jamais. WP-Cron se déclenche par une requête HTTP que le site s'envoie à lui-même ; dans mon architecture LXC, cette requête passe par l'IP publique et doit revenir par NAT (hairpin NAT), ce qui échoue. Je l'avais remplacé par un timer systemd toutes les 5 minutes.
Un mois plus tard, je vérifie que ça a servi : le site est passé tout seul en 7.1.3 le 6 octobre.
La nouvelle faille : CVE-2026-91768
Publiée le 24 septembre 2026, corrigée dans PHP 8.2.34 (et 8.3.35, 8.4.26, 8.5.11). Score CVSS 3.1 : 6,5 (moyen), mais avec une condition forte : l'attaquant doit être sur un réseau voisin (vecteur « Adjacent »), pas n'importe où sur Internet.
À quoi sert la fonction touchée ? PHP-FPM peut écouter sur un port réseau. Dans ce cas, l'option listen.allowed_clients sert de liste blanche : seules les adresses IP listées ont le droit de lui demander d'exécuter un script. C'est un videur avec une liste d'invités.
Le bug : une adresse IPv6 fait 16 octets (128 bits). Pour comparer l'adresse du visiteur à celle de la liste, le code ne comparait que les 12 premiers octets (96 bits) — une longueur codée en dur, juste en dessous de la bonne. Les 4 derniers octets, ceux qui distinguent une machine de sa voisine, n'étaient jamais vérifiés.
Image simple : le videur ne lit que le début du numéro de la carte d'identité. Si tu partages les mêmes premiers chiffres qu'un invité, tu entres. Exemple tiré de l'avis : avec allowed_clients = ::2, une connexion depuis ::1 est acceptée et le script s'exécute.
Conséquence : une machine du même réseau IPv6 qu'un client autorisé peut faire exécuter des scripts PHP alors qu'elle devrait être refusée. Il n'y a pas d'exploitation active connue au moment où j'écris.
Mon serveur est-il touché ?
Première vérification : la version installée, et le journal des modifications du paquet Debian pour être sûr que le correctif est dedans. Puis : le service a-t-il bien été redémarré après la mise à jour ? Un paquet à jour sur le disque ne protège pas un processus lancé avec l'ancienne version.
PHP 8.2.34 a été installé le 6 octobre à 15:52, lors de ma passe de correctifs de sécurité, et PHP-FPM a redémarré à 15:54 : c'est bien la version corrigée qui tourne. Depuis ce jour-là, les mises à jour de sécurité automatiques (unattended-upgrades) sont activées dans tous mes containers.
Et même avant le correctif ?
La faille ne concerne que PHP-FPM en écoute sur le réseau. J'ai donc regardé par où les requêtes arrivent chez moi.
Dans les deux containers (portfolio et blog), PHP-FPM écoute sur un socket Unix (/run/php/php8.2-fpm.sock) : un fichier local que seul Apache, dans le même container, utilise. Il n'ouvre aucun port réseau, il n'y a donc pas de liste allowed_clients à contourner, et les containers n'ont même pas d'adresse IPv6 globale. Mon serveur n'était pas exposé, même avant la mise à jour.
Dernier contrôle : les deux sites PHP répondent normalement.
Comparaison des deux CVE
| CVE-2026-93485 | CVE-2026-91768 | |
|---|---|---|
| Composant | WordPress (application) | PHP-FPM (moteur PHP) |
| Type | XSS stocké, côté navigateur | Contournement de contrôle d'accès |
| Attaquant | Doit publier un commentaire | Doit être sur un réseau IPv6 voisin |
| Gravité | Moyenne | Moyenne (6,5), risque réel faible |
| Mon exposition | Réelle mais faible | Nulle : socket local, pas de port réseau |
| Action | Mise à jour manuelle + réparation de WP-Cron | Vérification (paquet, redémarrage, config) |
À retenir
- Une erreur minuscule (12 au lieu de 16) suffit à casser un contrôle d'accès : en sécurité, les comparaisons doivent être complètes.
- Sous Debian, c'est le changelog du paquet qui prouve qu'une CVE est corrigée, pas seulement le numéro de version.
- Paquet à jour ≠ service protégé : vérifier que le processus a redémarré après la mise à jour.
- Moins un service est exposé, moins ses failles comptent : un socket local plutôt qu'un port réseau a suffi à rendre cette CVE sans effet chez moi.
Sources : avis PHP (GitHub Security Advisory) relayé par Wiz et stack.watch, SUSE (CVE-2026-91768), Debian Security Tracker, changelog du paquet php8.2 8.2.34-1~deb12u1.
