Faille PHP2Shell : alerte sécurité pour tous les serveurs de jeux (CVE-2026-109618)

Sommaire#

• PHP2Shell en deux minutes
• Pourquoi les serveurs de jeux sont en première ligne
• Ce qui est touché sur votre serveur, et qui doit agir
• Les versions de PHP corrigées
• La marche à suivre pour les administrateurs
• Si vous ne pouvez pas mettre à jour tout de suite
• Et côté joueurs
• FAQ
• Sources

Introduction#

Le 20 octobre 2026, l'équipe sécurité de PHP a fait quelque chose d'assez rare : annoncer publiquement qu'un correctif critique sortirait le lendemain, parce que des informations sur deux failles circulaient déjà en ligne. Le mercredi 21 octobre à 16 h, heure de Paris, les versions corrigées étaient disponibles. Le surnom donné à ces failles, PHP2Shell, résume bien l'enjeu : obtenir un accès complet (un « shell ») au serveur, sans compte et sans mot de passe.

Votre serveur Minecraft ou FiveM ne tourne pas en PHP, c'est vrai. Son site, sa boutique, sa page de vote et souvent son panel de gestion, eux, si. Azuriom, CraftMyWebsite, NamelessMC, WordPress, Pterodactyl : les outils les plus répandus chez les administrateurs de serveurs de jeux sont tous écrits en PHP. Voici ce qu'il faut vérifier aujourd'hui, et dans quel ordre.

PHP2Shell en deux minutes#

PHP2Shell regroupe deux vulnérabilités situées dans le cœur même de PHP. L'équipe sécurité du projet leur attribue à chacune une note de 9,2 sur 10 (CVSS v4.0).

• CVE-2026-109618, la corruption par manque de mémoire. Quand une requête épuise la mémoire autorisée, PHP s'interrompt alors que certaines données internes ne sont qu'à moitié initialisées. Le nettoyage de fin de requête les traite ensuite comme valides.
• CVE-2026-109619, l'état global périmé. Une information liée à une requête survit après la libération de la mémoire qui la contenait. La requête suivante, traitée par le même processus, s'en sert avant qu'elle soit remise à zéro.

Dans les deux cas, le résultat démontré par les chercheurs est le même : exécuter du code à distance, sans authentification, avec les droits du serveur web.

Le détail qui change tout : sur Apache avec mod_php, l'équipe de PHP précise qu'une simple requête anonyme peut déclencher l'attaque avant même que le code du site s'exécute. Votre CMS peut être parfaitement à jour et vos extensions irréprochables, ça ne change rien. La faille se trouve en dessous.

Pourquoi on ne peut pas attendre la semaine prochaine :

• le détail technique des deux failles et un outil d'exploitation sont déjà publics ;
• watchTowr et d'autres sociétés de sécurité signalent des premières exploitations réelles ;
• selon Sansec, toutes les versions depuis PHP 5.4 seraient concernées, soit à peu près tout ce qui tourne encore sur le web ;
• et une complexité d'attaque jugée « élevée » sur le papier pèse peu une fois qu'un outil prêt à l'emploi circule.

Pourquoi les serveurs de jeux sont en première ligne#

Une grosse boutique en ligne a une équipe technique qui a sans doute passé la nuit sur le sujet. Un serveur Minecraft de quarante joueurs, c'est souvent un fondateur, deux modérateurs et un site installé il y a deux ans sur un VPS à cinq euros par mois, auquel personne n'a touché depuis. C'est précisément ce profil que les scans automatisés trouvent en premier.

Notre milieu a aussi un problème bien à lui : les CMS abandonnés. MineWeb, longtemps très utilisé par les serveurs francophones, n'est plus maintenu et impose PHP 7.4 au maximum. Le projet PHP ne publie aucune version officielle corrigée pour 7.4, 8.0 et 8.1. Il a seulement mis en ligne des correctifs minimaux en code source, à compiler soi-même. Sur un hébergement mutualisé, ça revient à dire qu'il n'existe pas de solution simple. Nous expliquions déjà dans notre comparatif des CMS Minecraft pourquoi il fallait le quitter, et cette semaine en donne une illustration très concrète.

Les conséquences d'un site compromis, elles, n'ont rien de théorique. Une boutique piratée peut servir à détourner des paiements, à voler les identifiants des joueurs ou à afficher une fausse page de connexion aux couleurs du serveur. Sans compter la perte de confiance, qui se rattrape beaucoup plus difficilement qu'un site.

Ce qui est touché sur votre serveur, et qui doit agir#

