# Blog : PHP2Shell, sécurité des serveurs et assistance d'urgence

> Blog sur PHP2Shell et la sécurité des serveurs : situation, hébergement, détection, durcissement, développement sécurisé, direction et aides à la décision.

Source : https://phpsos.de/fr/blog/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

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.

- [PHP2Shell : ce qui est établi et ce qui ne l'est pas](https://phpsos.de/fr/blog/php2shell-was-belegt-ist/): Une vérification des faits sur PHP2Shell : quelles affirmations proviennent de sources primaires, lesquelles de reportages et lesquelles ne tiennent pas.
- [Pourquoi la faille PHP est devenue publique avant le correctif](https://phpsos.de/fr/blog/php-luecke-vorzeitig-bekannt/): 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.
- [Des autorités mettent des sites hors ligne : ce que les entreprises en retiennent](https://phpsos.de/fr/blog/behoerden-webseiten-offline/): 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.
- [Niveau d'alerte orange du BSI : ce que cette évaluation signifie](https://phpsos.de/fr/blog/bsi-warnstufe-orange-erklaert/): 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.
- [Ce que CERT-EU et CERT-Bund conseillent pour PHP2Shell](https://phpsos.de/fr/blog/cert-eu-empfehlungen-php/): Les organismes officiels sont d'accord : corriger immédiatement, sinon isoler. Nous comparons les recommandations et montrons à quoi ressemble concrètement l'isolation.
- [Règles de protection Cloudflare contre PHP2Shell : ce qu'elles apportent et ce qu'elles n'apportent pas](https://phpsos.de/fr/blog/cloudflare-waf-php2shell/): 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.
- [22,6 millions d'instances exposées : bien interpréter les chiffres](https://phpsos.de/fr/blog/exponierte-instanzen-einordnen/): 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.
- [PHP2Shell en cinq minutes : briefing pour la direction](https://phpsos.de/fr/blog/php2shell-briefing-geschaeftsfuehrung/): 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.
- [La faille de sécurité PHP expliquée simplement](https://phpsos.de/fr/blog/php-luecke-einfach-erklaert/): 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.
- [PHP2Shell : 15 questions de clients d'hébergeurs](https://phpsos.de/fr/blog/fragen-von-hosting-kunden/): 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.
- [Pourquoi une mise à jour de WordPress n'aide pas contre PHP2Shell](https://phpsos.de/fr/blog/warum-wordpress-update-nicht-hilft/): 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.
- [PHP2Shell et Log4Shell : ce que les deux failles ont en commun](https://phpsos.de/fr/blog/php2shell-und-log4shell/): Beaucoup comparent PHP2Shell à Log4Shell de 2021. Ce que la comparaison apporte, où elle boite et quelles leçons d'alors aident aujourd'hui.
- [Scans de masse visant PHP non corrigé : comment se déroulent les attaques automatisées](https://phpsos.de/fr/blog/automatisierte-massenscans/): 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.
- [Le délai entre le correctif et l'attaque](https://phpsos.de/fr/blog/zeitfenster-patch-angriff/): 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.
- [Après PHP2Shell : pourquoi d'autres avis sont probables](https://phpsos.de/fr/blog/weitere-php-meldungen/): 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.
- [PHP2Shell : l'état de la situation après la première semaine](https://phpsos.de/fr/blog/lagebild-erste-woche/): 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.
- [Faux conseils dangereux sur PHP2Shell qui circulent en ce moment](https://phpsos.de/fr/blog/gefaehrliche-falschtipps/): 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.
- [Modifier la version de PHP dans l'espace client de l'hébergeur](https://phpsos.de/fr/blog/php-version-hosting-aendern/): 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.
- [Debian et Ubuntu : mon paquet PHP est-il corrigé ?](https://phpsos.de/fr/blog/debian-ubuntu-paket-gepatcht/): Quels paquets PHP Debian et Ubuntu ont corrigés contre PHP2Shell, comment comparer exactement le niveau installé et pourquoi la preuve échoue parfois.
- [RHEL, AlmaLinux et Rocky Linux : vérifier le correctif PHP](https://phpsos.de/fr/blog/rhel-almalinux-rocky-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.
- [Le dépôt sury.org : des paquets PHP issus d'une source tierce](https://phpsos.de/fr/blog/sury-repository-php/): 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.
- [Le dépôt Remi : garder PHP à jour sur les systèmes RHEL](https://phpsos.de/fr/blog/remi-repository-php/): 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.
- [Pourquoi php -v affiche le même numéro après la mise à jour](https://phpsos.de/fr/blog/php-v-zeigt-alte-nummer/): 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.
- [Prouver les numéros CVE dans le changelog d'un paquet](https://phpsos.de/fr/blog/cve-im-changelog-nachweisen/): 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.
- [Changer d'hébergeur après un incident de sécurité : à quoi faire attention ?](https://phpsos.de/fr/blog/hoster-wechseln-nach-vorfall/): 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.
- [Plusieurs versions de PHP sur un serveur : corriger chacune séparément](https://phpsos.de/fr/blog/mehrere-php-versionen-server/): 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.
- [Désactiver les anciennes versions de PHP dans le panneau d'hébergement](https://phpsos.de/fr/blog/alte-php-versionen-abschalten/): 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.
- [Plesk : comprendre les handlers PHP (FPM, FastCGI, module Apache)](https://phpsos.de/fr/blog/plesk-php-handler/): Le handler PHP que Plesk utilise pour un site détermine l'isolation, la configuration et le risque. Une comparaison au regard de PHP2Shell.
- [CloudLinux et alt-php : ce que les clients d'hébergement doivent savoir](https://phpsos.de/fr/blog/cloudlinux-alt-php/): 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.
- [PHP sur NAS, pare-feu et appliances : les systèmes oubliés](https://phpsos.de/fr/blog/php-auf-nas-und-appliances/): 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.
- [PHP chez les fournisseurs cloud et PaaS : qui corrige l'environnement d'exécution ?](https://phpsos.de/fr/blog/paas-php-laufzeit/): 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.
- [Images Docker PHP officielles : tags, digests et reconstruction](https://phpsos.de/fr/blog/offizielle-php-docker-images/): 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.
- [CI/CD : reconstruire automatiquement les images PHP](https://phpsos.de/fr/blog/php-images-in-ci-neu-bauen/): 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.
- [Support à long terme pour les anciennes versions de PHP : options et limites](https://phpsos.de/fr/blog/langzeitsupport-alte-php-versionen/): 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.
- [Mettre à jour PHP sous Windows](https://phpsos.de/fr/blog/php-unter-windows-aktualisieren/): 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.
- [Signal d'alerte : le serveur web lance un shell](https://phpsos.de/fr/blog/webserver-startet-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.
- [Trouver les processus suspects sur les serveurs Linux](https://phpsos.de/fr/blog/verdaechtige-prozesse-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.
- [Repérer les tâches cron cachées comme porte dérobée](https://phpsos.de/fr/blog/cronjobs-als-hintertuer/): 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.
- [Trouver les fichiers récemment modifiés sur le serveur web](https://phpsos.de/fr/blog/geaenderte-dateien-finden/): 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.
- [Fichiers PHP dans le dossier de téléversement : bien interpréter les découvertes](https://phpsos.de/fr/blog/php-dateien-im-upload-ordner/): 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é.
- [Reconnaître le code PHP obfusqué](https://phpsos.de/fr/blog/verschleierter-php-code/): 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.
- [Vérifier les connexions sortantes d'un serveur](https://phpsos.de/fr/blog/ausgehende-verbindungen-pruefen/): 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.
- [Trouver des comptes administrateur inconnus dans le CMS et sur le serveur](https://phpsos.de/fr/blog/fremde-admin-konten-finden/): 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.
- [Trouver et supprimer les clés SSH inconnues](https://phpsos.de/fr/blog/ssh-schluessel-pruefen/): 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.
- [Mineur de cryptomonnaie sur le serveur web : signes et marche à suivre](https://phpsos.de/fr/blog/kryptominer-auf-dem-server/): 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.
- [Le serveur envoie du spam : trouver les causes](https://phpsos.de/fr/blog/server-verschickt-spam/): 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.
- [Spam SEO et pages étrangères dans l'index Google](https://phpsos.de/fr/blog/seo-spam-im-google-index/): 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.
- [Le site redirige vers des pages étrangères](https://phpsos.de/fr/blog/website-leitet-um/): 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.
- [Sécuriser les preuves avant de réinstaller le serveur](https://phpsos.de/fr/blog/beweise-sichern-vor-neuinstallation/): 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é.
- [Établir la chronologie d'un incident](https://phpsos.de/fr/blog/zeitleiste-eines-vorfalls/): 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.
- [Comparer les fichiers du noyau du CMS avec l'original](https://phpsos.de/fr/blog/cms-kerndateien-vergleichen/): 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.
- [Vérifier la base de données à la recherche de code injecté](https://phpsos.de/fr/blog/datenbank-auf-schadcode-pruefen/): 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.
- [Scanners de logiciels malveillants pour sites web : ce qu'ils trouvent et ce qu'ils manquent](https://phpsos.de/fr/blog/grenzen-von-malware-scannern/): 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.
- [Isoler les pools PHP-FPM site par site](https://phpsos.de/fr/blog/php-fpm-pools-isolieren/): 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.
- [Bien régler memory_limit](https://phpsos.de/fr/blog/memory-limit-richtig-setzen/): 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.
- [Limiter judicieusement post_max_size et upload_max_filesize](https://phpsos.de/fr/blog/post-max-size-upload-limits/): 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.
- [Désactiver session.upload_progress : correctement et durablement](https://phpsos.de/fr/blog/session-upload-progress-abschalten/): 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.
- [expose_php et en-têtes Server : masquer les indications de version](https://phpsos.de/fr/blog/expose-php-versionsangaben/): 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.
- [display_errors off : désactiver l'affichage des erreurs en production](https://phpsos.de/fr/blog/display-errors-produktion/): 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.
- [php_admin_value : verrouiller les paramètres contre l'écrasement](https://phpsos.de/fr/blog/php-admin-value-sperren/): 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.
- [Définir des limites de mémoire avec systemd et cgroups](https://phpsos.de/fr/blog/speichergrenzen-systemd-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.
- [Configurer Nginx pour PHP en toute sécurité](https://phpsos.de/fr/blog/nginx-fuer-php-absichern/): 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.
- [Configurer Apache pour PHP en toute sécurité](https://phpsos.de/fr/blog/apache-fuer-php-absichern/): 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.
- [Interdire l'exécution de PHP dans les dossiers d'upload](https://phpsos.de/fr/blog/php-in-uploads-verbieten/): 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.
- [Filtrer les requêtes d'upload en bordure : chances et risques](https://phpsos.de/fr/blog/upload-anfragen-am-rand-filtern/): 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.
- [Mettre en œuvre ModSecurity et l'OWASP Core Rule Set](https://phpsos.de/fr/blog/modsecurity-owasp-crs/): 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.
- [Configurer Fail2ban pour les serveurs web](https://phpsos.de/fr/blog/fail2ban-fuer-webserver/): 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.
- [Pare-feu pour serveurs web : n'ouvrir que les ports nécessaires](https://phpsos.de/fr/blog/firewall-fuer-webserver/): 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.
- [Mises à jour de sécurité automatiques sur les serveurs Linux](https://phpsos.de/fr/blog/automatische-sicherheitsupdates/): 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.
- [Moindre privilège : les droits de l'utilisateur du serveur web](https://phpsos.de/fr/blog/rechte-des-webserver-benutzers/): 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.
- [Protéger les espaces admin par IP, VPN ou protection complémentaire](https://phpsos.de/fr/blog/admin-bereiche-abschirmen/): 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.
- [Bien configurer TLS et HTTPS](https://phpsos.de/fr/blog/tls-https-richtig-konfigurieren/): 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.
- [Benchmarks CIS et modules du BSI pour serveurs web](https://phpsos.de/fr/blog/cis-benchmarks-bsi-bausteine/): 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.
- [Stocker les mots de passe en PHP : bien utiliser password_hash](https://phpsos.de/fr/blog/passwoerter-in-php-speichern/): 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.
- [Protection CSRF dans les applications PHP](https://phpsos.de/fr/blog/csrf-schutz-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.
- [Valider et filtrer les saisies en PHP avec filter_var](https://phpsos.de/fr/blog/eingaben-validieren-php/): 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.
- [Empêcher l'injection de commandes en PHP](https://phpsos.de/fr/blog/command-injection-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.
- [Empêcher le Server-Side Request Forgery (SSRF) en PHP](https://phpsos.de/fr/blog/ssrf-in-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.
- [Empêcher les XML External Entities (XXE) en PHP](https://phpsos.de/fr/blog/xxe-in-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.
- [Type juggling en PHP : les comparaisons lâches comme risque de sécurité](https://phpsos.de/fr/blog/type-juggling-php/): 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.
- [Nombres aléatoires et jetons sûrs en PHP avec random_bytes](https://phpsos.de/fr/blog/sichere-tokens-php/): 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.
- [Bien protéger les identifiants et les fichiers .env](https://phpsos.de/fr/blog/env-dateien-schuetzen/): 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.
- [Dossier .git public : une fuite de données sous-estimée](https://phpsos.de/fr/blog/git-ordner-oeffentlich/): 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.
- [Fichiers de sauvegarde dans le webroot : .zip, .sql et .bak](https://phpsos.de/fr/blog/backup-dateien-im-webroot/): 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.
- [Fichiers phpinfo() : pourquoi ils doivent disparaître](https://phpsos.de/fr/blog/phpinfo-dateien-entfernen/): 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.
- [Garder les dépendances à jour : Composer, npm et extensions](https://phpsos.de/fr/blog/abhaengigkeiten-aktuell-halten/): 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.
- [Revue de code de sécurité pour les projets PHP](https://phpsos.de/fr/blog/sicherheits-code-review-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.
- [Journaliser en sécurité : consigner les erreurs sans fuite de données](https://phpsos.de/fr/blog/sicher-loggen-php/): 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.
- [Sécuriser les API REST en PHP](https://phpsos.de/fr/blog/rest-api-php-absichern/): 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.
- [Contrats avec les prestataires informatiques : définir clairement les obligations de sécurité](https://phpsos.de/fr/blog/dienstleistervertrag-sicherheit/): 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.
- [Sous-traitance de données lorsque des prestataires accèdent aux serveurs](https://phpsos.de/fr/blog/auftragsverarbeitung-serverzugriff/): 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.
- [La gestion des vulnérabilités dans les PME](https://phpsos.de/fr/blog/schwachstellenmanagement-mittelstand/): 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.
- [Savoir ce qui tourne : l'inventaire de tous les sites et serveurs](https://phpsos.de/fr/blog/inventar-websites-server/): 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.
- [La gestion des correctifs comme processus plutôt que pompiers](https://phpsos.de/fr/blog/patch-management-prozess/): 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.
- [Contacts d'urgence : qui faut-il prévenir, et quand ?](https://phpsos.de/fr/blog/notfallkontakte-liste/): 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.
- [Ce que coûte un serveur piraté : les postes de coûts](https://phpsos.de/fr/blog/kostenposten-eines-hacks/): 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.
- [Informer les clients après un incident](https://phpsos.de/fr/blog/kunden-nach-vorfall-informieren/): 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.
- [La chaîne d'approvisionnement du web : agence, hébergeur, éditeur d'extensions](https://phpsos.de/fr/blog/lieferkette-agentur-hoster/): 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.
- [Sensibilisation à la sécurité pour admins et rédacteurs : l'équipe web](https://phpsos.de/fr/blog/sicherheitsbewusstsein-redaktion/): 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.
- [Exercice d'urgence sur table : simuler un incident de serveur web](https://phpsos.de/fr/blog/notfalluebung-am-tisch/): 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.
- [ISO 27001 et TISAX : ce que cela implique pour les serveurs web](https://phpsos.de/fr/blog/iso-27001-tisax-webserver/): 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.
- [VdS 10000 : la sécurité de l'information pour les petites et moyennes entreprises](https://phpsos.de/fr/blog/vds-10000-kmu/): 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.
- [Retour d'expérience : s'améliorer après l'incident](https://phpsos.de/fr/blog/lessons-learned-nach-vorfall/): 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.
- [Corriger, couper ou attendre ? Une aide à la décision face à la faille PHP](https://phpsos.de/fr/blog/patchen-abschalten-abwarten/): 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.
- [WAF ou mise à jour : pourquoi il vous faut les deux](https://phpsos.de/fr/blog/waf-oder-update/): 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.
- [Réinstaller ou nettoyer le serveur ? La décision après une compromission](https://phpsos.de/fr/blog/neu-aufsetzen-oder-bereinigen/): 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.
- [Corriger soi-même ou faire appel à un prestataire ? Une pesée honnête](https://phpsos.de/fr/blog/selbst-beheben-oder-dienstleister/): 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.
- [Choisir un prestataire de sécurité informatique : 12 questions avant la commande](https://phpsos.de/fr/blog/sicherheitsdienstleister-auswaehlen/): 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.
- [Hébergement managé ou serveur propre ? Le comparatif sécurité](https://phpsos.de/fr/blog/managed-oder-eigener-server/): 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.
- [Mise à niveau de PHP ou rétroportage ? La décision pour les anciens systèmes](https://phpsos.de/fr/blog/php-upgrade-oder-backport/): 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.
- [Changer de CMS après le piratage ? Quand cela aide, et quand non](https://phpsos.de/fr/blog/cms-wechsel-nach-hack/): 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.
- [Sites statiques : moins de PHP, moins de surface d'attaque](https://phpsos.de/fr/blog/statische-website-alternative/): 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.
- [Test d'intrusion, bug bounty ou scan de vulnérabilités ? Choisir la méthode adaptée](https://phpsos.de/fr/blog/pentest-bugbounty-scan/): 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.