Questions fréquentes

PHP2Shell désigne deux failles critiques dans PHP lui-même (CVE-2026-109618 et CVE-2026-109619, CVSS 9.2). Elles peuvent permettre à des attaquants d'exécuter du code malveillant sur le serveur sans authentification. Des correctifs sont disponibles depuis le 21 octobre 2026.

Les corrections sont incluses dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les hébergeurs et les distributions appliquent parfois des backports sans modifier le numéro de version. Ce qui compte, c'est l'état du paquet ou la confirmation écrite du fournisseur.

Non. La faille se trouve dans PHP, pas dans le CMS. Une mise à jour du CMS ne la corrige pas. Et un correctif PHP ne supprime pas le code malveillant qui a été introduit auparavant.

Nous travaillons à distance et démarrons dès que les accès sont disponibles. Indiquez-nous par WhatsApp votre système, votre version de PHP et ce que vous avez observé. Nous définissons ensuite la marche à suivre directement.

Oui. Nous travaillons directement pour des entreprises, en arrière-plan pour le compte d'agences et en concertation avec votre hébergeur lorsque celui-ci gère le serveur.

Si des données personnelles peuvent être concernées, l'art. 33 du RGPD prévoit en règle générale un délai de notification de 72 heures à compter de la prise de connaissance. Vous vérifiez avec votre délégué à la protection des données si ce délai s'applique. Nous fournissons la documentation technique correspondante.

Non. Les failles se trouvent dans PHP, donc dans le langage de programmation sur lequel fonctionnent WordPress, Shopware, TYPO3 et de nombreux autres systèmes. Une mise à jour du CMS ne les referme donc pas. Ce qui compte, c'est la version de PHP sur le serveur.

Avec l'hébergement mutualisé, c'est en règle générale l'hébergeur qui installe la mise à jour de PHP. Vous devriez néanmoins vous faire confirmer par écrit que la version de PHP que vous utilisez a été corrigée et redémarrée. La mise à jour ne répond pas à la question de savoir si quelque chose s'est produit avant le correctif.

Le nom décrit la conséquence : via PHP, un attaquant peut, dans le pire des cas, obtenir une ligne de commande, c'est-à-dire un shell, sur le serveur. Les désignations officielles sont les numéros CVE-2026-109618 et CVE-2026-109619.

Pas nécessairement. Certains fournisseurs ont mis des sites web hors ligne par précaution, comme le recommande le BSI lorsqu'une mise à jour n'est pas possible immédiatement. C'est une mesure de protection et non la preuve d'une attaque.

Cela peut suffire si l'hébergeur confirme l'état des paquets par écrit et que tous les processus PHP ont été redémarrés. Le numéro de version affiché ne prouve rien à lui seul, car les distributions appliquent des backports. Quant à savoir si le serveur a déjà été attaqué auparavant, un correctif n'y répond de toute façon pas.

Pas nécessairement. Le BSI recommande de déconnecter temporairement les serveurs web du réseau lorsque la mise à jour n'est pas possible immédiatement. Nous décidons ensemble, après l'inventaire, si c'est nécessaire dans votre cas.

Non. PHP2Shell se trouve dans PHP lui-même, pas dans le CMS. Une mise à jour du CMS reste judicieuse, mais elle ne referme pas cette faille.

Pour ces versions, le projet PHP ne publie plus de mises à jour officielles, seulement des backports minimaux du code source pour 7.4, 8.0 et 8.1. Nous sécurisons le serveur à titre transitoire et planifions avec vous le passage à une version prise en charge.

Selon l'art. 33 du RGPD, à partir du moment où le responsable du traitement a pris connaissance de la violation. À quel moment on peut l'admettre dans un cas particulier relève d'une appréciation juridique. Documentez donc précisément quand qui a eu quelle information.

Non. Une faille seule n'est pas encore une violation de la protection des données personnelles. La notification peut devenir obligatoire s'il existe des indices que des personnes non autorisées ont eu ou pu avoir accès à de telles données, et qu'il en résulte un risque pour les personnes concernées.

L'art. 33, par. 4, du RGPD autorise à fournir les informations de manière échelonnée lorsqu'elles ne peuvent pas être fournies en même temps. Une notification tardive doit être motivée. Attendre une clarté complète n'est donc en règle générale pas une raison de laisser le délai s'écouler.

L'obligation de notification incombe au responsable du traitement, donc en général à l'entreprise qui exploite le site. Un sous-traitant comme l'hébergeur doit informer le responsable du traitement sans délai, conformément à l'art. 33, par. 2, du RGPD.

Auprès de l'autorité de contrôle compétente en matière de protection des données ; pour les entreprises en Allemagne, il s'agit le plus souvent de l'autorité du Land où elles ont leur siège. La plupart des autorités proposent des formulaires en ligne à cet effet.