Le panel mérite une attention particulière. Celui qui prend la main dessus contrôle tous les serveurs de jeu qu'il pilote, les clés API, et souvent les sauvegardes. Bonne nouvelle en revanche pour les nœuds : Wings, le service qui fait tourner les serveurs sur chaque machine, est écrit en Go et n'est pas concerné par la faille.

Pour Tebex, une nuance : la boutique elle-même est hébergée par Tebex, vous n'avez donc pas de PHP à mettre à jour de ce côté. Si votre propre site affiche la boutique via un module, c'est en revanche ce site qu'il faut vérifier.

Les versions de PHP corrigées#

Les distributions Linux et les éditeurs de support long terme ont reçu les correctifs en avance : sur Debian, Ubuntu ou AlmaLinux, des paquets à jour devraient arriver rapidement via le gestionnaire habituel. Attention si vous utilisez le dépôt remi, très répandu sur les distributions de la famille Red Hat : l'équipe de PHP prévient qu'il n'aura pas de mise à jour le jour de la sortie, et conseille de passer par les paquets de la distribution ou de compiler depuis les sources.

Si votre site tourne encore en 8.2, profitez-en pour planifier le passage en 8.3 ou 8.4 : dans dix semaines, cette branche ne recevra plus rien.

La marche à suivre pour les administrateurs#

1. Faites l'inventaire de tout ce qui exécute du PHP. Site, boutique, vote, forum, wiki, panel, mais aussi les sous-domaines oubliés. Le « test.monserveur.fr » monté en 2023 pour essayer un thème compte autant que le site principal.
2. Vérifiez la version utilisée par le web, pas seulement celle du terminal. La commande php -v affiche la version en ligne de commande, qui peut différer de celle de PHP-FPM ou d'Apache. L'espace client de l'hébergeur ou une page phpinfo() temporaire (supprimée aussitôt après) donnent la vraie réponse.
3. Sur un hébergement mutualisé ou infogéré, demandez à votre hébergeur la version exacte appliquée. Une réponse du type « on s'en occupe » ne suffit pas.
4. Sur un VPS ou un dédié, mettez à jour les paquets (apt update && apt upgrade sous Debian et Ubuntu, dnf upgrade sous AlmaLinux ou Rocky), puis redémarrez tous les processus PHP : le service php-fpm, Apache s'il utilise mod_php, les processus lsphp sous LiteSpeed. Relancer Nginx seul ne recharge pas PHP.
5. Pour un panel Pterodactyl ou Pelican, appliquez le même traitement au PHP qui fait tourner le panel, puis contrôlez la liste des utilisateurs et des clés API.
6. Une fois à jour, cherchez des traces. Fichiers PHP récemment créés dans le dossier du site, comptes administrateurs inconnus dans le CMS, redirections étranges, pics de charge. En cas de doute, changez les mots de passe, les clés API de la boutique et du panel, et la clé de liaison entre le site et le serveur de jeu (AzLink sur Azuriom).

L'absence d'anomalie dans les journaux ne prouve pas grand-chose, l'équipe de PHP le dit elle-même. Si vous avez un sérieux doute, la solution la plus sûre reste de restaurer une sauvegarde antérieure au 20 octobre, puis d'appliquer la mise à jour avant de remettre le site en ligne.

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

Soyons clairs : aucune de ces mesures ne rend une installation sûre, l'équipe de PHP insiste sur ce point. Elles réduisent l'exposition le temps que le correctif soit en place.

• Désactiver le suivi de progression des uploads avec session.upload_progress.enabled = 0, dans le php.ini ou la configuration du pool FPM, puis redémarrer chaque worker. Pas via ini_set() ni un fichier .user.ini, appliqués trop tard. Un site de serveur de jeu n'utilise quasiment jamais cette fonction : vous pouvez la laisser coupée même après le correctif.
• Réduire la taille des requêtes acceptées : post_max_size = 8M si le site n'accepte pas d'envoi de fichiers, 32M sinon, avec un upload_max_filesize inférieur.
• Supprimer la limite mémoire contrôlable en imposant memory_limit = -1 côté administrateur (php_admin_value dans le pool FPM ou la configuration Apache). À coupler impérativement avec une limite au niveau du conteneur ou du cgroup, sinon une seule requête gourmande peut saturer la machine.
• Sous PHP 8.5, définir fatal_error_backtraces = 0.
• Filtrer en amont : Sansec recommande de bloquer les requêtes multipart/form-data au niveau du serveur web quand le site n'en a pas besoin, ou de placer le site derrière Cloudflare le temps de corriger.

