Blog : PHP2Shell, sécurité des serveurs et assistance d'urgence
Analyse de la situation, tutoriels pour les administrateurs et aides à la décision pour la direction. Classés par thème, chaque article avec ses sources.
Situation et analyse
17 articles
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 →002Pourquoi la faille PHP est devenue publique avant le correctif
Selon des rapports, des détails sur PHP2Shell sont devenus publics avant la fin de l'embargo. Nous expliquons le déroulement et ce qu'il signifie pour votre planification des correctifs.
Lire la suite →003Des autorités mettent des sites hors ligne : ce que les entreprises en retiennent
Mayence, le gouvernement du Land de Hesse et le BKA ont mis des sites hors ligne par précaution. Ce que les entreprises peuvent en retenir pour leur propre décision.
Lire la suite →004Niveau d'alerte orange du BSI : ce que cette évaluation signifie
Le BSI classe PHP2Shell au niveau 3 / orange. Ce que dit l'échelle, ce qu'elle ne dit pas, et comment les entreprises traduisent ce classement en décisions.
Lire la suite →005Ce que CERT-EU et CERT-Bund conseillent pour PHP2Shell
Les organismes officiels sont d'accord : corriger immédiatement, sinon isoler. Nous comparons les recommandations et montrons à quoi ressemble concrètement l'isolation.
Lire la suite →006Règles de protection Cloudflare contre PHP2Shell : ce qu'elles apportent et ce qu'elles n'apportent pas
Cloudflare a déployé tôt des règles de protection contre PHP2Shell. Pourquoi cela aide, pourquoi cela ne remplace pas la mise à jour de PHP et quels paramètres vérifier.
Lire la suite →00722,6 millions d'instances exposées : bien interpréter les chiffres
Unit 42, CybelAngel et d'autres avancent des chiffres très différents sur PHP2Shell. Nous expliquons ce qui a été compté et quel chiffre compte vraiment pour vous.
Lire la suite →008PHP2Shell en cinq minutes : briefing pour la direction
La faille de sécurité PHP2Shell sur une page pour les décideurs : situation, risque, cinq questions à l'informatique et les décisions du jour.
Lire la suite →009La faille de sécurité PHP expliquée simplement
PHP2Shell pour les non-techniciens : avec des images du quotidien, un petit glossaire et trois situations de départ typiques, ce que vous devez faire en tant qu'exploitant de site.
Lire la suite →010PHP2Shell : 15 questions de clients d'hébergeurs
Votre site est chez un hébergeur et vous voulez savoir ce que vous devez faire vous-même pour PHP2Shell ? Voici les 15 questions les plus fréquentes avec de courtes réponses.
Lire la suite →011Pourquoi une mise à jour de WordPress n'aide pas contre PHP2Shell
Après les gros titres, de nombreux exploitants ont mis WordPress à jour et se sentent en sécurité. Pourquoi cela tombe à côté avec PHP2Shell et ce qui compte à la place.
Lire la suite →012PHP2Shell et Log4Shell : ce que les deux failles ont en commun
Beaucoup comparent PHP2Shell à Log4Shell de 2021. Ce que la comparaison apporte, où elle boite et quelles leçons d'alors aident aujourd'hui.
Lire la suite →013Scans de masse visant PHP non corrigé : comment se déroulent les attaques automatisées
Après PHP2Shell, des attaquants balaient Internet de façon automatisée à la recherche de serveurs vulnérables. Comment cela se passe, pourquoi la taille n'a pas d'importance et ce qui vous protège.
Lire la suite →014Le délai entre le correctif et l'attaque
Avec PHP2Shell, des tentatives d'attaque ont eu lieu avant même le correctif. Nous expliquons les phases de la fenêtre, comment mesurer la vôtre et comment la raccourcir.
Lire la suite →015Après PHP2Shell : pourquoi d'autres avis sont probables
PHP2Shell n'est pas clos avec le correctif du 21 octobre. Pourquoi des avis de suite sont à prévoir et comment y préparer votre équipe.
Lire la suite →016PHP2Shell : l'état de la situation après la première semaine
Une semaine après la première tentative d'attaque observée : l'état des correctifs, des alertes des autorités, des attaques et des mises hors ligne, clairement séparé par sources.
Lire la suite →017Faux conseils dangereux sur PHP2Shell qui circulent en ce moment
Bloquer les cookies, masquer les messages d'erreur, ne mettre à jour que le CMS : neuf conseils sur PHP2Shell qui donnent une fausse sécurité, et ce qui compte vraiment.
Lire la suite →Hébergement et distributions
18 articles
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 →019Debian et Ubuntu : mon paquet PHP est-il corrigé ?
Quels paquets PHP Debian et Ubuntu ont corrigés contre PHP2Shell, comment comparer exactement le niveau installé et pourquoi la preuve échoue parfois.
Lire la suite →020RHEL, AlmaLinux et Rocky Linux : vérifier le correctif PHP
Ce que Red Hat a publié sur PHP2Shell, comment prouver le niveau des paquets sur RHEL et ses dérivés et pourquoi un rechargement ne suffit pas.
Lire la suite →021Le dépôt sury.org : des paquets PHP issus d'une source tierce
De nombreux serveurs Debian et Ubuntu obtiennent PHP du dépôt sury. Ce que cela signifie pour les mises à jour, les preuves et les anciennes versions de PHP après PHP2Shell.
Lire la suite →022Le dépôt Remi : garder PHP à jour sur les systèmes RHEL
Remi fournit des versions de PHP actuelles pour la famille RHEL, en module ou installables en parallèle. Voici comment vérifier le niveau après PHP2Shell et éviter les branches oubliées.
Lire la suite →023Pourquoi php -v affiche le même numéro après la mise à jour
La mise à jour est passée, mais php -v indique l'ancienne version. C'est le plus souvent un rétroportage et non une erreur. Voici comment distinguer l'inoffensif des vrais problèmes.
Lire la suite →024Prouver les numéros CVE dans le changelog d'un paquet
Qui doit prouver un correctif PHP à la direction, à des auditeurs ou à des assureurs a besoin de plus qu'un numéro de version. Voici comment l'entrée du changelog devient une preuve.
Lire la suite →025Changer d'hébergeur après un incident de sécurité : à quoi faire attention ?
Après un incident, vouloir un nouvel hébergeur se comprend. Pour que le changement n'emmène pas l'attaquant avec lui, l'ordre des étapes et le choix comptent.
Lire la suite →026Plusieurs versions de PHP sur un serveur : corriger chacune séparément
Sur de nombreux serveurs, trois, quatre installations PHP ou plus coexistent. Après PHP2Shell, chacune doit être trouvée, mise à jour et redémarrée.
Lire la suite →027Désactiver les anciennes versions de PHP dans le panneau d'hébergement
PHP2Shell est une bonne occasion de se débarrasser des anciennes versions de PHP. Voici comment procéder en trois phases pour qu'aucun site ni aucune tâche cron ne tombe en panne sans qu'on s'en aperçoive.
Lire la suite →028Plesk : comprendre les handlers PHP (FPM, FastCGI, module Apache)
Le handler PHP que Plesk utilise pour un site détermine l'isolation, la configuration et le risque. Une comparaison au regard de PHP2Shell.
Lire la suite →029CloudLinux et alt-php : ce que les clients d'hébergement doivent savoir
Sur les serveurs CloudLinux, les sites tournent souvent avec leurs propres paquets alt-php. Chacune de ces versions exige son propre correctif, et seul l'exploitant du serveur peut l'appliquer.
Lire la suite →030PHP sur NAS, pare-feu et appliances : les systèmes oubliés
PHP n'est pas utilisé que par les serveurs web. Les NAS, pare-feu et appareils spécialisés dotés d'une interface web peuvent aussi être concernés. Seul le fabricant peut le plus souvent y appliquer le correctif ; l'accessibilité, vous la réglez vous-même.
Lire la suite →031PHP chez les fournisseurs cloud et PaaS : qui corrige l'environnement d'exécution ?
Sur les services de plateforme, le correctif PHP dépend du modèle d'exploitation. Ce qui compte, c'est l'environnement d'exécution qui sert réellement les requêtes, non l'environnement local ou le code de l'application.
Lire la suite →032Images Docker PHP officielles : tags, digests et reconstruction
Un tag de l'image PHP officielle est un pointeur qui se déplace avec le temps vers de nouveaux états. Qui sait ce que signifient tag, variante et digest choisit la bonne image et peut prouver l'état des correctifs.
Lire la suite →033CI/CD : reconstruire automatiquement les images PHP
Une image vieillit même sans modification de code. Avec des builds planifiés, un contrôle de version et un déploiement par digest, les correctifs PHP arrivent de façon fiable en production.
Lire la suite →034Support à long terme pour les anciennes versions de PHP : options et limites
Qui ne peut pas quitter immédiatement PHP 8.1 ou antérieur trouve un support à long terme auprès de distributions, de fournisseurs tiers et de services commerciaux. Ce que ces voies apportent, ce qu'il vous faut par écrit et où sont les limites.
Lire la suite →035Mettre à jour PHP sous Windows
Sous Windows, il n'existe pas de mise à jour automatique de PHP. Qui choisit la bonne variante, vérifie le téléchargement et redémarre tous les processus applique proprement le correctif PHP2Shell sur chaque machine.
Lire la suite →Détection et forensique
18 articles
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 →037Trouver les processus suspects sur les serveurs Linux
Les processus malveillants se camouflent sous des noms anodins, tournent depuis des dossiers temporaires ou à partir de fichiers supprimés. Quelques commandes en lecture seule permettent de trouver les anomalies et de les situer.
Lire la suite →038Repérer les tâches cron cachées comme porte dérobée
Les attaquants utilisent des tâches planifiées pour revenir après un nettoyage. Voici comment vérifier complètement les crontabs, répertoires cron, minuteries systemd et tâches at, et reconnaître les entrées suspectes.
Lire la suite →039Trouver les fichiers récemment modifiés sur le serveur web
Après une intrusion possible, ce qui compte, c'est ce qui a changé sur le serveur. Voici comment chercher par plages de temps, bien utiliser mtime et ctime et comparer avec les paquets, Git et les sauvegardes.
Lire la suite →040Fichiers PHP dans le dossier de téléversement : bien interpréter les découvertes
Un fichier PHP dans le dossier de téléversement est presque toujours un signal d'alarme, mais pas chacun est du code malveillant. Voici comment évaluer la découverte sans détruire de traces et établir si quelqu'un l'a appelé.
Lire la suite →041Reconnaître le code PHP obfusqué
Un code PHP illisible avec eval et base64_decode est un signe classique de code malveillant injecté. Quels motifs chercher, comment les trouver sans danger et quand l'obfuscation est légitime.
Lire la suite →042Vérifier les connexions sortantes d'un serveur
Un serveur web répond avant tout à des requêtes. S'il établit lui-même des connexions vers des destinations inconnues, cela peut signifier un contrôle par des attaquants ou une fuite de données. Voici comment vérifier et limiter le trafic sortant.
Lire la suite →043Trouver des comptes administrateur inconnus dans le CMS et sur le serveur
Un administrateur inconnu est souvent la porte dérobée la plus simple. Voici comment chercher niveau par niveau des comptes étrangers, y compris ceux que l'interface cache.
Lire la suite →044Trouver et supprimer les clés SSH inconnues
Une clé SSH injectée ouvre la porte aux attaquants même quand tous les mots de passe ont été changés. Voici comment trouver chaque fichier authorized_keys et vérifier chaque entrée.
Lire la suite →045Mineur de cryptomonnaie sur le serveur web : signes et marche à suivre
Un processeur durablement saturé sans visiteurs supplémentaires : ce peut être un mineur de cryptomonnaie. Voici comment vérifier la charge, trouver le processus et ses mécanismes de redémarrage et procéder de façon ordonnée.
Lire la suite →046Le serveur envoie du spam : trouver les causes
Courriels non distribuables, listes de blocage, plaintes : quand votre propre serveur envoie du spam, un script ou une boîte aux lettres détournée en est le plus souvent la cause. Voici comment trouver la source.
Lire la suite →047Spam SEO et pages étrangères dans l'index Google
Soudain, des pages sur des médicaments ou des produits de marque se classent sous votre domaine. Voici comment trouver l'origine du spam SEO et le faire disparaître de l'index.
Lire la suite →048Le site redirige vers des pages étrangères
Des visiteurs atterrissent sur des jeux-concours ou des boutiques douteuses, alors que vous ne voyez rien ? Voici comment trouver la couche où se cache la redirection et la supprimer.
Lire la suite →049Sécuriser les preuves avant de réinstaller le serveur
Une reconstruction élimine l'attaquant, mais aussi toutes les traces. Une heure consacrée à la préservation des preuves permet de dire plus tard ce qui s'est passé.
Lire la suite →050Établir la chronologie d'un incident
Quand l'attaquant est-il arrivé, qu'a-t-il fait, quand cela a-t-il été remarqué ? Une chronologie propre répond à ces questions et sert de base aux notifications, à l'assurance et au rapport.
Lire la suite →051Comparer les fichiers du noyau du CMS avec l'original
La comparaison avec un original sain montre chaque fichier modifié, qu'un scanner le connaisse ou non. Voici comment la mettre en place pour WordPress, les projets Composer et les paquets système.
Lire la suite →052Vérifier la base de données à la recherche de code injecté
Qui ne vérifie que les fichiers en manque la moitié. Voici comment parcourir contenus, paramètres, triggers et comptes de la base de données, en lecture seule et sur une copie.
Lire la suite →053Scanners de logiciels malveillants pour sites web : ce qu'ils trouvent et ce qu'ils manquent
Le scanner ne signale rien, donc tout va bien ? Pas forcément. Quels types de scanners de sites existent, ce que chacun voit et ce qu'il ne peut fondamentalement pas voir.
Lire la suite →Durcissement et configuration
20 articles
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 →055Bien régler memory_limit
memory_limit limite la mémoire par requête PHP. Après PHP2Shell, php.net conseille temporairement le contraire. Ce qui vaut en exploitation normale, en transition et après la mise à jour.
Lire la suite →056Limiter judicieusement post_max_size et upload_max_filesize
Les limites d'upload agissent à trois endroits : le serveur web, PHP et l'application. Voici comment régler les valeurs de façon cohérente, y compris avec les valeurs transitoires de php.net pour PHP2Shell.
Lire la suite →057Désactiver session.upload_progress : correctement et durablement
Le remède contre CVE-2026-115560 et l'une des mesures transitoires PHP2Shell se met en place rapidement. Pour qu'il tienne, il doit être au bon endroit, verrouillé et revérifié après chaque mise à jour.
Lire la suite →058expose_php et en-têtes Server : masquer les indications de version
PHP, Nginx et Apache indiquent par défaut leur numéro de version dans chaque réponse. Cela ne protège pas des attaques, mais offre aux scanners une liste de cibles commode. Voici comment le désactiver tout en gardant la vue d'ensemble.
Lire la suite →059display_errors off : désactiver l'affichage des erreurs en production
Les messages d'erreur PHP visibles révèlent chemins, noms de bases de données et versions. Voici comment les désactiver dans PHP, dans le framework et dans le serveur web, sans perdre les erreurs de vue.
Lire la suite →060php_admin_value : verrouiller les paramètres contre l'écrasement
Un paramètre de sécurité sert à peu de chose si l'application le modifie à nouveau avec une ligne de code. Avec php_admin_value et php_admin_flag, vous fixez des valeurs de façon contraignante pour PHP-FPM et Apache.
Lire la suite →061Définir des limites de mémoire avec systemd et cgroups
Comme mesure transitoire PHP2Shell, php.net recommande memory_limit=-1 et une limite mémoire en dehors de PHP. Voici comment fixer cette limite avec systemd et cgroups, sans qu'un seul worker entraîne tout le service avec lui.
Lire la suite →062Configurer Nginx pour PHP en toute sécurité
La plupart des failles des installations Nginx pour PHP ne viennent pas de Nginx, mais de quelques lignes de la location PHP. Voici comment configurer la transmission à PHP-FPM pour que seuls les scripts voulus soient exécutés.
Lire la suite →063Configurer Apache pour PHP en toute sécurité
Apache est flexible, et c'est précisément ce qui le rend vulnérable aux erreurs de configuration. Voici comment connecter PHP via PHP-FPM, fermer .htaccess comme porte dérobée et régler en toute sécurité les principales options du noyau.
Lire la suite →064Interdire l'exécution de PHP dans les dossiers d'upload
Un webshell a besoin de deux choses : un dossier où il peut être écrit et un serveur qui l'exécute. Voici comment lui retirer la seconde, dans chaque dossier accessible en écriture, pas seulement dans uploads.
Lire la suite →065Filtrer les requêtes d'upload en bordure : chances et risques
Des auteurs spécialisés proposent de bloquer au proxy les requêtes d'upload hors des vraies voies d'upload, jusqu'à ce que PHP soit corrigé. Cela peut aider, mais aussi paralyser formulaires et commandes. Voici comment procéder de façon contrôlée.
Lire la suite →066Mettre en œuvre ModSecurity et l'OWASP Core Rule Set
Un pare-feu applicatif web maison avec ModSecurity et l'OWASP Core Rule Set est gratuit et puissant, mais ne fonctionne pas tout seul. Voici comment choisir le moteur, démarrer sans pannes et ajuster les règles.
Lire la suite →067Configurer Fail2ban pour les serveurs web
Fail2ban bannit les adresses qui se font remarquer à répétition dans les journaux. Pour les serveurs web, il fournit des filtres prêts à l'emploi, et quelques lignes suffisent pour en ajouter. Voici comment le configurer sans vous bloquer, ni vos clients.
Lire la suite →068Pare-feu pour serveurs web : n'ouvrir que les ports nécessaires
Un serveur web n'a généralement besoin que de deux ports vers l'extérieur. Pourtant, sur de nombreux serveurs, des bases de données, PHP-FPM ou des interfaces d'administration écoutent sur Internet. Voici comment trouver les services ouverts et fermer ce qui n'est pas nécessaire.
Lire la suite →069Mises à jour de sécurité automatiques sur les serveurs Linux
Selon des rapports, les distributions ont livré des backports PHP en partie dès le 21 octobre 2026, jour des correctifs. Qui utilisait les mises à jour de sécurité automatiques les avait vite sur le serveur. Pour qu'elles agissent aussi, il faut redémarrages, sources tierces et contrôle.
Lire la suite →070Moindre privilège : les droits de l'utilisateur du serveur web
Le code injecté s'exécute avec les droits de l'utilisateur du serveur web. Ce que ce compte peut faire détermine jusqu'où va un attaquant. Voici comment limiter shell, sudo, cron, base de données et système de fichiers au strict nécessaire.
Lire la suite →071Protéger les espaces admin par IP, VPN ou protection complémentaire
Pourquoi le back-office d'un site n'a pas à être accessible au monde entier, et comment le protéger par liste d'IP, VPN ou authentification préalable, sans vous verrouiller vous-même.
Lire la suite →072Bien configurer TLS et HTTPS
Quelles versions de TLS et quelles suites de chiffrement un serveur web devrait proposer aujourd'hui, sur quoi reposent les recommandations et comment vérifier Nginx, Apache et les connexions sortantes de PHP.
Lire la suite →073Benchmarks CIS et modules du BSI pour serveurs web
Quels standards de durcissement existent pour les serveurs web Linux, en quoi les benchmarks CIS et les modules de l'IT-Grundschutz diffèrent, et comment en faire une exigence vérifiable pour vos serveurs PHP.
Lire la suite →Développement sécurisé
16 articles
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 →075Protection CSRF dans les applications PHP
Comment les développeurs empêchent le Cross-Site Request Forgery dans les applications PHP : des jetons pour chaque requête qui modifie quelque chose, un contrôle de l'origine dans l'en-tête et des cookies SameSite comme couche supplémentaire.
Lire la suite →076Valider et filtrer les saisies en PHP avec filter_var
Comment les développeurs contrôlent les saisies en PHP avec filter_var, filter_input_array et des listes autorisées, quels filtres sont obsolètes et pourquoi la validation ne remplace ni les requêtes préparées ni l'encodage en sortie.
Lire la suite →077Empêcher l'injection de commandes en PHP
Comment les développeurs évitent l'injection de commandes en PHP : remplacer les commandes système par des fonctions PHP, utiliser proc_open sans shell, contrôler les arguments et repérer les points dangereux du code existant.
Lire la suite →078Empêcher le Server-Side Request Forgery (SSRF) en PHP
Comment les développeurs empêchent une application PHP d'interroger des systèmes internes pour le compte de tiers : listes autorisées, restriction des protocoles, contrôle de l'adresse résolue et limites au niveau du réseau.
Lire la suite →079Empêcher les XML External Entities (XXE) en PHP
Comment les développeurs traitent le XML en toute sécurité en PHP : comportement par défaut de libxml, options risquées comme LIBXML_NOENT, protection avec un chargeur d'entités et LIBXML_NO_XXE, et entrées XML cachées typiques.
Lire la suite →080Type juggling en PHP : les comparaisons lâches comme risque de sécurité
Pourquoi les comparaisons lâches avec == peuvent conduire à des failles de sécurité en PHP, ce qui a changé avec PHP 8.0 et comment écrire des comparaisons robustes pour les connexions, les jetons et les autorisations.
Lire la suite →081Nombres aléatoires et jetons sûrs en PHP avec random_bytes
Comment les développeurs génèrent en PHP des jetons pour les liens de mot de passe, les clés d'API et les codes à usage unique : sources cryptographiquement sûres, longueur suffisante, stockage sous forme de hachage et validité limitée.
Lire la suite →082Bien protéger les identifiants et les fichiers .env
Comment protéger mots de passe de base de données, clés d'API et autres secrets dans les projets PHP : fichiers .env hors du webroot, blocage dans le serveur web, droits étroits et remplacement ordonné après un incident.
Lire la suite →083Dossier .git public : une fuite de données sous-estimée
Pourquoi un webroot déployé avec Git peut exposer tout le code source avec son historique, comment le vérifier, le bloquer immédiatement et mettre en place un déploiement durable sans dossier .git.
Lire la suite →084Fichiers de sauvegarde dans le webroot : .zip, .sql et .bak
Pourquoi les dumps de base de données, archives et copies de sauvegarde dans le répertoire public comptent parmi les fuites de données les plus fréquentes, comment les trouver, les bloquer et déterminer s'ils ont été appelés.
Lire la suite →085Fichiers phpinfo() : pourquoi ils doivent disparaître
Après PHP2Shell, de nombreux administrateurs créent vite un info.php. Pourquoi de tels fichiers constituent une fuite de données, comment les trouver et quelles méthodes de vérification sont préférables.
Lire la suite →086Garder les dépendances à jour : Composer, npm et extensions
Un projet repose sur trois mondes de paquets : Composer, npm et extensions CMS. Comment tous les garder à jour avec un rythme fixe, des responsabilités claires et des tests.
Lire la suite →087Revue de code de sécurité pour les projets PHP
Comment les équipes examinent de façon ciblée leur propre code PHP à la recherche de failles de sécurité : types de revues, fonctions critiques, outils pertinents et liste de contrôle.
Lire la suite →088Journaliser en sécurité : consigner les erreurs sans fuite de données
Les journaux aident au dépannage et à la forensique, mais deviennent vite eux-mêmes une fuite de données. Ce que les applications PHP devraient journaliser, ce qu'elles ne devraient jamais consigner et comment protéger les journaux.
Lire la suite →089Sécuriser les API REST en PHP
Les interfaces sont souvent moins bien protégées que le site web placé devant. Les règles essentielles pour les API REST en PHP, de l'autorisation par objet à la limitation du débit.
Lire la suite →Direction et aspects juridiques
14 articles
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 →091Sous-traitance de données lorsque des prestataires accèdent aux serveurs
Qui laisse des tiers accéder à des serveurs contenant des données clients a généralement besoin d'un contrat de sous-traitance. Ce qu'exige l'art. 28 du RGPD et comment organiser les accès d'urgence dans le respect de la protection des données.
Lire la suite →092La gestion des vulnérabilités dans les PME
Aucune PME ne peut traiter immédiatement chaque alerte. Un cycle léger (recenser, évaluer, décider, prouver) garantit que l'essentiel est fait en premier.
Lire la suite →093Savoir ce qui tourne : l'inventaire de tous les sites et serveurs
Avec PHP2Shell, beaucoup n'ont pas échoué sur le correctif, mais sur la question de savoir où PHP tourne. Voici comment bâtir un inventaire de tous vos sites et serveurs.
Lire la suite →094La gestion des correctifs comme processus plutôt que pompiers
Qui ne corrige que lorsque tout brûle perd du temps en cas de crise. Comment un processus avec classes, fenêtres et preuves relie routine et urgence.
Lire la suite →095Contacts d'urgence : qui faut-il prévenir, et quand ?
En situation de crise, ce qui compte, c'est qui l'on joint et quand. Comment bâtir une liste de contacts d'urgence informatiques, avec déclencheurs, suppléances et informations nécessaires à chaque appel.
Lire la suite →096Ce que coûte un serveur piraté : les postes de coûts
Un serveur web piraté coûte plus que sa réparation. Quels postes de coûts apparaissent et comment justifier un budget de prévention avec vos propres chiffres.
Lire la suite →097Informer les clients après un incident
Obligation ou choix volontaire : comment décider, après un incident, qui informer, quels canaux sont sûrs et comment préparer votre service client.
Lire la suite →098La chaîne d'approvisionnement du web : agence, hébergeur, éditeur d'extensions
PHP2Shell a montré combien de maillons séparent un correctif de votre site. Comment connaître, sécuriser votre chaîne d'approvisionnement et absorber la défaillance d'un maillon.
Lire la suite →099Sensibilisation à la sécurité pour admins et rédacteurs : l'équipe web
Celui qui gère des sites décide chaque jour de la sécurité, souvent sans s'en rendre compte. Comment former admins et rédacteurs selon leur rôle, sans déluge de diapositives.
Lire la suite →100Exercice d'urgence sur table : simuler un incident de serveur web
Un exercice sur table coûte un après-midi et montre si votre plan d'urgence tient. Vous trouverez ici un scénario prêt à l'emploi pour un incident sur un serveur web PHP.
Lire la suite →101ISO 27001 et TISAX : ce que cela implique pour les serveurs web
Qui exploite un SMSI selon ISO 27001 ou détient un label TISAX doit penser aux serveurs web. Voici les exigences concernées et les preuves qui comptent après PHP2Shell.
Lire la suite →102VdS 10000 : la sécurité de l'information pour les petites et moyennes entreprises
La VdS 10000 est un cadre léger de sécurité de l'information pour les PME. Ce qu'elle exige, ce qu'apporte 2025 et ce que cela implique pour les sites et serveurs web.
Lire la suite →103Retour d'expérience : s'améliorer après l'incident
Après l'incident vient le prochain. Une réunion de bilan structurée, sans recherche de coupable, fait d'une mauvaise semaine un progrès mesurable.
Lire la suite →Aides à la décision
10 articles
Corriger, couper ou attendre ? Une aide à la décision face à la faille PHP
Face à une faille PHP critique, les responsables doivent décider vite. Cette aide ordonne les trois options, donne des critères et montre quand attendre est défendable.
Lire la suite →105WAF ou mise à jour : pourquoi il vous faut les deux
Un pare-feu d'applications web peut intercepter des attaques, mais ne ferme aucune faille de l'interpréteur PHP. Quand un WAF aide, où il s'arrête et comment combiner les deux.
Lire la suite →106Réinstaller ou nettoyer le serveur ? La décision après une compromission
Après une intrusion, deux voies s'offrent : nettoyer le serveur ou le reconstruire. Quels critères décident, et pourquoi l'ordre compte plus que le choix.
Lire la suite →107Corriger soi-même ou faire appel à un prestataire ? Une pesée honnête
Toutes les situations de sécurité n'exigent pas une aide externe. Avec ces critères et un court auto-test, décidez si votre équipe gère PHP2Shell seule ou a besoin de soutien.
Lire la suite →108Choisir un prestataire de sécurité informatique : 12 questions avant la commande
Trouver sous la pression du temps un bon prestataire de sécurité est difficile. Ces douze questions aident à comparer objectivement les offres, sans se laisser séduire par les promesses publicitaires.
Lire la suite →109Hébergement managé ou serveur propre ? Le comparatif sécurité
PHP2Shell a été un test de résistance pour chaque modèle d'exploitation. Le comparatif montre quand l'hébergement managé est plus sûr, quand le serveur propre l'est, et quelles formes mixtes ont fait leurs preuves.
Lire la suite →110Mise à niveau de PHP ou rétroportage ? La décision pour les anciens systèmes
Pour les anciennes versions de PHP, plusieurs voies existent après PHP2Shell : rétroportage de la distribution, source tierce, correctif source, support longue durée ou mise à niveau. Ce que vaut chaque voie et combien de temps elle tient.
Lire la suite →111Changer de CMS après le piratage ? Quand cela aide, et quand non
Après une intrusion, la confiance dans le CMS a souvent disparu. Mais un nouveau système résout rarement la vraie cause. Quand le changement est judicieux et comment il réussit proprement.
Lire la suite →112Sites statiques : moins de PHP, moins de surface d'attaque
Un site statique diffuse des fichiers HTML finis et n'a pas besoin de PHP sur le serveur. Cela réduit nettement la surface d'attaque, mais apporte ses propres limites et obligations.
Lire la suite →113Test d'intrusion, bug bounty ou scan de vulnérabilités ? Choisir la méthode adaptée
Scan, test d'intrusion et bug bounty examinent les sites de façons très différentes. Ce que fait chaque méthode, où elle échoue et quel ordre convient à votre entreprise.
Lire la suite →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.