PHP2Shell : deux failles critiques de PHP, et ce que nous avons fait chez Alama

Publié le 22 octobre 2026

Le 21 octobre 2026, deux failles critiques de PHP ont été rendues publiques. PHP est le langage sur lequel tourne une très grande partie du web, dont beaucoup de sites que nos clients hébergent chez nous. Des attaques ont déjà été observées sur Internet.

Cet article dit ce que sont ces failles, ce que nous avons trouvé en vérifiant nos propres systèmes, ce que nous avons changé, et ce que tu peux faire si tu gères PHP toi-même. Sans jargon, et sans rien cacher.

En bref

Nous n’avons trouvé aucune trace d’intrusion dans nos journaux ni sur nos serveurs.
Des sondes automatiques ont bien visé nos sites : environ 690 requêtes d’envoi de fichier, toutes rejetées.
PHP a été mis à jour partout chez Alama : la boutique, le panel de jeu, nos sites, le webmail, et les « eggs » que nos clients utilisent pour héberger leurs propres sites PHP.
Le client dont le site PHP était concerné a été prévenu directement.

BD en quatre cases : un robot violet frappe avec un colis étiqueté FORM et dit « Livraison spéciale ! », le lama d’Alama regarde le colis à travers une loupe, voit une bombe et dit « Colis piégé. Refusé. », puis met PHP à jour dans les trois petites maisons qui représentent les eggs, et le robot s’éloigne les mains vides pendant que le lama dit « Tout est calme. »

Ce que sont ces failles

Les deux failles s’appellent CVE-2026-109618 et CVE-2026-109619, et on les surnomme ensemble « PHP2Shell ». Elles sont notées toutes deux 9,2 sur 10 sur l’échelle CVSS v4, ce qui est la zone « critique ».

CVE-2026-109618 est une corruption de mémoire : PHP manque de mémoire en lisant une requête, et sa mémoire est corrompue.
CVE-2026-109619 est un état laissé derrière : ce qu’une requête laisse dans la mémoire de PHP est réutilisé par la requête suivante, qui ne devrait jamais le voir.

Ce qui les rend graves, c’est la façon d’y arriver. Un attaquant n’a besoin d’aucun compte. Il lui suffit d’envoyer un formulaire qui contient un fichier, ce que tout site avec un champ d’envoi accepte toute la journée. PHP lit cette requête avant même que le code du site ne démarre, donc les propres vérifications du site n’ont jamais l’occasion de dire non. Ensemble, ces failles peuvent permettre à un attaquant d’exécuter son propre code sur le serveur.

Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35.

Ce que nous avons fait chez Alama

Nous avons vérifié. Nous avons parcouru nos journaux et nos serveurs à la recherche du moindre signe que quelqu’un soit entré, et nous n’en avons trouvé aucun. Des sondes automatiques ont bien visé nos sites, environ 690 requêtes d’envoi de fichier, et toutes ont été rejetées.

Nous avons aussi agi, en deux temps. D’abord nous avons posé une protection immédiate. Puis nous avons mis PHP à jour partout où nous le faisons tourner :

la boutique,
le panel de jeu,
nos sites,
le webmail,
et les eggs : les modèles de serveur que nos clients utilisent pour héberger leurs propres sites PHP. Cette partie compte, parce qu’un client ne devrait pas avoir à se demander si le PHP sous son site est bien la version corrigée.

Le client dont le site PHP était concerné a été prévenu directement.

Si tu gères ton propre PHP

Mets PHP à jour vers une version corrigée : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, selon la branche sur laquelle tu es. Si ta branche n’a pas de version corrigée, passe à une branche qui en a une.
En attendant la mise à jour, coupe une fonction de PHP dans ton php.ini, puis redémarre PHP (PHP-FPM ou ton serveur web) :
```
session.upload_progress.enabled = 0
```

Ce n’est qu’une protection partielle. Elle ne remplace pas la mise à jour, et elle ne rend pas un serveur sûr à elle seule. Vois-la comme une fenêtre qu’on ferme en attendant d’avoir la bonne serrure.

Questions

Si tu héberges quelque chose chez nous et que tu as une question à ce sujet, écris-nous à contact@alama.host.