# PHP 8.1 et antérieur : ce qui s'applique maintenant

> PHP 8.1 et antérieur n'ont aucune mise à jour officielle contre PHP2Shell. Ce que signifient les backports, comment sécuriser le serveur et migrer.

Source : https://phpsos.de/fr/php2shell/php-8-1-und-aelter/  
É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 :** pour la faille de sécurité PHP2Shell sur PHP 8.1, il n'existe aucune mise à jour officielle. Le projet PHP ne fournit pour 7.4, 8.0 et 8.1 que des backports minimaux du code source, pas de versions prêtes à l'emploi. Qui exploite ces versions a besoin d'un backport confirmé de son fournisseur ou de mesures transitoires, et devrait planifier dès maintenant le passage à une version prise en charge.

## Existe-t-il une mise à jour contre la faille de sécurité de PHP 8.1 ?

Pas de la part du projet PHP. Le 21 octobre 2026, des corrections officielles ne sont parues que pour les branches prises en charge : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour officielles.

Elles sont néanmoins concernées. Selon la presse spécialisée, les versions vulnérables remontent presque sans interruption jusqu'à PHP 5.4. Qui exploite l'une de ces versions accessible publiquement a donc une faille critique avec un CVSS v4.0 de 9.2 sans correctif prêt à l'emploi.

Pour de nombreuses entreprises, c'est une surprise, car de tels systèmes fonctionnent souvent depuis des années de manière stable et discrète. Qu'une version ne reçoive plus de mises à jour ne se remarque pas au quotidien, jusqu'à ce qu'une faille comme PHP2Shell apparaisse. Les backports du code source pour 7.4, 8.0 et 8.1 sont une exception et non une reprise de la maintenance régulière.

## Ce que signifient les backports du code source

Pour 7.4, 8.0 et 8.1, il existe des backports minimaux du code source. Ce sont des corrections dans le code source reportées sur ces anciennes branches. Elles ne sont pas une version officielle avec numéro de version, paquet testé et journal des modifications.

Concrètement : quelqu'un doit reprendre le backport, recompiler PHP à partir de celui-ci, tester et déployer. Cela peut se faire de trois façons :

- **Votre distribution** reprend la correction dans ses paquets, par exemple dans le cadre d'une maintenance longue.
- **Votre hébergeur** construit ses propres paquets PHP et applique le backport.
- **Vous-même** ou un prestataire compilez PHP à partir des sources. C'est exigeant et doit être répété à chaque nouvelle faille.

Savoir si votre système a reçu un backport se vérifie dans le journal des modifications du paquet :

```bash
apt changelog php8.1-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619"      # Debian/Ubuntu
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619"    # famille RHEL
```

