NOTRE OFFRE
Sauvegardes Logiciels Technologie des serveurs Hébergement web Sécurité web

PHP2Shell : ce que les propriétaires de sites web doivent savoir sur les failles de sécurité PHP

Inscription PHP en trois dimensions sur un panneau rouge aux coins arrondis, avec du code informatique en filigrane sur un fond rouge abstrait.
Dernière modification : 04/11/2026 Équipe ALL-INKL.COM 9 Min. de lecture

Deux failles de sécurité critiques ont été découvertes dans PHP. Elles sont regroupées sous le nom de PHP2Shell. Dans certaines conditions, des attaquants peuvent les exploiter pour exécuter du code malveillant sur un serveur web. Deux questions essentielles se posent donc aux propriétaires de sites web : la version de PHP utilisée a-t-elle déjà été corrigée ? Et y a-t-il des signes d’une attaque ?

Les clients d’ALL-INKL.COM peuvent être rassurés : toutes les versions de PHP que nous proposons ont déjà reçu les correctifs nécessaires. Il reste toutefois conseillé de vérifier que votre site web ne présente aucune modification suspecte.

Qu’est-ce que PHP2Shell ?

Deux graves failles de sécurité PHP ont été rendues publiques le 21 octobre 2026. Elles portent les identifiants CVE-2026-109618 et CVE-2026-109619. PHP est un langage de programmation utilisé sur de nombreux serveurs web. Il gère notamment les formulaires de contact, les connexions des utilisateurs et les commandes dans les boutiques en ligne. Les systèmes de gestion de contenu comme WordPress utilisent également PHP.

Dans certaines conditions, ces deux failles permettent une exécution de code à distance, appelée Remote Code Execution (RCE). Cela signifie que des attaquants peuvent exécuter à distance leurs propres commandes sur un serveur concerné. L’ampleur des dommages possibles dépend de la configuration du serveur et des droits d’accès en place. Un accès complet au serveur n’est pas automatiquement possible.

L’exécution de code à distance
L’exécution de code à distance, ou RCE, permet à une personne de faire exécuter ses instructions par un système distant. Les conséquences dépendent en partie des droits du processus touché. Une RCE ne donne pas nécessairement un accès administrateur illimité à l’ensemble du serveur.

Important : vous pouvez être concerné même si vous n’avez pas programmé votre site vous-même. L’essentiel est de savoir si l’environnement PHP du serveur a été corrigé.

Comment ces failles sont-elles apparues ?

Les deux vulnérabilités proviennent d’erreurs dans la gestion de la mémoire de PHP. Dans le cas de CVE-2026-109618, PHP peut, dans certaines circonstances, continuer à traiter des données incorrectes ou incomplètes. Dans le cas de CVE-2026-109619, PHP peut accéder à une zone mémoire qui a déjà été libérée. Ces erreurs peuvent provoquer des plantages ou, dans certaines conditions, permettre l’exécution de code malveillant.

Selon la PHP Foundation, des indices concernant l’un des problèmes existaient dès 2024. Des difficultés techniques, des ressources limitées et des décisions tardives ont d’abord empêché sa correction. En août 2026, l’ampleur du problème est devenue plus claire. Après la divulgation prématurée d’informations, les mises à jour de sécurité ont été publiées plus tôt que prévu. Cet incident montre que même des logiciels éprouvés peuvent contenir des failles encore inconnues. Une maintenance régulière et des mises à jour de sécurité restent donc indispensables.

Quels sont les risques pour les sites web ?

Si des attaquants exploitent ces failles avec succès, les dommages peuvent varier selon le système :

  • Contenus modifiés : les textes, les images ou d’autres contenus du site pourraient être altérés.
  • Identifiants volés : des mots de passe ou des informations confidentielles pourraient être divulgués.
  • Redirections frauduleuses : les visiteurs pourraient être envoyés vers des sites frauduleux.
  • Fonctions de boutique altérées : les processus de commande ou les redirections de paiement pourraient être modifiés.
  • Code malveillant injecté : les attaquants pourraient exécuter des programmes malveillants sur le serveur.

