# Scanners de logiciels malveillants pour sites web : ce qu'ils trouvent et ce qu'ils manquent

> Scanners de malwares pour sites web : ce que voient scanners externes, de plugin et de serveur, leurs limites et pourquoi « rien trouvé » ne suffit pas.

Source : https://phpsos.de/fr/blog/grenzen-von-malware-scannern/  
É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

**En bref :** un scanner de logiciels malveillants pour sites web trouve surtout des motifs connus dans les fichiers ou dans la page livrée. Le code nouveau et obscurci, les portes dérobées dans la base de données, les comptes étrangers, les tâches cron et les clés SSH restent souvent invisibles. « Rien trouvé » ne signifie donc pas « sain ». Une vérification ne devient fiable que par la combinaison d'un scanner, d'une comparaison avec l'original, d'un examen de la base de données et du système, et d'une surveillance du comportement.

## Le calme trompeur après la coche verte

Après PHP2Shell, de nombreux exploitants ont fait ce qui s'impose : lancer un scanner. Un service en ligne examine la page d'accueil, un plugin de sécurité parcourt le répertoire web, le résultat est vert. La question de savoir si quelque chose s'est produit avant le correctif semble ainsi tranchée.

Le problème tient au principe. La plupart des scanners comparent des contenus avec des motifs de logiciels malveillants connus. Or pour les failles CVE-2026-109618 et CVE-2026-109619, il n'existe pas d'indicateurs de compromission publiés et confirmés ; la détection repose sur l'analyse comportementale. Un scanner ne peut pas rechercher des traces que personne ne connaît. Au mieux, il trouve des logiciels malveillants généraux rechargés après une intrusion, à condition qu'ils suivent des motifs connus.