Les noms de paquets varient selon la distribution et la source de paquets. Si une entrée manque, interrogez le fournisseur. Comment la vérification fonctionne en détail, c'est expliqué sous [Bien vérifier la version de PHP et l'état des correctifs](https://phpsos.de/fr/php2shell/php-version-pruefen/).

## Sécuriser l'ancien serveur jusqu'à la migration

Tant qu'aucun backport confirmé n'est en service, les mesures transitoires de php.net s'appliquent : `memory_limit=-1` non écrasable avec limite de mémoire via cgroup, `post_max_size` de 8M ou 32M avec `upload_max_filesize` en dessous et `session.upload_progress.enabled=0` dans la configuration du serveur, puis redémarrage de tous les workers. Elles ne sont pas une protection complète. Détails sous [Mesures immédiates si vous ne pouvez pas encore appliquer le correctif](https://phpsos.de/fr/php2shell/sofortmassnahmen-ohne-patch/).

S'y ajoutent des mesures qui réduisent l'accessibilité : espaces d'administration uniquement via VPN ou adresses IP autorisées, arrêt des sites web inutiles, accès au serveur étroitement limités. Le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) recommande de déconnecter temporairement du réseau les serveurs sans mise à jour. Pour une ancienne application difficile à migrer, une solution cloisonnée peut être la réponse la plus honnête, plutôt qu'une exploitation sur l'Internet ouvert.

> **Agir immédiatement:**
> Si un serveur sous PHP 8.1 ou antérieur est resté exposé sans protection sur le réseau depuis le 17 octobre, prenez cela au sérieux : le BSI s'attendait à une exploitation rapide à grande échelle. Sauvegardez les journaux à partir du 20 octobre et faites rechercher des traces sur le serveur avant de migrer.

## Planifier la migration : vers quelle version ?

L'objectif est une version que le projet PHP prend en charge et que votre application supporte. PHP 8.2 referme la faille à partir de 8.2.35, mais atteint la fin de la prise en charge le 31 décembre 2026. Qui migre maintenant devrait donc, si possible, viser 8.3 ou plus récent, pour autant que l'application l'autorise. L'état actuel est indiqué par php.net sur la page des versions prises en charge.

Quelle version de PHP supportent votre CMS ou votre boutique, vérifiez-le selon les exigences système de l'éditeur, par exemple sur wordpress.org, shopware.com ou typo3.org. Souvent, l'application elle-même doit d'abord être mise à jour avant que PHP puisse changer. Un cas typique, ce sont les anciennes boutiques, que nous décrivons sur la page [Shopware 5](https://phpsos.de/fr/plattformen/shopware-5/). Le contexte sur les conséquences des versions obsolètes figure sous [Fin de vie de PHP : risques des versions obsolètes](https://phpsos.de/fr/ratgeber/php-end-of-life-risiken/).

| Étape | Contenu |
|---|---|
| Inventaire | version de PHP, application, extensions, adaptations spécifiques |
| Exigences | versions de PHP prises en charge selon l'éditeur |
| Environnement de test | copie avec la nouvelle version de PHP, analyse du journal d'erreurs |
| Bascule | fenêtre de maintenance planifiée, retour arrière préparé |
| Suivi | vérifier les valeurs transitoires, mettre en place la surveillance |

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

Avec la [migration de PHP 8.1 et antérieur](https://phpsos.de/fr/leistungen/php-migration-legacy/), nous vous conduisons de l'ancienne version à une version prise en charge :

- **Sécuriser immédiatement :** vérifier l'état des backports, mettre en place les mesures transitoires, réduire l'accessibilité.
- **Rechercher des traces :** sauvegarder les journaux à partir du 20 octobre et les analyser à la recherche d'anomalies.
- **Préparer la migration :** clarifier la compatibilité selon l'éditeur, mettre en place un environnement de test, corriger les erreurs.
- **Basculer et attester :** installer la nouvelle version de PHP, redémarrer tous les processus, documenter l'état.


## Questions fréquentes

**PHP 8.1 est-il concerné par PHP2Shell ?**  
Selon la presse spécialisée, presque toutes les versions, jusqu'à PHP 5.4, sont concernées, PHP 8.1 compris. Le projet PHP ne publie plus de mises à jour officielles pour 8.1, seulement des backports minimaux du code source.

**Qu'est-ce qu'un backport du code source ?**  
Une correction dans le code source reportée sur une ancienne branche de version. Ce n'est pas une version prête à l'emploi : quelqu'un doit la reprendre, recompiler PHP, tester et déployer. Votre fournisseur de distribution, votre hébergeur ou un prestataire peut s'en charger.

**Suffit-il de passer à PHP 8.2 ?**  
À court terme, PHP 8.2.35 referme la faille. PHP 8.2 atteint toutefois la fin de la prise en charge le 31 décembre 2026. Qui migre de toute façon devrait donc vérifier si l'application prend aussi en charge 8.3 ou plus récent selon l'éditeur.

**Ma boutique ne fonctionne qu'avec PHP 7.4. Que faire ?**  
Deux choses sont alors nécessaires en parallèle : sécuriser le serveur par des mesures transitoires et un cloisonnement, et amener l'application vers une version qui supporte une version de PHP prise en charge. Laquelle, les exigences système de l'éditeur l'indiquent.

## Sources

- [php.net : versions prises en charge](https://www.php.net/supported-versions.php)
- [php.net : avis de sécurité](https://www.php.net/)
- [TechTarget : PHP2Shell, 22 millions de serveurs exposés](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
- [Shopware](https://www.shopware.com/)