--- title: 'PHP2Shell : un RCE critique dans tout PHP | DevSense' description: "Analyse de PHP2Shell — CVE-2026-109618 et CVE-2026-109619, un RCE non authentifié dans le cœur de PHP : comment fonctionnent ces vulnérabilités, pourquoi elles sont dangereuses, qui s'est précipité pour corriger et comment protéger son serveur. Sans exploit fonctionnel, à but pédagogique." faq: - { question: "Qu'est-ce que PHP2Shell et quelles versions de PHP sont touchées ?", answer: "PHP2Shell est le nom commun de deux vulnérabilités du cœur de PHP, CVE-2026-109618 et CVE-2026-109619, divulguées le 21 octobre 2026. Ensemble, elles permettent une exécution de code à distance non authentifiée via le simple traitement d'une requête HTTP. Presque toutes les branches de la dernière décennie sont touchées ; les correctifs sont sortis dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, et pour 8.1/8.0/7.4 PHP a publié des backports minimaux." } - { question: "L'attaquant a-t-il besoin d'une authentification ou d'un plugin vulnérable ?", answer: "Non. C'est tout l'enjeu : la faille se trouve dans le cœur même de PHP, sur le chemin de traitement de la requête entrante, qui s'exécute avant même le code de l'application. Pas besoin de login, ni d'une CMS particulière, ni d'un plugin vulnérable — il suffit que le serveur accepte des requêtes HTTP et fasse tourner PHP. C'est pourquoi les chercheurs parlent de « 70 % du web » : c'est la part des sites sous PHP, et non le nombre de serveurs réellement compromis." } - { question: 'La vulnérabilité est-elle exploitée dans des attaques réelles ?', answer: "Au moment de l'écriture (troisième jour après la divulgation), aucune compromission publiquement confirmée via PHP2Shell n'existe, mais Cloudflare et d'autres observent déjà des scans et des tentatives d'exploitation, avec mutation du payload pour contourner les filtres. Face à un RCE non authentifié dont le CVSS atteint 9.2, la fenêtre entre « personne n'a eu le temps de mettre à jour » et « les attaques massives arrivent » se compte en jours." } - { question: 'Que faire tout de suite si une mise à jour immédiate est impossible ?', answer: 'La mise à jour de PHP est la seule solution complète. En attendant son déploiement : activez un WAF (Cloudflare, Fastly, Akamai, Imperva et les fournisseurs cloud ont déjà déployé une protection par défaut), limitez la taille du corps de requête sur le reverse proxy, désactivez session.upload_progress.enabled et, sur PHP 8.5, fatal_error_backtraces, surveillez dans les logs les erreurs de mémoire insuffisante avec « Unknown on line 0 » et les plantages de worker. Cela réduit le risque, mais ne referme pas la faille.' } published: '2026-10-23' --- # PHP2Shell : un RCE critique dans tout PHP — ce qui s'est passé et comment se protéger Il existe une sorte particulière de vulnérabilités — celles qui ne vivent ni dans le plugin de quelqu'un ni dans une ligne bancale d'une application précise, mais dans les fondations mêmes sur lesquelles repose tout le reste. PHP2Shell en est exactement une. Ce n'est pas une faille dans WordPress, ni la bévue d'un développeur isolé, ni un `eval()` oublié. C'est une fissure dans un mur porteur : dans ce code du cœur de PHP qui analyse la requête entrante avant même que ne s'exécute la première ligne de votre application. Le 21 octobre 2026, PHP a publié des versions d'urgence et divulgué deux vulnérabilités — **CVE-2026-109618** et **CVE-2026-109619** — qui, ensemble, offrent ce qu'il y a de presque pire sur le web : une **exécution de code à distance non authentifiée**. Sans login. Sans plugin vulnérable. Sans le moindre clic de la victime. Cet article est écrit le troisième jour après la divulgation, alors que le correctif existe déjà mais que la moitié d'internet n'a pas encore mis à jour — et il est donc écrit sans la moindre ligne d'exploit fonctionnel. Nous décortiquerons ce qui s'est cassé et pourquoi c'est si dangereux, mais sans mettre une arme entre les mains de quiconque. L'objectif : que vous compreniez l'ennemi et que vous fermiez la porte, pas que quelqu'un assemble une attaque à partir de notre texte. **Voir aussi :** [Attaques web et comment s'en protéger](web-attacks-and-prevention) · [Intégrations résilientes](resilient-external-integrations) · [Observabilité et monitoring](observability-monitoring-laravel) · [Déploiement sans interruption](zero-downtime-deployment-laravel) ## Sommaire * [En bref : l'essentiel en trente secondes](#tldr) * [Pourquoi une faille dans le cœur, c'est une autre échelle](#why-core) * [Chronologie : comment une IA a trouvé une faille dans tout PHP](#timeline) * [Deux portes : ce qui se cache derrière les deux CVE](#two-doors) * [À quel point les dégâts sont graves](#impact) * [Le point de vue de l'attaquant : modèle de menace sans mode d'emploi](#attacker) * [Qui s'est déjà précipité pour corriger](#responders) * [Y a-t-il déjà des victimes](#victims) * [Comment se protéger : étape par étape](#defense) * [Comment repérer l'attaque dans vos logs](#detection) * [PHP est vivant — et en voici la preuve](#php-alive) * [Checklist](#checklist) * [Quiz d'auto-évaluation](#self-test-quiz) --- ## En bref : l'essentiel en trente secondes * **Quoi :** deux vulnérabilités du cœur de PHP sous le nom commun PHP2Shell — CVE-2026-109618 et CVE-2026-109619. * **Le danger :** exécution de code à distance non authentifiée (RCE), gravité jusqu'à **CVSS 9.2**. * **Qui est concerné :** pratiquement toutes les branches de PHP de la dernière décennie, indépendamment de la CMS et du framework. * **Où c'est corrigé :** PHP **8.5.12, 8.4.27, 8.3.36, 8.2.35** ; pour 8.1/8.0/7.4 — des backports minimaux de l'équipe PHP. * **Que faire :** mettre à jour PHP et redémarrer PHP-FPM et les workers de file d'attente. Immédiatement. Le reste n'est que béquilles temporaires. Si vous lisez ceci depuis une production tournant sur une version non corrigée — fermez l'article, mettez à jour, revenez. Sérieusement. --- ## Pourquoi une faille dans le cœur, c'est une autre échelle La plupart des vulnérabilités web ressemblent à une fenêtre non verrouillée dans un appartement bien précis : un bug dans un plugin, une injection SQL dans un contrôleur maison, un contrôle de droits oublié. Vous réparez l'appartement — la fenêtre est fermée. PHP2Shell, c'est un défaut d'usine dans la serrure montée sur une porte sur deux de la planète. PHP traite la requête entrante par couches. D'abord le cœur : il lit les en-têtes, analyse le corps de la requête, remplit les superglobales `$_POST`, `$_FILES`, `$_COOKIE`. Et ce n'est qu'ensuite que la main passe à votre code — au routeur de Laravel, au cœur de WordPress, à la première ligne que vous avez écrite. PHP2Shell vit **sur la première couche**. Le chemin vulnérable s'exécute chez tout le monde et à chaque fois, simplement parce que le serveur a accepté une requête. De là vient la fameuse formule des chercheurs sur « 70 % d'internet ». Il importe de comprendre ce que cela signifie : PHP sert environ 70 % de tous les sites du monde, et la surface d'attaque théorique, c'est eux tous. Cela ne veut **pas** dire que 70 % des sites sont déjà compromis ni que chacun d'eux est forcément percé en une requête. Cela veut dire que le plafond de cette vulnérabilité a la taille du web. --- ## Chronologie : comment une IA a trouvé une faille dans tout PHP Cette histoire comporte un détail qui la fera entrer dans les manuels — et ce n'est pas la vulnérabilité elle-même. Elle n'a pas été trouvée par un audit manuel classique, mais par le tandem d'un humain et d'une IA. Les chercheurs de Wiz ont mené leurs recherches à l'aide de modèles modernes et, selon leurs propres mots, le modèle a apporté une « contribution inestimable » non seulement à la découverte, mais aussi à la transformation des trouvailles en exploits fonctionnels contre plusieurs cibles — « en quelques heures ». Nous vivons dans un monde où le fuzzing du cœur de PHP n'est plus mené par le seul humain avec son débogueur, mais aussi par une IA, et les deux côtés de la barricade l'ont déjà compris. Chronologie 2026 (d'après Wiz) : | Date | Événement | |------|---------| | 19 août | Découverte de la première des vulnérabilités | | 20 août | RCE non authentifié confirmé contre Drupal | | 21 août | RCE non authentifié confirmé contre WordPress | | 24 août | Transmis à l'équipe de sécurité de PHP | | 21 septembre | PHP confirme le problème et lance une correction coordonnée | | 21 octobre | Publication des correctifs et divulgation publique | Presque deux mois — entre la transmission discrète à l'équipe PHP et la divulgation publique. C'est bien là le processus correct et « adulte » : d'abord on répare, ensuite on raconte. L'article que vous lisez est paru deux jours après la dernière ligne de ce tableau. --- ## Deux portes : ce qui se cache derrière les deux CVE Sous le nom de PHP2Shell se cachent deux défauts distincts — deux portes vers une même pièce. Différents chercheurs et éditeurs décrivent les bugs sous-jacents avec de légères divergences de détail, et sous chaque CVE se cache plutôt une classe de problèmes qu'une seule ligne. Nous restons délibérément au niveau de la mécanique — « ce qui s'est exactement cassé » — sans descendre jusqu'à la recette pour remonter jusqu'au shell. ### CVE-2026-109618 — traitement des données entrantes de la requête La première porte s'ouvre à l'étape où PHP analyse le corps d'une requête POST et le traitement des uploads. Le problème tient à la gestion de la mémoire sur ce chemin : pour une certaine forme de données en entrée, le cœur accède à de la mémoire qu'il a déjà libérée, ou fausse la comptabilité lors de son allocation. Là où il devrait y avoir un soigneux « alloue — utilise — libère » s'ouvre une fenêtre dans laquelle l'état de la mémoire cesse de correspondre à ce qu'attend le code. Or une gestion défaillante de la mémoire en code natif, c'est un tremplin classique : de là part aussi bien un chemin vers la fuite de morceaux de la mémoire du processus (et donc le contournement de protections comme l'ASLR) que vers le contrôle de l'exécution. Détail essentiel : ce chemin ne requiert ni authentification ni configuration particulière de l'application. Il suffit que PHP analyse automatiquement le corps de la requête — ce qu'il fait toujours. ### CVE-2026-109619 — état résiduel entre les requêtes La seconde porte est plus subtile et, en un sens, plus élégante. PHP-FPM est un processus longue durée : un même worker sert requête après requête sans recharger le framework (pourquoi c'est à la fois rapide et dangereux, nous l'avons détaillé dans l'article sur les [files d'attente en production](laravel-queues-production#memory)). Si, après le traitement d'une requête, un état « résiduel » demeure dans le worker — par exemple celui du mécanisme de suivi de la progression des uploads de fichiers (`session.upload_progress`) ou de la constitution des traces d'erreurs fatales — alors la requête suivante peut tomber sur ces données périmées. Une requête prépare le piège, la seconde tombe dedans. La perfidie, c'est qu'une partie de ces mécanismes fonctionne même si l'application ne les a jamais explicitement appelés. `session.upload_progress` est activé par défaut et se déclenche sans le moindre `session_start()` dans votre code. > [!NOTE] > Retenez deux réglages de la seconde porte — `session.upload_progress.enabled` et (sur PHP 8.5) `fatal_error_backtraces`. Plus bas, dans la section sur la défense, ce sont précisément eux que nous couvrirons si une mise à jour immédiate est impossible. --- ## À quel point les dégâts sont graves Le RCE, c'est le sommet de la chaîne alimentaire des vulnérabilités. Pas « des données ont fuité », pas « une page a été remplacée », mais **du code étranger s'exécute sur votre serveur avec les droits de votre processus web**. Ce que cela signifie en pratique : * **Contrôle total de l'application.** L'attaquant lit et modifie n'importe quoi dans le code et les fichiers accessibles à `www-data`. * **Accès aux secrets.** Le `.env` avec le mot de passe de la base, les clés des systèmes de paiement, les tokens d'API, l'`APP_KEY` — tout ce que le processus peut lire, l'attaquant le lit aussi. * **Toute la base de données.** Pas via une injection astucieuse, mais directement — avec les mêmes identifiants que l'application. * **Déplacement latéral.** Le serveur devient une tête de pont : de là, on scanne le réseau interne, on attaque les services voisins, on s'installe via un web-shell. * **Le silence.** Une exploitation réussie peut renvoyer un banal HTTP 200 sans faire tomber le worker. De l'extérieur — rien ; à l'intérieur — l'intrus est déjà chez vous. Pour un site comme DevSense, où il n'y a ni paiements ni données personnelles d'utilisateurs au-delà du minimum, le dommage direct est moindre que pour une boutique en ligne ou une banque. Mais « moindre » ne veut pas dire « nul » : même notre serveur, c'est un accès à la BDD, aux clés de messagerie, à l'infrastructure de déploiement, et une excellente tête de pont pour attaquer les autres. C'est pourquoi [nous avons mis à jour PHP](../tools/dockerfile-php-best-practices) le jour même. --- ## Le point de vue de l'attaquant : modèle de menace sans mode d'emploi Regarder la vulnérabilité avec les yeux de l'attaquant est utile — on comprend mieux où placer la défense. Mais « le point de vue de l'attaquant » signifie ici **le modèle de menace et l'économie de l'attaque**, et non une recette pas à pas. La recette, nous ne la donnerons pas par principe : elle a deux jours, elle frappe un RCE non authentifié, et la moitié des serveurs n'est pas encore fermée. Ce qui meut l'attaquant dans une telle situation : * **La masse prime sur la précision.** Quand « tout le web » est vulnérable, personne ne choisit sa victime avec soin. On lance un large scan : on essaie tout le monde, on s'installe chez ceux où ça a marché. Votre site est visé non parce que vous êtes intéressant, mais parce que vous existez et répondez aux requêtes. * **La course contre le correctif.** La valeur d'un exploit est maximale dans les premiers jours, tant que la masse n'a pas mis à jour. De là le pic d'activité juste après la divulgation — il est déjà observé. * **Le contournement des filtres.** Dès que les éditeurs de WAF ont déployé leurs règles, les attaquants ont commencé à muter le payload pour y échapper. Cloudflare l'a déjà constaté. Conclusion pour vous : le WAF, c'est du temps gagné, pas une victoire. Seul le correctif l'emporte. * **L'automatisation est aussi de leur côté.** Si une IA a aidé à trouver et à remonter la vulnérabilité en quelques heures du côté des chercheurs, alors du côté des attaquants aussi le cycle « du CVE au scanner de masse » est devenu plus court que jamais. Le sens pratique de cette optique est unique : ne comptez pas sur le fait que « mon petit site n'intéresse personne ». Dans un monde d'attaques en diffusion générale, il n'existe pas de sites inintéressants. --- ## Qui s'est déjà précipité pour corriger Bonne nouvelle : l'industrie a réagi à PHP2Shell comme un organisme coordonné, et c'est sans doute la meilleure illustration du fait que l'écosystème PHP est bien vivant et en bonne santé. La divulgation a été coordonnée — à l'heure H, la protection était déjà en place. * **Cloudflare** a déployé ses règles WAF **environ 9 heures avant la divulgation publique** et a activé la protection par défaut le 21 octobre à 3 h 02 UTC — sur tous les plans, y compris gratuit, sans aucune action du client. Selon ses données, il voit déjà passer du trafic d'attaque et ses mutations. * **Fastly, Akamai, Imperva** — ont déployé leurs propres règles de protection pour les clients incapables de mettre à jour instantanément. * **AWS, Google Cloud, Microsoft, Vercel** — ont publié des guides de réponse et une protection au niveau de leurs plateformes. * **Automattic** (l'entreprise derrière WordPress.com) et d'autres acteurs de l'écosystème — figurent parmi ceux qui ont aidé à la réponse coordonnée. Il faut saluer à part l'équipe de sécurité de PHP elle-même : deux mois de travail discret, une sortie synchronisée des correctifs sur toutes les branches supportées, et même des backports pour les branches dont le support officiel est déjà terminé (7.4, 8.0, 8.1). Pour un projet que l'on enterre depuis des années dans les commentaires, c'est une réaction exemplaire. --- ## Y a-t-il déjà des victimes Ici, il faut être honnête et ne pas alimenter la panique. **Le troisième jour après la divulgation, aucune compromission publiquement confirmée via PHP2Shell n'existe.** Aucune grande organisation n'a pour l'instant été nommée comme victime. Mais plusieurs choses sont connues avec certitude : * Des exploits fonctionnels existent — ils ont été démontrés par les chercheurs contre des images récentes de WordPress, Drupal et Joomla. C'est une démonstration de la surface, pas la racine du problème : l'affaire n'est pas dans ces CMS, mais dans PHP en dessous. * Les scans et tentatives d'exploitation sont déjà en cours — en témoignent à la fois Cloudflare, qui observe du trafic d'attaque, et les bulletins du secteur, qui constatent « l'apparition de tentatives d'exploitation ». * L'absence de victimes publiques au troisième jour, ce n'est pas « on l'a échappé belle », mais « il est encore trop tôt ». Entre le scan de masse et les premiers rapports publics de compromissions, il s'écoule généralement des semaines. La fenêtre dans laquelle il faut réussir à mettre à jour est ouverte en ce moment même. Plus simplement : le silence au tableau n'est pas la fin de l'alerte, mais une longueur d'avance. Mettez-la à profit. --- ## Comment se protéger : étape par étape ### 1. Mettez à jour PHP — c'est la seule vraie solution Tout le reste ci-dessous n'est que des béquilles qui achètent du temps. Seul le correctif referme la faille. ```bash # Debian/Ubuntu, dépôt Ondřej Surý (comme chez nous) sudo apt-get update sudo apt-get install --only-upgrade -y \ $(dpkg-query -W -f='${db:Status-Abbrev} ${Package}\n' 'php8.5*' | awk '$1 == "ii" {print $2}') # Redémarrer tout ce qui garde l'ancien binaire en mémoire sudo systemctl restart php8.5-fpm sudo supervisorctl restart all # les workers de file d'attente sont aussi du PHP ``` Versions cibles : **8.5.12 / 8.4.27 / 8.3.36 / 8.2.35** ou plus récentes. Vérifiez à la fois le CLI et le FPM : ```bash php -v | head -1 /usr/sbin/php-fpm8.5 -v | head -1 ``` > [!WARNING] > Le redémarrage de PHP-FPM est obligatoire. Le processus longue durée garde en mémoire l'ancien binaire, vulnérable, même après `apt upgrade`, tant qu'on ne l'a pas redémarré. Même chose pour les workers de file d'attente sous Supervisor ou Horizon — ils ne voient pas le nouveau PHP tant qu'ils ne sont pas redémarrés. Pour le détail de la mise à jour et de la reconstruction des images — voir notre analyse de l'[image de production pour PHP](../tools/dockerfile-php-best-practices). ### 2. Montez un WAF Si vous êtes derrière Cloudflare — la protection est déjà activée par défaut, vérifiez seulement que les règles sont en mode blocage. Fastly, Akamai, Imperva et les fournisseurs cloud ont déployé l'équivalent. N'oubliez pas la mutation du payload : le WAF est une mesure temporaire. ### 3. Limitez le corps de requête en bordure Sur le reverse proxy (nginx, load balancer), coupez les corps de requête anormalement gros avant qu'ils n'atteignent PHP. Cela ne soigne pas, mais fait tomber une bonne part des tentatives automatiques. ### 4. Couvrez la seconde porte par la configuration Si le correctif n'est pas encore déployé — désactivez les mécanismes par lesquels fonctionne CVE-2026-109619. DevSense ne les utilise pas, cela n'a aucun impact sur le fonctionnement du site : ```ini ; /etc/php/8.5/fpm/conf.d/99-hardening.ini session.upload_progress.enabled = 0 fatal_error_backtraces = 0 ; PHP 8.5 uniquement expose_php = Off ``` ```bash sudo systemctl restart php8.5-fpm ``` Cela réduit l'exposition, mais **ne remplace pas la mise à jour**. --- ## Comment repérer l'attaque dans vos logs Une défense sans observabilité est aveugle. Voici les indicateurs honnêtes à surveiller (aucun ne prouve à lui seul une compromission — c'est la corrélation qui compte) : * **Dans les logs de PHP-FPM :** `Allowed memory size ... exhausted` en combinaison avec `Unknown on line 0`. La mention `on line 0` signifie que le plantage s'est produit à l'étape d'initialisation de la requête, avant même le code de l'application — c'est précisément là que vit la première porte. * **Plantages de workers :** des segfaults (`SIGSEGV`, `exited on signal 11`) dans les logs de PHP-FPM ou d'Apache, surtout en séries. * **Requêtes anormales :** des POST avec des noms de champs anormalement longs (de l'ordre du mégaoctet), des données binaires et des octets nuls dans les valeurs de champs. * **Cookie `PHPSESSID` anormalement gros** — l'un des signes pointés par les chercheurs eux-mêmes. * **Processus orphelins lancés par l'utilisateur web :** un shell lancé sous `www-data`, ce n'est plus un signe, mais presque une condamnation : ```bash ps -eo user,pid,ppid,cmd | awk '$1=="www-data"' | grep -vE "php-fpm|nginx" sudo grep -h "Unknown on line 0" /var/log/php8.5-fpm.log* 2>/dev/null | tail ``` Comment intégrer ces signaux dans un monitoring et des alertes permanents — dans l'article sur l'[observabilité](observability-monitoring-laravel). --- ## PHP est vivant — et en voici la preuve On enterre PHP avec une régularité enviable. « Langage mort », « legacy », « tout le monde est parti sur Node et Go » — cette nécrologie s'écrit chaque année. PHP2Shell, aussi paradoxal que cela paraisse, est un argument exactement dans l'autre sens. Premièrement, une vulnérabilité d'une telle ampleur n'est possible que pour une technologie sur laquelle repose réellement une immense part du web. Les langages morts ne font pas les titres de la CISA et n'obligent pas Cloudflare à déployer une protection neuf heures avant la divulgation. Dans un trou de la taille de 70 % d'internet ne tombe que ce qui soutient cet internet. Deuxièmement — et c'est l'essentiel — regardez la réaction. L'équipe de sécurité de PHP a mené une correction coordonnée exemplaire, publié les correctifs sur toutes les branches de façon synchrone, et même backporté les correctifs sur des branches sans support officiel. Toute l'industrie — d'Automattic à AWS — a fonctionné comme un seul organisme. Ce n'est pas ainsi que se comporte un projet mourant, mais un écosystème mûr et vivant, aux processus adultes. PHP 8.5 avec les property hooks, la visibilité asymétrique, les propriétés typées et l'opérateur pipe — c'est un langage moderne, pas une pièce de musée. Le vivant a un système immunitaire, et en octobre 2026 il a réagi vite et de façon coordonnée. Plus vivant que jamais — notamment parce qu'il sait cicatriser vite de telles blessures. --- ## Checklist 1. PHP mis à jour vers 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 ou plus récent — à la fois le CLI et PHP-FPM. 2. PHP-FPM redémarré ; workers de file d'attente (Supervisor/Horizon) redémarrés. 3. Vérifié que le processus FPM ne garde pas l'ancien binaire (`/proc//exe` sans la mention `(deleted)`). 4. WAF activé et en mode blocage ; souvenez-vous du caractère temporaire de cette mesure. 5. Taille du corps de requête limitée en bordure. 6. Si le correctif n'est pas déployé — `session.upload_progress.enabled` et `fatal_error_backtraces` désactivés. 7. Logs vérifiés pour `Unknown on line 0`, les segfaults et les shells sous `www-data`. 8. Images de conteneurs reconstruites et redéployées si PHP est installé depuis une image. --- ## En résumé PHP2Shell est un cas rare où une vulnérabilité est intéressante non seulement par ce qu'elle casse, mais aussi par ce qu'elle révèle. Ce qu'elle casse, c'est le fondement : un RCE non authentifié dans le cœur sur lequel repose une grande part du web. Et ce qu'elle révèle, c'est que l'écosystème autour de ce cœur est vivant, rapide et coordonné. Le correctif est sorti, les gros acteurs ont fait rempart pour ceux qui n'ont pas eu le temps, et de vous on attend une seule action, simple : mettre à jour et redémarrer. Faites-le avant que la longueur d'avance ne s'épuise. --- ## Quiz d'auto-évaluation ### Question 1 : Pourquoi PHP2Shell est-elle plus dangereuse qu'une vulnérabilité typique dans un plugin de CMS ? - A) Parce qu'elle est plus difficile à détecter par les scanners. - B) Parce qu'elle est dans le cœur de PHP, sur le chemin de traitement de la requête, et se déclenche avant le code de l'application — sans authentification et indépendamment de la CMS ou du framework. - C) Parce qu'elle ne touche que les versions obsolètes de PHP.
Afficher la réponse **Réponse : B** Le défaut vit sur la première couche de traitement de la requête, commune à toutes les applications PHP. Ni login, ni CMS particulière, ni plugin vulnérable ne sont nécessaires — il suffit que le serveur accepte des requêtes et exécute PHP.
### Question 2 : Pourquoi faut-il absolument redémarrer PHP-FPM et les workers de file d'attente après `apt upgrade` ? - A) Sinon les fichiers de configuration ne seront pas mis à jour. - B) Parce que les processus longue durée gardent en mémoire l'ancien binaire PHP, vulnérable, tant qu'on ne les a pas redémarrés. - C) Pour vider l'OPcache des pages statiques.
Afficher la réponse **Réponse : B** PHP-FPM et les workers de file d'attente sont des processus longue durée. Ils continuent d'exécuter l'ancien binaire chargé en mémoire, même après la mise à jour du paquet, tant qu'ils ne sont pas redémarrés. On peut le vérifier via le lien symbolique `/proc//exe`.
### Question 3 : Pourquoi le WAF est-il du temps gagné et non une solution complète ? - A) Le WAF ralentit le site et il faut le désactiver. - B) Parce que les attaquants mutent le payload pour contourner les règles — seule la mise à jour de PHP referme la faille. - C) Parce que le WAF ne protège que des attaques authentifiées.
Afficher la réponse **Réponse : B** Les règles du WAF filtrent les formes d'attaque connues, mais les attaquants mutent déjà le payload pour y échapper (Cloudflare l'a constaté). Le WAF réduit le risque et achète du temps pour la mise à jour, mais la seule solution complète, c'est le correctif.