# CVE-2026-109618 : RCE par état de mémoire insuffisante

> CVE-2026-109618 expliquée : comment l'état de mémoire insuffisante de PHP peut mener à l'exécution de code, quelles versions sont corrigées et que faire.

Source : https://phpsos.de/fr/php2shell/cve-2026-109618/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** CVE-2026-109618 est l'une des deux failles derrière PHP2Shell. Un état de mémoire insuffisante peut interrompre PHP alors que les données de la requête ne sont initialisées qu'en partie ; lors du nettoyage, des données invalides peuvent alors être considérées comme valides. Cela permet l'exécution de code sans authentification. L'erreur est corrigée dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.

## Qu'est-ce que CVE-2026-109618 ?

CVE-2026-109618 (identifiant GitHub GHSA-w8hw-w9fx-j79w) est une faille d'erreur de mémoire dans le cœur de PHP. Elle est évaluée à 9.2 selon CVSS v4.0. Avec [CVE-2026-109619](https://phpsos.de/fr/php2shell/cve-2026-109619/), elle forme ce que les médias désignent sous le nom de [PHP2Shell](https://phpsos.de/fr/php2shell/was-ist-php2shell/).

L'effet est ce qu'on appelle une unauthenticated Remote Code Execution : un attaquant peut exécuter du code sur le serveur web depuis l'extérieur et sans compte utilisateur. La faille appartient ainsi à la classe de vulnérabilités la plus dangereuse qu'un serveur web puisse avoir.

## Comment la faille naît, dans ses grandes lignes

Lorsque PHP traite une requête web, il crée en interne des structures de données pour cette requête, par exemple pour les données de formulaire transmises. Si PHP atteint alors sa limite de mémoire, il s'interrompt avec un état de mémoire insuffisante (out of memory). Selon php.net, cela peut se produire alors que les données de la requête ne sont initialisées qu'en partie.

À la fin de chaque requête, PHP fait le ménage et libère la mémoire. C'est précisément là que se situe l'erreur : le nettoyage peut traiter comme valides des données invalides, créées à moitié seulement. De ce comportement erroné, on peut dériver, sous certaines conditions, l'exécution de code.

Pourquoi une telle erreur est-elle si grave ? Une erreur de mémoire dans le langage de programmation touche toutes les applications qui fonctionnent dessus, quel que soit le soin apporté à leur programmation. Une installation WordPress bien entretenue avec des plugins à jour est aussi concernée qu'un ancien développement spécifique. C'est pourquoi une mise à jour de l'application n'aide pas ici, seule une mise à jour de PHP le fait.

Nous ne publions volontairement pas d'autres détails techniques sur l'exploitation. Pour la défense, ils ne sont pas nécessaires : l'essentiel est de savoir si votre serveur utilise une version corrigée et si les nouveaux processus tournent réellement.

## Versions et modes d'exécution concernés

| Branche PHP | Dernier état avant le correctif | Corrigée à partir de |
|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 |
| 8.4 | 8.4.26 | 8.4.27 |
| 8.3 | 8.3.35 | 8.3.36 |
| 8.2 | 8.2.34 | 8.2.35 |
| 8.1 et antérieures | aucune mise à jour officielle | seulement des backports minimaux du code source pour 7.4, 8.0, 8.1 |

Les modes d'exécution PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed sont concernés. L'équipe PHP estime le risque le plus élevé avec mod_php. Les distributions et hébergeurs appliquent parfois des backports, de sorte qu'un ancien numéro de version est affiché alors que l'erreur est corrigée. Ce qui fait foi, ce sont l'état des paquets et la confirmation du fournisseur.

Pour l'ordre de grandeur : Palo Alto Networks (Unit 42) a dénombré plus de 22,6 millions d'instances exposées et potentiellement vulnérables. Le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) a émis le niveau d'alerte 3 (orange) et s'attendait à une exploitation rapide à grande échelle.

## Corriger CVE-2026-109618 : mise à jour et redémarrage

Le seul remède complet est la mise à jour. Vérifiez d'abord la version et l'état des paquets. Les noms de paquets varient selon la distribution ; les exemples partent de PHP 8.3 :

