---
title: 'Failles RCE critiques dans PHP : versions corrigées et mitigations'
description: "CVE-2026-109618 et CVE-2026-109619 (CVSS 9.2) permettent une exécution de code à distance sans authentification : versions corrigées, environnements concernés et mitigations d'attente."
pubDate: 2026-10-22
family: 'php-symfony'
tags: []
heroImage: '/images/failles-rce-critiques-php-versions-corrigees-et-mitigations.webp'
videoUrl: 'https://www.youtube.com/watch?v=uYk6lt735x4'
faq:
  - question: 'Quelles versions de PHP corrigent CVE-2026-109618 et CVE-2026-109619 ?'
    answer: "PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026. Les sources sont sur la page de téléchargement de php.net, et les distributions ainsi que les éditeurs LTS ont reçu les correctifs à l'avance : vérifie les paquets de ton fournisseur avant de compiler à la main."
  - question: 'Les mitigations suffisent-elles si je ne peux pas mettre à jour immédiatement ?'
    answer: "Non. php.net est explicite : seul un passage à une version corrigée est une solution complète. Les réglages proposés (memory_limit=-1, post_max_size bas, session.upload_progress.enabled=0, fatal_error_backtraces=0) réduisent l'exposition à des chemins d'attaque identifiés, mais ne rendent pas une installation sûre."
  - question: 'PHP 8.1 et les versions antérieures sont-ils concernés ?'
    answer: "Oui. L'alerte CERT-FR liste les branches 5.x, 7.x, 8.0.x et 8.1.x comme affectées, alors que le projet PHP n'assure plus leur support. Contacte ton éditeur pour un correctif rétroporté, ou migre vers une version maintenue ; des backports source minimaux existent pour 7.4, 8.0 et 8.1 pour ceux qui compilent eux-mêmes."
---

Le 21 octobre 2026, le projet PHP a publié **PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35** pour corriger deux vulnérabilités critiques notées **9.2/10** au CVSS 4.0. Toutes deux sont classées CWE-416 (use-after-free) et permettent à un attaquant non authentifié d'exécuter du code sur le serveur. La vidéo les présente sous le surnom « PHP2Shell ».