La présence d’une faille ne signifie pas automatiquement qu’une attaque a réussi. Il faut examiner, à partir d’éléments concrets tels que les dommages possibles mentionnés ci-dessus, si des personnes non autorisées ont eu accès au système.

Un certificat SSL ne protège pas non plus contre PHP2Shell. HTTPS chiffre les données échangées entre le navigateur et le serveur web, tandis que PHP2Shell concerne le traitement sur le serveur lui-même. Pour en savoir plus, consultez notre article HTTP vs HTTPS : quelle est la différence ?.

Quelles versions de PHP ont été corrigées ?

Les versions corrigées suivantes ont été publiées pour remédier aux deux failles :

Version de PHP Première version corrigée
8.2 8.2.35
8.3 8.3.36
8.4 8.4.27
8.5 8.5.12

Le tableau présente les premières versions corrigées. Les hébergeurs peuvent également appliquer les correctifs de sécurité à des versions plus anciennes de PHP. Un numéro de version plus ancien ne signifie donc pas nécessairement que l’installation n’est pas sécurisée.

Les clients d’ALL-INKL.COM peuvent vérifier la version de PHP utilisée dans le système d’administration client (KAS). Pensez également aux sous-domaines et aux installations de test. Après un changement de version, testez les fonctions importantes comme les formulaires, les connexions et les processus de commande.

Tenez également compte des avis de sécurité ultérieurs : le 23 octobre, un problème touchant une configuration de session peu courante a été signalé. Le 26 octobre, de nouvelles versions pour Windows ont été publiées en raison d’une autre faille de sécurité dans Brotli. Brotli est une méthode de compression des fichiers qui permet aux sites de se charger plus rapidement. Des erreurs lors du traitement de ces données peuvent entraîner des risques de sécurité.

Que devraient faire les clients d’ALL-INKL.COM maintenant ?

ALL-INKL.COM a corrigé toutes les versions de PHP proposées, y compris les plus anciennes. À ce jour, aucun élément concret n’indique que ces failles ont été exploitées avec succès. Il n’est toutefois pas possible d’exclure totalement des attaques antérieures. Nous recommandons donc les mesures suivantes :

1. Vérifier les modifications sur votre site

Vérifiez si votre site présente des modifications inhabituelles. Portez une attention particulière aux comptes utilisateurs inconnus, aux redirections inattendues, aux fichiers modifiés et aux contenus suspects. Toute anomalie n’est pas forcément le signe d’une attaque. Des modifications peuvent avoir été effectuées par votre agence ou d’autres personnes autorisées. Ne supprimez pas trop vite les fichiers suspects, car ils peuvent être importants pour une enquête. En cas de soupçon fondé, contactez l’assistance ALL-INKL.COM.

2. Maintenir les applications à jour

Mettez régulièrement à jour votre CMS ainsi que les plugins, extensions et thèmes installés. Une mise à jour de WordPress, par exemple, ne remplace toutefois pas une mise à jour de sécurité PHP. Ces deux éléments doivent être sécurisés indépendamment.

3. Effectuer des sauvegardes

Sauvegardez régulièrement les fichiers de votre site ainsi que les bases de données associées. Vérifiez que les sauvegardes peuvent être restaurées. Nos guides de sauvegarde des données vous accompagnent dans cette démarche. Gardez à l’esprit qu’une sauvegarde peut déjà contenir des fichiers altérés. Après une attaque, utilisez si possible une sauvegarde dont vous avez vérifié qu’elle n’a pas été compromise.

4. Vérifier les identifiants d’accès

Si un accès non autorisé a été confirmé, les mots de passe et les clés d’accès potentiellement concernés devraient être renouvelés après le nettoyage du système. Éliminez d’abord la cause de l’attaque afin d’empêcher les personnes non autorisées d’accéder à nouveau au système.

L’IA rend-elle les failles de sécurité plus dangereuses ?