```bash
php -v
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"
```

Si le journal des modifications du paquet cite le numéro CVE, le backport est installé. S'il est absent, cela ne signifie pas automatiquement que le paquet est vulnérable ; la comparaison avec le tableau des versions ou une question au fournisseur aide alors.

Après la mise à jour, tous les processus PHP doivent être redémarrés, par exemple avec `systemctl restart php8.3-fpm` ou, avec mod_php, par un redémarrage d'Apache. Comment vous assurer qu'aucun ancien worker ne tourne plus, c'est expliqué sous [Redémarrer PHP-FPM et tous les workers](https://phpsos.de/fr/php2shell/php-fpm-neustart/).

## Mesures transitoires lorsque la mise à jour n'est pas encore possible

php.net a publié des mesures transitoires pour PHP2Shell. Elles valent pour les deux failles ensemble et ne constituent expressément pas une protection complète. Que plusieurs d'entre elles portent sur des limites de mémoire correspond au déclencheur de mémoire insuffisante de CVE-2026-109618 ; il n'existe cependant pas d'attribution officielle de chaque mesure à chaque CVE.

```ini
; exemple de pool FPM, p. ex. /etc/php/8.3/fpm/pool.d/www.conf (le chemin varie selon la distribution)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M          ; 32M si des envois de fichiers sont nécessaires
php_admin_value[upload_max_filesize] = 6M    ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off
```

Les valeurs doivent être définies de telle sorte que les applications ne puissent pas les écraser, d'où `php_admin_value`. Avec `memory_limit=-1`, le service a besoin d'une limite de mémoire externe, via conteneur ou cgroup, et non via `RLIMIT_AS` ou `RLIMIT_DATA`. Sur PHP 8.5 s'ajoute `fatal_error_backtraces=0`. Tous les détails figurent sous [Mesures immédiates si vous ne pouvez pas encore appliquer le correctif](https://phpsos.de/fr/php2shell/sofortmassnahmen-ohne-patch/).

> **Important:**
> Si ni la mise à jour ni les mesures transitoires ne sont possibles immédiatement, le BSI recommande de déconnecter temporairement du réseau les serveurs web concernés.

## Comment PHP SOS aide-t-il concrètement ?

Avec notre [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/), nous refermons CVE-2026-109618 de façon structurée :

- **Recenser l'état actuel :** branche PHP, mode d'exécution, source des paquets et état des backports pour chaque serveur.
- **Installer la mise à jour** depuis la source de paquets appropriée ou, lorsque ce n'est pas possible, mettre en place proprement les mesures transitoires dans la configuration du pool ou du serveur.
- **Vérifier le redémarrage :** nous contrôlons qu'aucun ancien processus PHP ne tourne plus.
- **Attestation :** vous recevez une documentation avec les versions et états des paquets avant et après l'intervention, par exemple pour la direction, l'assureur ou la protection des données.


## Questions fréquentes

**Quelle est la gravité de CVE-2026-109618 ?**  
La faille est évaluée à 9.2 selon CVSS v4.0 et donc critique. Elle permet l'exécution de code malveillant à distance sans authentification. Pour PHP2Shell, le BSI a émis le niveau d'alerte 3 (orange).

**Suffit-il d'augmenter memory_limit ?**  
Non. php.net cite memory_limit=-1, défini de façon fixe dans la configuration du serveur, comme l'une de plusieurs mesures transitoires. Ce n'est expressément pas une protection complète et exige une limite de mémoire via conteneur ou cgroup. La solution reste la mise à jour.

**Quel identifiant GHSA correspond à CVE-2026-109618 ?**  
Dans le GitHub Security Advisory, la faille est référencée sous GHSA-w8hw-w9fx-j79w. La seconde faille PHP2Shell, CVE-2026-109619, porte l'identifiant GHSA-6wmf-4rv5-p3rp.

## Sources

- [php.net : avis de sécurité](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI : office fédéral allemand de la sécurité des technologies de l'information](https://www.bsi.bund.de/)