Actualités cyber

PHP2Shell : votre site est-il concerné et que demander à votre hébergeur ?

Transformez les alertes PHP d’octobre en demandes concrètes à votre hébergeur, avec une checklist et un message prêt à adapter.

Si vous possédez un site, la question utile sur PHP2Shell est : qui peut confirmer que le moteur PHP qui traite les visites a été corrigé ? Ce guide vous aide à poser la question, même quand une autre entreprise administre le serveur. Informations vérifiées le 30 octobre 2026.

Une faille critique ne prouve pas une fuite de données

La mise à jour du 27 octobre de l’alerte AL26-026 du Centre canadien pour la cybersécurité signale une exploitation réelle de CVE-2026-109618 et CVE-2026-109619, surnommées PHP2Shell. Ces failles peuvent permettre l’exécution de code sans connexion préalable. Source en anglais.

Il faut donc vérifier rapidement l’exposition. Cela ne démontre pas que votre site particulier a été attaqué ni que des données clients ont été volées. Distinguez ces questions dans vos échanges avec votre prestataire et vos clients.

Partez du service, pas de la page d’accueil

Listez votre site principal, votre boutique, votre portail client et vos outils d’administration. Pour chacun, notez la personne ou l’entreprise responsable de l’hébergement. Demandez si PHP traite les requêtes Web. Une belle page d’accueil, un cadenas fonctionnel ou un tableau de bord CMS à jour ne répondent pas à cette question.

Demandez une réponse qui nomme le service de production. Une capture provenant d’un autre serveur ou d’une installation PHP en ligne de commande ne constitue pas la confirmation recherchée. Si le fournisseur gère plusieurs environnements, demandez un état distinct pour la production, la préproduction et les services d’administration accessibles publiquement.

Quelles versions PHP contiennent les premiers correctifs ?

L’avis PHP du 21 octobre indique les versions officielles suivantes pour les deux failles initiales :

Branche PHPPremière version corrigée
8.58.5.12
8.48.4.27
8.38.3.36
8.28.2.35

Une distribution peut intégrer le correctif à un paquet dont le numéro de base est plus ancien. L’avis Ubuntu sur les paquets l’illustre et précise que les applications peuvent nécessiter un redémarrage pour charger les composants corrigés. Demandez le paquet exact, l’avis du fournisseur et la confirmation que le service actif l’utilise.

Un avis distinct complète les premiers correctifs. L’avis PHP du 23 octobre sur la progression des téléversements concerne CVE-2026-115560, non corrigée par les versions du 21 octobre. Elle exige une combinaison inhabituelle de configuration et de changement du gestionnaire de sérialisation à l’exécution. Faites évaluer cet avis et sa mesure de mitigation par l’administrateur ; le tableau ne suffit pas pour déclarer le service entièrement protégé.

Demandez une réponse que vous pourrez suivre

  • Quels services nommés de mon compte utilisent PHP, et qui les maintient ?
  • Quel paquet ou quelle version corrige les deux premières CVE ? Quel avis fournisseur le confirme ?
  • À quelle date le service de production a-t-il commencé à utiliser le moteur corrigé ?
  • L’avis distinct du 23 octobre a-t-il été évalué, et quelle action était nécessaire ?
  • Si un point reste ouvert, qui en est responsable et quand recevrai-je un suivi ?

Conservez le numéro du ticket, la date et la réponse dans votre dossier de maintenance. « Les mises à jour sont automatiques » ouvre la discussion ; demandez l’état de votre service réel.

Un message court à adapter pour votre hébergeur

Bonjour, pouvez-vous confirmer l’état PHP2Shell de [domaine/service] ? Le moteur Web en production dispose-t-il des correctifs pour CVE-2026-109618 et CVE-2026-109619 ? Merci d’indiquer le paquet ou la version installé, l’avis fournisseur et la date de mise à jour du service actif. Merci également de confirmer votre évaluation de l’avis du 23 octobre concernant CVE-2026-115560. S’il reste une action, qui en est responsable et quand pouvons-nous attendre le prochain suivi ? Merci.

Envoyez-le depuis votre portail d’assistance habituel. Face à un appel inattendu pour une « mise à jour urgente », appliquez les vérifications de notre guide sur le faux support informatique avant de suivre des instructions ou de donner un accès.

Que faire si vous suspectez une compromission ?

Contactez rapidement l’hébergeur et le responsable de la réponse aux incidents. Le guide canadien de réponse aux incidents distingue la détection, le confinement, l’éradication et la récupération. Coordonnez la conservation des éléments utiles et les décisions de reprise avec cette équipe, plutôt que de commencer par supprimer les fichiers suspects.

Changer un mot de passe ne corrige pas PHP. Inversement, installer un correctif ne démontre pas qu’une intrusion antérieure a été éliminée. Demandez de documenter la correction logicielle et le résultat de l’enquête, notamment les identifiants ou sessions à remplacer et le moment approprié. Ne clôturez votre suivi que lorsque les actions restantes ont des responsables nommés.

Clarifiez les responsabilités sur les comptes

En complément de la maintenance serveur, documentez qui gère les accès, la MFA et la récupération dans votre équipe.

Lire le guide de politique pour PME