> ## Documentation Index
> Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# php2shell (CVE-2026-109618 et CVE-2026-109619) : deux RCE dans le cœur de PHP

> Deux exécutions de code à distance sans authentification dans PHP lui-même, corrigées le 21 octobre. Qui est touché, comment mettre à jour, ce que nous avons fait.

*Publié le 21 octobre 2026*

> [!WARNING]
>
> **CVE-2026-109618 et CVE-2026-109619, CVSS v4.0 9,2 chacune.** Deux exécutions de code à distance sans authentification dans le cœur de PHP, quelle que soit l'application. Les détails ont fuité avant la fin de l'embargo et des attaques sont observées depuis le 21 octobre au matin. Corrigé dans **PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35**, publiés le 21 octobre. Mettez à jour maintenant.

## Le problème en deux phrases

Une requête HTTP sans authentification peut corrompre l'état interne de PHP et mener à l'exécution de code, avant même que l'application ne démarre. WordPress, Magento, PrestaShop ou une application maison : tout site servi par PHP est concerné, qu'il soit à jour ou non.

Selon l'équipe de sécurité de PHP, toutes les installations qui servent des requêtes web sont touchées : PHP-FPM, Apache avec mod\_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé avec **mod\_php**, pour lequel un exploit fonctionnel a été démontré.

| CVE | Nom | Mécanisme |
| - | - | - |
| CVE-2026-109618 | RCE via corruption sur manque de mémoire | Un dépassement de mémoire interrompt PHP alors que les données internes de la requête ne sont que partiellement initialisées ; le nettoyage de fin de requête les traite ensuite comme valides |
| CVE-2026-109619 | RCE via état global périmé | Un état interne lié à une requête survit à la libération de sa mémoire ; la requête suivante traitée par le même processus peut l'utiliser avant qu'il ne soit réinitialisé |

Les détails techniques complets sont dans les avis [GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) et [GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp).

## Chronologie

| Date (UTC) | Événement |
| - | - |
| 20 octobre | Fuite des deux failles, prévues pour une publication coordonnée le 22 octobre. PHP annonce une version de sécurité pour le lendemain |
| 21 octobre, 07:43 | Premières attaques observées ; des règles WAF d'urgence sont déployées par les principaux fournisseurs |
| 21 octobre, après-midi | Publication de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, en avance sur l'horaire annoncé (14:00) |

Le correctif public indique désormais aux attaquants où regarder : les attaques vont s'intensifier sur les serveurs qui ne sont pas encore à jour.

## Ce que nous avons fait chez OnetSolutions

**Mitigation appliquée avant le correctif.** Le 21 octobre, avant la publication des versions corrigées, nous avons désactivé `session.upload_progress` sur tous nos serveurs d'hébergement web, pour toutes les versions de PHP proposées (de 7.0 à 8.4). Nous avons contrôlé les valeurs effectives version par version.

**Correctif installé le jour même.** Nos équipes étaient mobilisées dès la fuite et ont suivi la situation en continu. Les versions corrigées de PHP ont été installées sur l'ensemble de notre hébergement web le jour même de leur publication, pour toutes les versions proposées, y compris PHP 7.0 à 8.1 qui reçoivent un correctif rétroporté. La mitigation reste en place en complément.

**Surveillance.** L'analyse antimalware en temps réel reste active sur nos serveurs d'hébergement web.

> [!NOTE]
>
> La mitigation réduit la surface d'attaque, elle ne la supprime pas. L'équipe de PHP est claire : seule la mise à jour corrige ces failles.

## Évaluer son exposition

| Profil | Exposition | Action |
| - | - | - |
| Hébergement web OnetSolutions, PHP 8.2 ou plus récent | Traitée par nous | Rien à faire |
| Hébergement web OnetSolutions, PHP 7.0 à 8.1 | Traitée par nous, correctif rétroporté | Rien d'urgent ; [passer en PHP 8.2 ou plus](https://help.onetsolutions.net/fr/web-hosting/php-version) reste recommandé |
| VPS qui sert du PHP sur Internet | **Critique** | Mettre à jour maintenant, mitigation en attendant le paquet |
| VPS avec Apache et mod\_php | **Critique**, exploit démontré | Mettre à jour en priorité absolue |
| Site derrière un CDN ou un WAF, serveur d'origine joignable directement | **Critique** | Le WAF se contourne : restreindre l'origine aux adresses du proxy |
| VPS sans PHP | Nulle | Rien à faire |

> [!NOTE]
>
> Vous administrez votre VPS : c'est à vous d'y installer le correctif. Les sections suivantes donnent les commandes.

## Mettre à jour PHP

Les distributions Linux ont reçu les correctifs en avance : leurs paquets arrivent dans les heures qui suivent la publication.

```bash theme={null}
# Debian, Ubuntu
apt update && apt install --only-upgrade 'php*'

# RHEL, AlmaLinux, Rocky Linux
dnf upgrade 'php*'
```

