Un PHP non corrigé est une porte ouverte. Nous la refermons.
Assistance d'urgence à distance pour les entreprises en Europe : corriger PHP, rechercher les traces d'intrusion, supprimer le code malveillant, durcir le serveur. Immédiatement, avec des partenaires spécialisés, jusqu'à la clôture et la documentation de l'incident.
$ php -v PHP 8.3.35 (cli) (built: Sep 30 2026) ! État avant le correctif du 21 octobre 2026 $ phpsos pruefen --ziel produktion Mode d'exécution .. php-fpm CVE-2026-109618 .. ouvert CVE-2026-109619 .. ouvert Redémarrage des workers .. en attente $ phpsos absichern [ok] Paquet 8.3.36 installé [ok] tous les workers redémarrés [ok] Système de fichiers analysé à la recherche de webshells [ok] Rapport pour la direction établi
- Made in GermanySécurité informatique venue d'Allemagne, travail conforme au droit européen de la protection des données.
- Plus de 25 ansSpécialisés depuis plus de 25 ans dans la sécurité informatique et l'exploitation de serveurs, avec notre réseau de partenaires.
- Réseau de partenairesDes experts en cybersécurité spécialisés en analyse forensique, tests d'intrusion et durcissement de serveurs, coordonnés par un seul interlocuteur.
Vous êtes concerné ? Appelez-nous. Nous vous aidons.
Piraté, bloqué, webshell découvert ou doute sur l'impact de PHP2Shell : contactez-nous maintenant. Nous prenons le relais dès le premier message, à distance et sans déplacement.
Votre PHP est-il déjà corrigé ?
Saisissez votre version de PHP. Le test la compare aux avis de sécurité de php.net et indique la suite à donner. Important : même une version corrigée ne prouve pas que rien ne s'est produit avant la mise à jour.
Quel est le degré d'urgence de votre situation ?
Quatre questions, une évaluation, les premières mesures et un message WhatsApp prêt à nous envoyer. Au niveau 3 : ne rien supprimer, ne rien réinstaller, préserver les traces.
De l'appel d'urgence au serveur durci
Nous prenons en charge la technique et fournissons les justificatifs dont la direction, la protection des données et l'assurance ont besoin.
Assistance immédiate PHP2Shell : aide face à la faille de sécurité PHP
Nous corrigeons PHP2Shell sur vos serveurs web à distance : inventaire, correctif ou mesure transitoire, redémarrage de tous les workers et attestation écrite.
Lire la suite →02Site web piraté, que faire ? Aide d'urgence à distance
Votre site web est piraté ou se comporte de façon inhabituelle ? Nous prenons en charge à distance le confinement, la préservation des traces, le nettoyage et la documentation.
Lire la suite →03Service de correctifs PHP : mise à jour installée, avec redémarrage et attestation
Nous installons la mise à jour PHP sur vos serveurs, redémarrons tous les processus PHP et fournissons une attestation écrite de la version, de l'état des paquets et du redémarrage.
Lire la suite →04Durcissement de serveurs web PHP
Nous durcissons vos serveurs web PHP selon un plan établi : isolation par site, configuration PHP sûre, droits sur les fichiers, accès, journaux et sauvegardes.
Lire la suite →05Faire supprimer malwares et webshells d'un site web
Nous supprimons code malveillant, webshells et portes dérobées des sites web et des serveurs, reconstruisons à partir de sources fiables et refermons la porte d'entrée.
Lire la suite →06Réponse aux incidents en cas d'attaques de serveurs
Traitement structuré des incidents lors d'attaques contre des serveurs web : vue d'ensemble, confinement, élimination, rétablissement et suivi avec des rôles fixes.
Lire la suite →Notre façon de travailler en cas d'urgence
Des étapes claires, un seul interlocuteur, tout à distance. Des spécialistes de notre réseau de partenaires interviennent si une analyse forensique ou un test d'intrusion est nécessaire.
Faire le point
Vous nous écrivez par WhatsApp ou vous nous appelez. Nous clarifions le système, la version de PHP, l'hébergeur et les observations.
Préserver et colmater
Préserver les traces, corriger PHP ou mettre en place des mesures transitoires, redémarrer tous les workers, justifier l'état des correctifs.
Vérifier et nettoyer
Rechercher des traces d'intrusion dans les fichiers, la base de données, les comptes et les journaux. Supprimer les webshells et les portes dérobées.
Durcir et rendre compte
Durcir la configuration, mettre en place la supervision, rapport pour la direction, la protection des données et l'assurance.
Correctif impossible pour l'instant ? Mesures transitoires
php.net indique des paramètres qui compliquent les vecteurs d'attaque connus jusqu'à l'installation de la mise à jour. Choisissez votre mode d'exécution, copiez les lignes, puis redémarrez tous les processus PHP.
Le BSI (office fédéral allemand de la sécurité des systèmes d'information) recommande : si la mise à jour n'est pas possible immédiatement, déconnecter temporairement le serveur web du réseau.
Mesures transitoires selon php.net, elles ne remplacent pas la mise à jour. memory_limit=-1 uniquement en combinaison avec une limite de mémoire via conteneur ou cgroup. Sauvegardez d'abord la configuration.
Qui fait quoi ? Le vide entre l'hébergeur et l'agence
De nombreuses entreprises comptent sur le fait que « quelqu'un » applique le correctif. En règle générale, la répartition est la suivante :
| Tâche | Hébergeur (hébergement mutualisé) | Agence / web design | PHP SOS |
|---|---|---|---|
| Mettre à jour le paquet PHP | le plus souvent oui | le plus souvent non | oui, ou avec votre hébergeur |
| Redémarrer tous les workers et le justifier | en partie | non | oui, avec justificatif |
| Vérifier si une intrusion a eu lieu avant le correctif | en règle générale non | en partie | oui |
| Supprimer les webshells et les portes dérobées | en règle générale non | en partie | oui |
| Rapport pour la direction, la protection des données, l'assurance | non | rarement | oui |
| Durcissement et supervision continue | en partie | en partie | oui |
Ce qui est établi et ce que vous faites maintenant
Faits tirés des avis de php.net et du BSI (office fédéral allemand de la sécurité des systèmes d'information), présentés pour la direction et les administrateurs.
Qu'est-ce que PHP2Shell ? La faille expliquée simplement
PHP2Shell désigne deux failles critiques dans PHP lui-même, par lesquelles des attaquants peuvent exécuter du code sur des serveurs web sans authentification. La situation en termes clairs.
Lire la suite →CVE-2026-109618 : RCE par état de mémoire insuffisante
CVE-2026-109618 est l'une des deux failles PHP2Shell : un état de mémoire insuffisante peut interrompre PHP en plein traitement de la requête. Corrigée à partir de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
Lire la suite →CVE-2026-109619 : RCE par état global périmé
CVE-2026-109619 est la seconde faille PHP2Shell : l'état interne d'une requête peut subsister après la libération de la mémoire et être exploité par la requête suivante dans le même worker.
Lire la suite →CVE-2026-115560 : avis sur Session Upload Progress
CVE-2026-115560 est un avis de php.net du 23.10.2026 : exécution de code possible uniquement avec une configuration de session inhabituelle. Parade jusqu'à la prochaine version : session.upload_progress.enabled=0.
Lire la suite →Quelles versions de PHP sont concernées ?
PHP2Shell est corrigée dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour PHP 8.1 et antérieur, il n'existe plus de mises à jour officielles. Le tableau montre l'état par branche.
Lire la suite →Bien vérifier la version de PHP et l'état des correctifs
La version de PHP affichée ne dit pas à elle seule si PHP2Shell est refermée. L'état des paquets, les backports et le fait que les nouveaux processus tournent réellement sont déterminants.
Lire la suite →Pour votre plateforme et votre serveur
Où se cache le code malveillant dans WordPress, Shopware ou TYPO3, et comment appliquer réellement le correctif sur Plesk, cPanel ou dans un conteneur.
Plateformes
Serveurs et hébergement
Chaque secteur a des données différentes à perdre
Données de santé, secret professionnel des mandants, données de paiement : nous adaptons la vérification et le rapport à vos obligations.
10 étapes avant que nous prenions le relais
Cochez ce qui est fait. La liste reste enregistrée dans votre navigateur.
Les coches sont enregistrées uniquement dans votre navigateur.
72 heures, NIS2, assurance
Repères généraux pour la direction. Pas de conseil juridique.
Obligation de notification RGPD : 72 heures après l'incident
Après une attaque contre un serveur web, une obligation de notification à l'autorité de contrôle peut exister. Voici, en termes généraux, quand les 72 heures courent et ce qui en fait partie.
Lire la suite →NIS2 et sécurité des serveurs web
NIS2 impose à de nombreuses entreprises une gestion des risques et des notifications. Voici, en termes généraux, ce que cela signifie pour les serveurs web et où trouver des informations fiables.
Lire la suite →Cyberassurance : ce qui compte en cas de sinistre
Lors d'une attaque, l'information rapide de l'assureur, des preuves sauvegardées et des démarches coordonnées décident souvent de la prise en charge. Voici les points typiques en termes généraux.
Lire la suite →Responsabilité de la direction en cas de failles de sécurité informatique
La sécurité informatique est une mission de la direction. Voici, en termes généraux, quels devoirs de diligence s'appliquent et comment les dirigeants prennent des décisions traçables face à des failles comme PHP2Shell.
Lire la suite →Articles spécialisés pour administrateurs et développeurs
Chronologie PHP2Shell : du 17 au 25 octobre 2026
Toutes les dates documentées sur PHP2Shell en un coup d'œil, de la première tentative d'attaque observée à la situation au 25 octobre 2026, et ce qu'il en découle pour votre contrôle.
Lire la suite →Confirmation de mise à jour PHP par l'hébergeur : comment demander l'état du correctif
Après PHP2Shell, une version PHP affichée prouve peu de choses. Ce modèle vous permet d'exiger de votre hébergeur une confirmation que vous pouvez documenter.
Lire la suite →Détecter et supprimer un webshell
Comment repérer les portes dérobées sur des serveurs web PHP sans détruire les traces, et pourquoi la simple suppression suffit rarement.
Lire la suite →Trouver une backdoor WordPress : repérer les portes dérobées méthodiquement
Où les portes dérobées se cachent typiquement dans WordPress et comment les admins les repèrent méthodiquement avec WP-CLI et quelques commandes.
Lire la suite →Configurer php.ini de façon sécurisée
Quels réglages de php.ini réduisent la surface d'attaque, comment les protéger contre l'écrasement et ce qui s'applique en plus après PHP2Shell.
Lire la suite →Bien utiliser PHP disable_functions
disable_functions permet de bloquer des fonctions PHP à risque. Comment définir la liste en fonction de votre application sans paralyser le site.
Lire la suite →Situation, tutoriels, aides à la décision
Du niveau d'alerte du BSI aux journaux des modifications de paquets, jusqu'à la question de savoir s'il faut réinstaller ou nettoyer. Chaque article avec ses sources.
PHP2Shell : ce qui est établi et ce qui ne l'est pas
Une vérification des faits sur PHP2Shell : quelles affirmations proviennent de sources primaires, lesquelles de reportages et lesquelles ne tiennent pas.
Lire la suite →Modifier la version de PHP dans l'espace client de l'hébergeur
Comment changer la version de PHP dans l'espace client de votre hébergeur, quelle version choisir et ce qu'il faut vérifier avant et après.
Lire la suite →Signal d'alerte : le serveur web lance un shell
Lorsqu'un processus PHP-FPM ou serveur web lance un shell, c'est l'un des signaux d'alerte les plus forts d'une intrusion. Voici comment vérifier l'arbre des processus, situer les exceptions et surveiller durablement ce schéma.
Lire la suite →Isoler les pools PHP-FPM site par site
Un pool dédié par site est un début, pas une fin. Voici comment vérifier les pools existants et durcir sockets, extensions, pages de statut, ressources et journaux.
Lire la suite →Stocker les mots de passe en PHP : bien utiliser password_hash
Comment les développeurs stockent les mots de passe en PHP avec password_hash et password_verify, choisissent le bon algorithme et remplacent d'anciens hachages MD5 ou SHA-1 sans réinitialisation de mot de passe pour tous les utilisateurs.
Lire la suite →Contrats avec les prestataires informatiques : définir clairement les obligations de sécurité
PHP2Shell a montré combien il est souvent flou de savoir qui doit appliquer les correctifs. Quelles obligations de sécurité doivent figurer dans les contrats avec une agence, un hébergeur et un prestataire informatique.
Lire la suite →Le langage de programmation PHP, expliqué simplement
Comment PHP génère une page, ce que sont SAPI, PHP-FPM et OPcache, et pourquoi c'est précisément ce qui détermine la sécurité. Avec un glossaire de tous les termes techniques.
Qu'est-ce que PHP2Shell ?
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.
Quelles versions de PHP sont sûres ?
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.
Une mise à jour de WordPress ou de la boutique suffit-elle ?
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.
En combien de temps pouvez-vous intervenir ?
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.
Travaillez-vous aussi pour des agences et des clients d'hébergeurs ?
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.
Devons-nous déclarer l'incident ?
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.
Chaque heure compte. Écrivez-nous maintenant.
Décrivez brièvement votre système, votre version de PHP et ce que vous avez observé. Nous vous répondons, faisons le point et travaillons à distance jusqu'à la clôture et la documentation de l'incident.