L’intelligence artificielle peut analyser rapidement du code et repérer des failles de sécurité. Cela aide les chercheurs en sécurité, mais peut aussi profiter aux attaquants. Selon l’entreprise de cybersécurité Wiz, l’IA a considérablement facilité le développement et l’adaptation d'exploits de démonstration (preuves de concept) fonctionnels pour PHP2Shell. Elle n’est toutefois pas à l’origine des erreurs initiales de PHP.

À l’avenir, l’IA pourrait accélérer la découverte et l’exploitation des vulnérabilités existantes. Il est impossible de prévoir de manière fiable dans quelle mesure cela fera augmenter le nombre d’attaques réussies. Pour les propriétaires de sites, les priorités restent d’installer rapidement les mises à jour de sécurité, de vérifier régulièrement les applications et de définir clairement les responsabilités. Le code généré par l’IA devrait également être contrôlé avant son utilisation afin de détecter d’éventuels problèmes de sécurité.

FAQ : Questions fréquentes sur PHP2Shell

PHP2Shell désigne-t-il une seule faille de sécurité ?

Non. Ce nom désigne deux failles de sécurité PHP portant les identifiants CVE-2026-109618 et CVE-2026-109619.

PHP2Shell signifie-t-il que mon site a été piraté ?

Non. Une faille de sécurité signifie seulement, dans un premier temps, qu’une attaque pourrait être possible. Il faut vérifier si votre site a réellement été touché.

Une mise à jour de WordPress suffit-elle ?

Non. WordPress et l’environnement PHP sous-jacent doivent être mis à jour et sécurisés séparément.

Dois-je mettre à jour PHP sur mon ordinateur ?

Si vous consultez simplement des sites web, ce n’est pas nécessaire. Si vous utilisez votre propre environnement PHP local, vous devriez vérifier son niveau de sécurité.

Un certificat SSL protège-t-il contre PHP2Shell ?

Non. SSL, ou HTTPS, protège la connexion, et non le traitement PHP sur le serveur.

Dois-je passer immédiatement à une nouvelle version majeure de PHP ?

Pas nécessairement. L’essentiel est de disposer d’une installation PHP dont la correction est confirmée. La compatibilité devrait être vérifiée avant tout changement de version majeure.

Une ancienne version de PHP est-elle automatiquement non sécurisée ?

Non. Les hébergeurs peuvent également fournir des correctifs de sécurité pour les anciennes versions. C’est le niveau de sécurité réel qui compte.

Un scanner de sécurité suffit-il pour vérifier mon site ?

Un scanner peut signaler des problèmes potentiels, mais il ne remplace ni la vérification des mises à jour installées ni une investigation ciblée en cas de soupçon.

Dois-je mettre mon site hors ligne ?

En général, non, si l’environnement PHP est corrigé et qu’aucun signe d’attaque réussie n’est présent. En cas d’intrusion confirmée, une mise hors ligne temporaire peut être judicieuse.

L’IA pourra-t-elle assurer tous les contrôles de sécurité à l’avenir ?

Non. L’IA peut faciliter l’analyse, mais elle ne remplace pas les contrôles techniques et l’évaluation réalisés par les professionnels responsables.

Maintenir PHP à jour et vérifier régulièrement les sites

PHP2Shell montre que même les composants fondamentaux d’un site peuvent contenir des failles de sécurité. Chez ALL-INKL.COM, toutes les versions de PHP proposées ont déjà été corrigées. Les propriétaires de sites doivent néanmoins maintenir leurs applications à jour, effectuer des sauvegardes régulières et rester attentifs aux modifications inhabituelles. Installer rapidement les mises à jour de sécurité et contrôler régulièrement son site permet de réduire considérablement le risque d’attaques réussies.

Cet article vous a-t-il été utile ?

PREMIER-NIVEAU DOMAINES

Les domaines de premier niveau ouvrent des opportunités pour des adresses web créatives, une meilleure présence sur le marché et des identités en ligne uniques.

Réservez dès aujourd’hui votre domaine idéal.