Redémarrez ensuite tous les processus PHP : l'une des deux failles vit dans l'état que conserve un processus d'une requête à l'autre.

```bash theme={null}
# Debian, Ubuntu
systemctl restart 'php*-fpm.service'
systemctl restart apache2 2>/dev/null

# RHEL, AlmaLinux, Rocky Linux
systemctl restart php-fpm
systemctl restart httpd 2>/dev/null

# Contrôler la version servie
php -v
```

> [!WARNING]
>
> Si vous utilisez le dépôt Remi (`rpms.remirepo.net`), il ne publiera pas de mise à jour le 21 octobre. L'équipe de PHP recommande de passer aux paquets de votre distribution ou de compiler depuis les sources.

**PHP 8.1 et antérieur.** Le projet PHP ne publie plus de version pour ces branches. Vu la gravité, son équipe de sécurité a tout de même publié des correctifs minimaux pour [PHP 7.4](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619), [8.0](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619) et [8.1](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619), à compiler soi-même. Certaines distributions et offres de support étendu les reprennent dans leurs paquets : renseignez-vous auprès de votre fournisseur, ou passez à une version maintenue.

## Si vous ne pouvez pas mettre à jour tout de suite

L'équipe de PHP liste des mesures qui ferment certains chemins d'attaque connus. Elle prévient qu'elles ne rendent pas une installation sûre.

### Contre CVE-2026-109619 (état global périmé)

Désactivez le suivi de progression des envois de fichiers, dans le `php.ini` ou un fichier `conf.d` chargé au démarrage, puis redémarrez tous les processus. Un `ini_set()` ou un `.user.ini` ne suffit pas : le réglage doit s'appliquer avant l'analyse de la requête.

```bash theme={null}
# Debian, Ubuntu : un fichier pour chaque version et chaque SAPI
for dir in /etc/php/*/*/conf.d; do
  printf 'session.upload_progress.enabled = 0\n' > "$dir/zz-php2shell.ini"
done
systemctl restart 'php*-fpm.service'
systemctl restart apache2 2>/dev/null
```

```bash theme={null}
# RHEL, AlmaLinux, Rocky Linux
printf 'session.upload_progress.enabled = 0\n' > /etc/php.d/zz-php2shell.ini
systemctl restart php-fpm
systemctl restart httpd 2>/dev/null
```

Pour l'imposer dans un pool PHP-FPM précis, ajoutez à sa configuration (par exemple `/etc/php/8.3/fpm/pool.d/www.conf`) :

```ini theme={null}
php_admin_flag[session.upload_progress.enabled] = off
```

Sur PHP 8.5, ajoutez aussi `fatal_error_backtraces = 0` : cela ferme le chemin d'attaque confirmé par les traces d'erreurs fatales.

### Contre CVE-2026-109618 (manque de mémoire)

Réduisez la taille maximale des requêtes : `post_max_size = 8M` si l'application ne reçoit pas de fichiers, `32M` si elle en reçoit, avec `upload_max_filesize` inférieur à `post_max_size`.

L'équipe de PHP suggère aussi `memory_limit = -1`, à condition qu'une limite de mémoire par conteneur ou par cgroup protège le serveur. Sans cette limite, un seul processus peut consommer toute la mémoire de la machine : ne l'appliquez pas à la légère.

### Vérifier

```bash theme={null}
# PHP en ligne de commande
php -i | grep -E 'session\.upload_progress\.enabled|post_max_size'

# PHP-FPM (adaptez la version : php-fpm8.3 sur Debian et Ubuntu, php-fpm sur RHEL)
php-fpm8.3 -i | grep -E 'session\.upload_progress\.enabled|post_max_size'
```

Attendu : `session.upload_progress.enabled => Off`.

## Chercher des traces

Des attaques ont précédé le correctif. Sur un serveur qui a tourné avec une version vulnérable, cherchez les fichiers PHP créés ou modifiés depuis le 20 octobre :

```bash theme={null}
# Fichiers PHP modifiés depuis le 20 octobre, du plus récent au plus ancien
find /var/www -type f -name '*.php' -newermt '2026-10-20' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort -r | head -50
```

Un fichier que vous n'avez pas déployé, en particulier dans un répertoire d'envoi de fichiers, signe une compromission. Traitez alors le serveur comme compromis : restaurez depuis une sauvegarde antérieure au 20 octobre et renouvelez les secrets qu'il détient.

## Et après ?

La mitigation peut rester en place après la mise à jour : peu d'applications utilisent le suivi de progression des envois de fichiers.

Le vrai sujet est ailleurs. PHP 8.1 et les versions antérieures ne reçoivent plus de versions officielles, et PHP 8.2 arrive en fin de vie le 31 décembre 2026. Si un de vos sites en dépend, c'est le moment de le migrer. Pour toute question, [notre équipe est disponible](https://help.onetsolutions.net/fr/console/support) depuis votre espace client.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.