Aucune commande de cet article n'a été exécutée pour l'écrire, et aucun serveur PHP n'a été mis à jour ni testé ici : les faits viennent de l'[avis de sécurité php.net du 21 octobre 2026](https://www.php.net/archive/2026.php#2026-10-21-5), des deux avis GitHub Security Advisory, de l'[alerte CERTFR-2026-ALE-014](https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-014) et du [billet de la PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/). Les commandes citées proviennent de ces sources.

## Deux failles dans le moteur, pas dans ton application

Les deux problèmes se situent dans des parties que presque chaque requête traverse : la gestion mémoire et la gestion d'erreurs. C'est ce qui les rend sérieux, et aussi difficiles à corriger sans casser la compatibilité ou les extensions tierces.

- **CVE-2026-109618 — RCE par corruption OOM** ([GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)) : PHP utilise `longjmp()` pour sortir d'un contexte lors d'une erreur d'allocation mémoire. Si une requête atteint `memory_limit` au mauvais moment, les données internes de la requête ne sont que partiellement initialisées, et le nettoyage de fin de requête traite ensuite ces données invalides comme valides, ce qui corrompt la mémoire.
- **CVE-2026-109619 — RCE par état global périmé** ([GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)) : une erreur fatale au mauvais moment peut laisser l'état interne pointer vers de la mémoire qui appartenait à une requête précédente. Une requête ultérieure traitée par le même worker réutilise cette mémoire libérée avant que l'initialisation normale ne la remette à zéro.

Les deux avis portent le vecteur CVSS 4.0 `CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N` : attaque par réseau, aucun privilège requis, aucune interaction utilisateur, mais complexité élevée et conditions d'attaque présentes. La portabilité et la fiabilité d'un exploit dépendent de la compilation PHP, des extensions, du SAPI et de la disposition de l'allocateur.

## Quels environnements sont concernés

L'avis php.net cible toutes les installations PHP qui servent des requêtes web, et l'avis GitHub détaille le niveau de risque par interface :

- **Apache avec mod_php** : cas le plus exposé. Le démon de fin de requête est appelé même quand le démarrage de la requête a échoué, et une exploitation complète a été validée en HTTP avec les réglages par défaut, avant même que le code de l'application ne s'exécute.
- **PHP-FPM** : l'analyse source conclut à un SAPI vulnérable et l'exécution de code a été confirmée par des chemins applicatifs, sans exploit FPM complet démontré.
- **FrankenPHP** : il appelle le démon de fin de requête de façon inconditionnelle comme mod_php, ce qui le rend « probablement vulnérable » selon l'avis, sans validation complète.
- **LiteSpeed (LSAPI)** : le modèle se rapproche de FPM, avec des exploits applicatifs probables mais non validés.

Côté versions, l'alerte CERT-FR liste comme affectées toutes les branches 5.x, 7.x, 8.0.x et 8.1.x, ainsi que les 8.2.x antérieures à 8.2.35, les 8.3.x antérieures à 8.3.36, les 8.4.x antérieures à 8.4.27 et les 8.5.x antérieures à 8.5.12.

## Mettre à jour

1. **Identifie ta version** avec `php -v`, puis relève la configuration sensible : `php -i | grep -E 'memory_limit|post_max_size|upload_max_filesize|session.upload_progress'`.
2. **Applique les paquets de ta distribution.** php.net indique que les distributions Linux et les éditeurs LTS ont reçu les correctifs à l'avance ; privilégie donc `apt upgrade` / `dnf upgrade` sur les paquets PHP plutôt qu'une compilation manuelle. Le dépôt tiers `rpms.remirepo.net` est explicitement déconseillé ce jour-là : il n'aura pas les correctifs.
3. **Redémarre les workers** après toute modification d'`ini` : un pool FPM ou un serveur Apache ne relit pas `php.ini` sans redémarrage.
4. **Si tu restes sur une version non maintenue** (7.4, 8.0, 8.1), l'équipe sécurité PHP fournit des backports source minimaux pour ceux qui compilent eux-mêmes, et certaines distributions proposent des correctifs rétroportés.

Vérifie ensuite que la version affichée par `php -v` correspond bien à une version corrigée, et que tes workers ont redémarré.

## Mitigations en attendant la mise à jour

php.net propose des mesures d'attente, en précisant qu'elles ne remplacent pas une mise à jour. Pour **CVE-2026-109618** :

- passe `memory_limit=-1`, de préférence d'une façon que l'application ne peut pas écraser (par exemple `php_admin_value` dans le pool FPM ou la configuration Apache), puis vérifie qu'aucun réglage de pool, de répertoire ou d'application ne remet une limite finie ;
- baisse `post_max_size` : `8M` si l'application ne reçoit pas de fichiers, `32M` si elle en reçoit, en gardant `upload_max_filesize` inférieur ;
- impose des limites au niveau du serveur web ou du proxy sur la taille décodée des requêtes, le nombre de champs, de parties multipart, d'en-têtes et la profondeur d'imbrication, y compris pour les requêtes sans `Content-Length` exploitable ;
- utilise une limite de conteneur ou de cgroup comme frontière de disponibilité. L'avis déconseille explicitement `RLIMIT_AS` et `RLIMIT_DATA`, qui peuvent eux-mêmes déclencher l'échec d'allocation vulnérable.

Pour **CVE-2026-109619** :

- mets `session.upload_progress.enabled=0` puis redémarre chaque worker. Le réglage doit s'appliquer avant l'analyse de la requête : `php.ini`, un pool FPM ou la configuration serveur, pas `ini_set()` ni un `.user.ini` ;
- sur PHP 8.5, mets `fatal_error_backtraces=0` puis redémarre ;
- supprime les réglages invalides ou obsolètes appliqués par requête qui émettent des diagnostics avant l'initialisation : masquer les messages avec `error_reporting`, `display_errors` ou `@` ne protège pas ;
- corrige les erreurs fatales et les dépassements de temps d'exécution atteignables par un attaquant, notamment dans les callbacks, le traitement d'import ou d'upload et le nettoyage.

Le CERT-FR ajoute que des preuves de concept circulent depuis le 22 octobre pour des déploiements spécifiques, et propose en contournement non qualifié le blocage au niveau d'un WAF de toutes les requêtes dont le `Content-Type` vaut `multipart`, ou a minima une supervision de ces requêtes.

## Ce que ces failles ne changent pas

Le risque vient du moteur, pas de ton code métier : une application Symfony, Laravel, WordPress ou Drupal correctement écrite hérite de la vulnérabilité de la version de PHP qui l'exécute. À l'inverse, aucune mitigation listée ci-dessus ne rend une installation sûre — seul le passage à une version corrigée le fait. Enfin, PHP 8.1 et les branches antérieures ne reçoivent plus de mises à jour du projet, donc le correctif dépend de ton éditeur.

Si tu veux compléter la mise à jour du moteur par une revue du code applicatif, l'article sur [Symfony Security Auditor](/blog/decouverte-de-symfony-security-auditor/) montre comment auditer les failles qui ne se voient pas dans une analyse statique.

Pour voir les deux failles expliquées pas à pas, avec le rappel des versions à appliquer, regarde la vidéo complète.

## Questions fréquentes

**Quelles versions de PHP corrigent CVE-2026-109618 et CVE-2026-109619 ?**

PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026. Les sources sont sur la page de téléchargement de php.net, et les distributions ainsi que les éditeurs LTS ont reçu les correctifs à l'avance : vérifie les paquets de ton fournisseur avant de compiler à la main.

**Les mitigations suffisent-elles si je ne peux pas mettre à jour immédiatement ?**

Non. php.net est explicite : seul un passage à une version corrigée est une solution complète. Les réglages proposés (memory_limit=-1, post_max_size bas, session.upload_progress.enabled=0, fatal_error_backtraces=0) réduisent l'exposition à des chemins d'attaque identifiés, mais ne rendent pas une installation sûre.

**PHP 8.1 et les versions antérieures sont-ils concernés ?**

Oui. L'alerte CERT-FR liste les branches 5.x, 7.x, 8.0.x et 8.1.x comme affectées, alors que le projet PHP n'assure plus leur support. Contacte ton éditeur pour un correctif rétroporté, ou migre vers une version maintenue ; des backports source minimaux existent pour 7.4, 8.0 et 8.1 pour ceux qui compilent eux-mêmes.