Cela ne rend pas les scanners inutiles. Cela signifie seulement que leur résultat doit être correctement interprété. Les signes qui comptent au-delà des scanners sont décrits dans [Suis-je déjà compromis ?](https://phpsos.de/fr/php2shell/bin-ich-gehackt-anzeichen/).

## Scanners de logiciels malveillants pour sites web : trois conceptions

| Conception | Ce qu'elle voit | Ce qu'elle ne voit pas |
|---|---|---|
| Scanner externe (service en ligne) | pages livrées, scripts intégrés, redirections, listes de blocage | fichiers, base de données, comptes, tout ce qui n'est livré que sous conditions |
| Scanner dans le CMS (plugin ou extension) | fichiers du répertoire web, en partie le contenu de la base de données, comparaison avec les fichiers du noyau | niveau système, tâches cron, SSH ; tourne dans le système éventuellement compromis |
| Scanner sur le serveur (basé sur des signatures) | tous les fichiers lisibles, y compris hors du répertoire web | motifs inconnus et obscurcis, base de données, comptes, comportement |

Les scanners externes sont utiles pour détecter les conséquences visibles, comme des redirections ou des inscriptions sur des listes de blocage. Mais de nombreux piratages ne diffusent leurs contenus de spam ou de redirection qu'à certains visiteurs, par exemple les moteurs de recherche ou les appareils mobiles. Le scanner voit alors une page saine.

Les scanners dans le CMS ont plus de visibilité, mais un problème de principe : ils s'exécutent dans le même système qu'ils doivent examiner. Un code disposant de droits suffisants peut influencer leurs résultats, masquer des fichiers ou désactiver le scanner. Les scanners de serveur fonctionnent en dehors de l'application, mais restent tributaires de motifs.

## Ce que les scanners manquent par principe

Indépendamment de la conception, certains domaines sont à peine couverts par un scanner de fichiers ou de pages :

1. **Code nouveau ou obscurci de façon individuelle :** toute variante qui diffère des motifs connus passe à travers.
2. **La base de données :** scripts dans les contenus, paramètres modifiés, triggers et comptes étrangers. Plus de détails dans [Vérifier la base de données à la recherche de code injecté](https://phpsos.de/fr/blog/datenbank-auf-schadcode-pruefen/).
3. **Les accès :** comptes administrateur supplémentaires, clés SSH, utilisateurs de la base de données, comptes dans le panneau d'hébergement.
4. **Services système et tâches cron :** mécanismes qui rechargent régulièrement du code malveillant.
5. **Modifications discrètes de fichiers légitimes :** une seule ligne supplémentaire dans un fichier du noyau, d'apparence inoffensive.
6. **Données exfiltrées :** aucun scanner ne montre si des identifiants ou des données clients ont été copiés.

## Ce qui apporte la certitude

Plus de sécurité vient de la combinaison de types de vérifications qui fonctionnent différemment :

- **Comparaison avec l'original :** elle trouve toute modification de fichiers connus, indépendamment des motifs. La démarche est décrite dans [Comparer les fichiers du noyau du CMS avec l'original](https://phpsos.de/fr/blog/cms-kerndateien-vergleichen/).
- **Recherche ciblée d'anomalies :** fichiers PHP dans les dossiers d'upload, fichiers récemment modifiés, code obscurci, fichiers exécutables dans les dossiers temporaires.
- **Vérification des comptes et des services système :** comparer utilisateurs, clés, tâches cron et services avec la situation attendue connue.
- **Analyse des journaux :** requêtes vers des fichiers inconnus, multiplication d'erreurs, connexions inhabituelles.
- **Surveillance du comportement :** processus du serveur web qui lancent un shell, connexions sortantes inattendues, nouveaux fichiers dans des dossiers sensibles.

La dernière catégorie est la plus importante lorsqu'il n'existe aucune trace connue. Elle ne demande pas à quoi ressemble le code malveillant, mais ce qu'il fait. Un processus de serveur web qui lance soudain un shell se remarque, quelle que soit la manière dont le code déclencheur est obscurci.

> **Astuce:**
> Faites tourner un scanner de serveur depuis un système sain, sur une copie en lecture seule, plutôt que sur le serveur suspect lui-même. Le code injecté ne peut ainsi pas influencer le résultat.

## Comment utiliser les scanners à bon escient

Les scanners ont leur place, comme un outil parmi d'autres. Un scanner externe convient comme contrôle régulier des conséquences visibles, par exemple chaque semaine. Un scanner dans le CMS signale au quotidien les logiciels malveillants connus et les fichiers du noyau modifiés. Un scanner de serveur complète la recherche de motifs connus dans tout le système de fichiers.

Ce qui compte, c'est la manière de traiter le résultat. Une trouvaille est une vérification clairement à mener et justifie une enquête complète, car il est rare qu'un seul fichier soit concerné. Un résultat vide, en revanche, n'est qu'une indication sur les motifs examinés. Consignez dans votre documentation quel scanner a tourné, quand et avec quel état, et n'écrivez pas « système sain », mais « aucun motif connu trouvé ».

Pour la direction, cela signifie : une coche verte ne remplace pas la vérification par quelqu'un qui examine ensemble fichiers, base de données, comptes et comportement. Après un incident avec exécution de code possible, comme on peut l'envisager avec PHP2Shell, cette vérification devrait avoir lieu.

Si un scanner signale en revanche une trouvaille, il faut agir vite, mais avec méthode. Ne supprimez pas immédiatement le fichier signalé via la fonction du scanner. Sauvegardez d'abord le fichier et les journaux, afin de pouvoir déterminer comment il est arrivé sur le serveur. Le déroulement d'un nettoyage complet est décrit dans le service [Faire supprimer logiciels malveillants et webshells](https://phpsos.de/fr/leistungen/malware-entfernung/).

## Comment PHP SOS aide-t-il concrètement ?

- Nous combinons les scanners avec une comparaison à l'original, une recherche ciblée et l'analyse des comptes, services et journaux.
- Nous examinons les systèmes suspects via des copies sécurisées, afin que les résultats ne soient pas influencés par le système compromis.
- Nous qualifions honnêtement chaque résultat de prouvé, probable ou inconnu.
- Avec la [supervision de sécurité pour serveurs web](https://phpsos.de/fr/leistungen/security-monitoring/), nous surveillons durablement le comportement de vos serveurs, et pas seulement les motifs connus.


## Questions fréquentes

**Mon site est-il sain si le scanner de logiciels malveillants ne trouve rien ?**  
Pas nécessairement. Les scanners trouvent surtout des motifs connus. Le code nouveau ou bien obscurci, les portes dérobées dans la base de données, les comptes étrangers, les tâches cron et les clés SSH passent souvent inaperçus. Un résultat vide est un élément, pas un acquittement.

**Quelle est la différence entre un scanner externe et un scanner de plugin ?**  
Un scanner externe consulte le site de l'extérieur et ne voit que ce qui est livré. Un scanner de plugin s'exécute à l'intérieur du CMS et peut lire des fichiers, mais il tourne dans le même système, éventuellement compromis. Les deux ont leurs propres angles morts.

**Existe-t-il des signatures de scanner pour PHP2Shell ?**  
Il n'existe pas d'indicateurs de compromission publiés et confirmés pour PHP2Shell. Les scanners ne peuvent donc pas rechercher de façon ciblée des traces PHP2Shell avérées. La détection repose sur l'analyse comportementale et sur la recherche de signes généraux de compromission.

**Quel est le meilleur scanner ?**  
La question est trompeuse. Plus important qu'un produit donné, c'est la combinaison de différents types de vérifications : comparaison avec l'original, recherche dans les fichiers et la base de données, vérification des comptes et des services système, ainsi que surveillance du comportement.

## Sources

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [BSI (office fédéral allemand de la sécurité des technologies de l'information) : conseils sur les incidents de sécurité informatique](https://www.bsi.bund.de/)
- [php.net : avis de sécurité](https://www.php.net/)