Le 21 octobre 2026, l'équipe de sécurité PHP a publié une mise à jour hors cycle. Deux failles critiques — CVE-2026-109618 et CVE-2026-109619 — résident dans l'interpréteur PHP lui-même, le moteur d'exécution qui propulse environ 40 % du web. Toutes deux permettent une exécution de code à distance (RCE) non authentifiée et obtiennent un score CVSS v4.0 de 9,2. Les correctifs sont intégrés dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, mais des millions de serveurs restent non corrigés. Des chercheurs rapportent que des tentatives d'exploitation contre des sites WordPress ont débuté dans les heures suivant la publication du code d'exploitation public. 1 2
Peu avant cette crise PHP, en septembre 2026, la CISA a ajouté CVE-2026-87902 dans le cœur de WordPress à son catalogue de vulnérabilités exploitées connues. 3 4 Cette faille d'inclusion de fichier à distance, affectant WordPress 4.7.0–7.1.1, est également notée CVSS 9,2 ; l'exploitation active a débuté dans les heures suivant le correctif. Par ailleurs, une vulnérabilité CVSS 10,0 dans le plugin Bricksforge (octobre 2026) a été weaponisée presque immédiatement. 5
Tout cela soulève une seule question : dans quelle mesure le logiciel serveur lui-même est-il sécurisé, indépendamment du langage qu'il exécute ?
La cause profonde des vulnérabilités PHP : la couche interpréteur
CVE-2026-109618 et CVE-2026-109619 exploitent deux scénarios distincts dans lesquels PHP laisse ses structures de données internes de traitement des requêtes partiellement initialisées, ou permet la réutilisation d'une mémoire précédemment libérée. Au cœur des deux failles se trouvent de subtils bugs de gestion de mémoire dans un interpréteur écrit en C.
La conception de PHP est structurellement vulnérable à cette classe de risques. Chaque requête HTTP lance l'interpréteur PHP, qui lit, compile et exécute le code source de l'application. Cette architecture multicouche double la surface d'attaque : les failles dans le code applicatif (WordPress, plugins) et les failles dans le cœur de l'interpréteur sont des vecteurs d'entrée tout aussi exploitables. La crise d'octobre 2026 a révélé un bug non pas dans le code de WordPress, mais dans PHP lui-même — et chaque site WordPress était exposé. 6
La justification sécuritaire du développement de FFS en C++
FFS repose délibérément sur un modèle différent de l'approche interpréteur de PHP.
Pas de couche interpréteur. FFS est un unique exécutable, écrit en C++23, fonctionnant nativement sous Linux. Lorsqu'une requête HTTP arrive, aucun interpréteur PHP, Python ou Ruby n'est lancé et aucun code source n'est lu. Le code en exécution est du code machine produit à la compilation et vérifié par le système de types. Il n'existe aucun chemin par lequel des failles au niveau de l'interpréteur comme CVE-2026-109618 et CVE-2026-109619 pourraient atteindre FFS.
Sécurité mémoire appliquée à la compilation. Les erreurs use-after-free et de tampon partiellement initialisé en PHP se manifestent à l'exécution. FFS utilise la sémantique C++ moderne — RAII, pointeurs intelligents, move semantics — pour éliminer largement cette classe d'erreurs à la compilation. Les durées de vie des objets sont suivies par le compilateur ; la mémoire est libérée de manière déterministe à la sortie du périmètre.
L'isolation des composants limite le rayon d'action. Chaque page est chargée indépendamment comme bibliothèque partagée .so. Même si un composant contenait une faille, le processus serveur central resterait non affecté. Avec WordPress, une faille de plugin s'exécute dans le même contexte d'exécution que toute l'application.
Une chaîne de dépendances, une surface d'attaque. WordPress dépend d'un écosystème de plus de 55 000 plugins et d'innombrables bibliothèques PHP. Les dépendances d'exécution de FFS sont consignées dans un manifeste unique ; chaque dépendance est empaquetée avec vérification SHA.
Preuve du monde réel : ~300 sondes d'attaque quotidiennes sur fedem.eu
Au-delà des évaluations de sécurité théoriques, fedem.eu subit quotidiennement un véritable trafic d'attaque. Les journaux enregistrent systématiquement environ 300 IP uniques lançant des scans automatisés et des tentatives d'exploitation. Les sondes les plus fréquentes :
/wp-admin,/wp-login,/wp-config.php— scanners ciblant les vulnérabilités WordPress- Toute requête de fichier
.php— tentatives d'atteindre un interpréteur PHP ou de déclencher une inclusion de fichier à distance /phpmyadmin,/pma— reconnaissance de panneaux d'administration de base de donnéeseval-stdin.php,phpunit— exploits PHPUnit RCE/.env,/.git/config,private.key— tentatives d'exfiltration de credentials- Injection JNDI (
${jndi:...}) — attaques Log4Shell résiduelles - Path traversal
../et sondes/etc/passwd— reconnaissance du système de fichiers
Chacun de ces vecteurs d'attaque n'a aucune signification dans un déploiement FFS : aucun interpréteur PHP ne tourne sur le serveur, pas de WordPress, pas de panneau d'administration de base de données, aucun fichier .php. Les scanners l'ignorent et envoient des centaines de sondes en quelques secondes.
FFS Guard : Bloquer dès la première requête
Le module Guard intégré à FFS ne se contente pas de répondre aux menaces une par une ; il analyse le comportement et place l'IP sur la liste noire.
Analyse des chemins et des motifs
Guard fonctionne sur deux couches de règles :
Chemins interdits (banned-paths.txt) — couvre les chemins qui n'existent jamais dans FFS : WordPress, Joomla, Drupal, phpMyAdmin, /cgi-bin, /admin, répertoires de métadonnées Git/SVN et répertoires système Linux. Une requête correspondant à l'un de ces chemins reçoit immédiatement un HTTP 404, avant qu'une session Wt soit créée ; le compteur de greylisting est incrémenté.
Analyse des motifs (banned-patterns.txt) — une deuxième couche regex qui inspecte le chemin et la chaîne de requête après décodage URL. Toute requête .php, eval-stdin, motifs JNDI ${...}, séquences de path traversal (../) et noms de fichiers sensibles (.env, id_rsa, .git-credentials) sont tous détectés. Un match incrémente le compteur de greylist ; au-delà du seuil, l'IP est automatiquement placée sur liste noire.
Mécanisme honeypot
L'une des fonctionnalités les plus puissantes de Guard est ses chemins honeypot : de faux chemins enregistrés sur le serveur, jamais liés depuis aucune page, jamais listés dans un sitemap, jamais référencés nulle part. Aucun visiteur légitime ou bot bien comporté ne peut les découvrir. Une IP qui accède à l'un d'eux est instantanément placée en liste noire permanente, contournant entièrement le seuil de greylist — preuve concluante de scanning automatisé.
Réponse graduée
Dès qu'une IP dépasse le seuil de greylist, elle est automatiquement mise sur liste noire. Certains signaux — un hit honeypot, des motifs critiques spécifiques — déclenchent une promotion immédiate. Toute la décision est protégée par un filtre whitelist qui charge ses règles avant le démarrage du serveur : une IP sur liste blanche ne peut jamais tomber en liste noire.
PHP vs C++ : les chiffres
| Critère | PHP / WordPress | FFS (C++) |
|---|---|---|
| Couche interpréteur | Présente — à chaque requête | Aucune |
| PHP RCE octobre 2026 (CVE-2026-109618/19) | Directement affecté | Non affecté |
| CVE-2026-87902 (WordPress RCE) | Directement affecté | Non affecté |
| Surface de dépendances | Écosystème de 55 000+ plugins | Manifeste unique, vérifié SHA |
| Gestion mémoire | GC à l'exécution, risque use-after-free | RAII, suivi des durées de vie à la compilation |
| Détection des attaques | Dépend d'un plugin tiers | Module Guard intégré |
| Blocage au niveau HTTP | Aucun | HTTP 404 avant ouverture de la session Wt |
Conclusion
La communauté PHP/WordPress se retrouve à nouveau dans un cycle de correctifs d'urgence. Cette fois, le problème n'est pas dans le code applicatif mais dans le moteur d'exécution lui-même ; les tentatives d'exploitation se poursuivent depuis septembre même au fil de l'application des patches.
FFS n'est pas concerné par ce débat. Comme le serveur n'exécute aucun interpréteur PHP, les vulnérabilités PHP sont hors de portée ; comme il n'existe pas d'écosystème de plugins WordPress, les chaînes d'attaque de type CVE-2026-87902 ne peuvent pas être construites. La sécurité n'est pas déléguée à un plugin tiers — elle est intégrée au cœur.
Les ~300 IP d'attaque quotidiennes de fedem.eu ne sont pas un problème ; elles sont une mesure de la santé de Guard. Ces mêmes chiffres auraient une signification très différente sur un système basé sur un interpréteur PHP open-source et un écosystème de 55 000 plugins.
Pour discuter de sécurité basée sur l'architecture et de FFS, contactez-nous.
Sources
- OX Security — CVE-2026-109618 & CVE-2026-109619: Two Vulnerabilities Allow Unauthenticated RCE in PHP ↩
- Patchstack — Major security alert: PHP vulnerable to critical RCE, attacks ongoing ↩
- The Hacker News — Attackers Exploit WordPress CVE-2026-87902 Within Hours of Disclosure ↩
- CISA — CISA Adds One Known Exploited Vulnerability to Catalog (2026-09-25) ↩
- The Hacker News — Attackers Exploit CVSS 10.0 Bricksforge WordPress Flaw Enabling Unauthenticated RCE ↩
- Diamatix — Critical PHP Vulnerabilities Affect WordPress and Other Web Applications: CMS Updates Alone Are Not Enough ↩