Dernier recours, recommandé par le CERT-EU aux organisations qui ne peuvent pas corriger : isoler le site d'internet. Pour un serveur de jeu, une page de maintenance pendant quarante-huit heures coûte bien moins cher qu'une base de comptes joueurs dans la nature.

Et côté joueurs#

Vous n'avez rien à changer dans votre jeu. Quelques réflexes valent quand même le coup cette semaine :

• utilisez un mot de passe différent pour chaque boutique et chaque forum de serveur, parce qu'une seule base volée suffit à tester vos identifiants ailleurs ;
• activez la double authentification quand elle est proposée ;
• méfiez-vous d'un site de serveur qui vous redirige soudain ailleurs ou vous demande de télécharger un « launcher obligatoire » ;
• si un serveur annonce un incident, changez votre mot de passe chez lui et partout où vous l'aviez réutilisé.

Sansec signale d'ailleurs qu'une des deux failles permet aussi de faire fuiter des morceaux de la mémoire du serveur. Sur un site mal corrigé, des fragments de données traitées pour d'autres visiteurs peuvent donc sortir. Raison de plus pour ne pas recycler ses mots de passe.

FAQ#

PHP2Shell touche-t-il mon serveur Minecraft lui-même ?#

Non. Le serveur Minecraft Java tourne en Java, celui de Bedrock en C++, et FiveM comme Garry's Mod reposent sur leurs propres moteurs. Le risque vient des services web qui les entourent, et du panel s'il est installé sur la même machine que le serveur de jeu.

Mon site est chez un hébergeur mutualisé, dois-je faire quelque chose ?#

Oui : vérifier. C'est l'hébergeur qui applique la mise à jour, mais c'est souvent vous qui choisissez la branche PHP dans l'espace client. Si votre site est réglé sur une version abandonnée comme 7.4 ou 8.1 pour rester compatible avec un vieux CMS, rien ne garantit que la mise à jour de l'hébergeur vous protège.

J'utilise une boutique Tebex, suis-je concerné ?#

Pas pour la boutique elle-même, hébergée et maintenue par Tebex. En revanche, le site sur lequel vous l'intégrez, votre CMS ou votre forum, reste à vérifier comme n'importe quel site PHP.

Azuriom est-il vulnérable ?#

La faille ne vient pas d'Azuriom mais de PHP, le langage sur lequel il repose. Un Azuriom installé sur un PHP non corrigé est donc exposé, comme n'importe quel CMS PHP. Mettre PHP à jour suffit : il n'y a rien à réinstaller côté CMS.

Comment savoir si mon site a déjà été piraté ?#

Les indices les plus fréquents : des fichiers PHP inconnus créés récemment, un compte administrateur que personne ne connaît, des redirections vers d'autres sites, une alerte de votre hébergeur ou une consommation processeur anormale. Aucun de ces signes n'est une preuve absolue, et leur absence non plus. En cas de vrai doute, restaurez une sauvegarde saine, mettez PHP à jour, puis changez tous les accès.

Conclusion#

PHP2Shell ne vise aucun jeu en particulier, et c'est justement ce qui le rend dangereux pour notre écosystème : il passe par la partie que beaucoup d'administrateurs ont tendance à oublier une fois le site lancé. La mise à jour prend une dizaine de minutes sur un VPS et un ticket chez un hébergeur mutualisé. Le vrai travail concerne les sites restés sur des versions abandonnées, MineWeb en tête, pour lesquels la migration n'est plus une option qu'on peut repousser.

Une fois votre infrastructure corrigée, la suite ne change pas : faire vivre votre communauté. Notre guide pour attirer des joueurs sur votre serveur Minecraft détaille les leviers qui fonctionnent, et vous pouvez référencer votre serveur gratuitement sur ServeurListe pour apparaître dans nos classements.

Sources#

• www.php.net/archive/2026.php#2026-10-21-5 (avis de sécurité de PHP)
• www.php.net/archive/2026.php#2026-10-20-1 (annonce préalable de la mise à jour de sécurité)
• www.php.net/archive/2026.php#2026-10-21-4 (PHP 8.5.12)
• www.php.net/archive/2026.php#2026-10-21-3 (PHP 8.4.27)
• www.php.net/archive/2026.php#2026-10-21-2 (PHP 8.3.36)
• www.php.net/archive/2026.php#2026-10-21-1 (PHP 8.2.35)
• github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• cert.europa.eu/publications/security-advisories/2026-018 (CERT-EU)
• sansec.io/research/php2shell (Sansec)
• watchtowr.com/intelligence/php-cve-2026-109618-faq (watchTowr)