Faille PHP2Shell : comment nous avons protégé les sites de nos clients

Deux failles dans le moteur PHP

PHP2Shell regroupe deux failles du moteur PHP, référencées CVE-2026-109618 et CVE-2026-109619. Elles ont été rendues publiques le 21 octobre 2026, avec une note de gravité de 9,2 sur 10.

Elles permettent à un attaquant d’exécuter son propre code sur le serveur, à distance et sans se connecter. L’attaque agit au niveau de PHP, avant le chargement du site. Un WordPress à jour, une extension de sécurité ou un mot de passe solide ne la bloquent donc pas.

Toutes les installations de PHP qui servent des pages web sont concernées. Des tentatives d’exploitation ont été observées quatre jours avant la publication, puis des attaques réelles dans les jours suivants.

Les versions corrigées

Les correctifs sont sortis le 21 octobre 2026 :

• PHP 8.5.12 ;
• PHP 8.4.27 ;
• PHP 8.3.36 ;
• PHP 8.2.35.

PHP 8.1 et les versions plus anciennes ne reçoivent plus de mise à jour officielle. L’équipe de PHP a publié des correctifs sous forme de code source pour les versions 7.4, 8.0 et 8.1. C’est à l’hébergeur de les intégrer lui-même.

Nos interventions selon l’hébergement

Nous avons commencé par l’inventaire : pour chaque site que nous suivons, la version de PHP et le type d’hébergement. La réponse dépend de ces deux informations.

Sur un serveur dédié. Pour un site industriel hébergé sur son propre serveur, l’infogérant a installé PHP 8.3.36 et mis à jour le système. Nous avons ensuite contrôlé le site : page d’accueil, page de connexion, interface de programmation, plan du site. Tout répondait normalement. Le client a reçu un compte rendu.

Sur un hébergement managé. Pour deux sites hébergés chez Kinsta, nous avons mis à jour les extensions puis passé PHP en version 8.4. L’un des deux sites a affiché une erreur critique après la bascule, à cause d’une extension installée en double. Nous l’avons retirée et le site est revenu en ligne.

Sur un serveur mutualisé. Pour les dix-sept sites d’une agence partenaire, l’hébergeur a appliqué le correctif à toutes les versions de PHP dès la publication, y compris les anciennes. Nous avons repéré les sites qui tournaient encore en PHP 7.4 et 8.0, et recommandé de les passer en 8.3.

Après le correctif, la montée de version

Le correctif ferme uniquement PHP2Shell. PHP 8.1 et les versions antérieures ne reçoivent plus de correctifs de sécurité réguliers. À la prochaine faille, rien ne garantit qu’un hébergeur prendra le temps de la corriger.

Nous recommandons PHP 8.3 au minimum. La montée de version se prépare : sauvegarde, mise à jour des extensions et du thème, test sur une copie du site, puis bascule et contrôle. Pour un site WordPress classique, comptez une demi-journée.

Pensez aussi au système du serveur. Ubuntu 22.04, encore très répandu, sort de son support standard en avril 2027.

Les points à vérifier sur votre site

• Demandez à votre hébergeur ou à votre prestataire la version de PHP de votre site.
• Vérifiez qu’elle figure dans la liste des versions corrigées, ou que le correctif a bien été appliqué.
• Si votre site tourne sous PHP 8.1 ou plus ancien, planifiez la montée de version.
• Si vous ne savez pas qui doit s’en occuper, c’est le moment de le décider. Nous détaillons ce qu’un contrat de maintenance doit couvrir.

Votre site est concerné et vous voulez un avis ? Notre offre de maintenance et sécurité commence par ce type de diagnostic.

Sources

• Help Net Security, 21 octobre 2026
• Datadog Security Labs : détection, analyse et correction
• watchTowr : exploitation observée