Exploit-DB : L’archive public des exploits et preuves de concept

Vous souhaitez tester la sécurité d’un système ou comprendre le fonctionnement des failles informatiques, mais vous ne savez pas où avoir des informations sur celles-ci ? Exploit-DB est la plateforme incontournable à maîtriser : cette immense base de données centralise les vulnérabilités et les codes d’exploitation utilisés par les experts du monde entier.

Dans ce chapitre accessible aux débutants, vous allez apprendre à naviguer sur Exploit-DB, chercher des failles précises et exploiter ses ressources pour renforcer vos compétences en cybersécurité. Découvrez comment transformer cet outil puissant en un véritable allié au quotidien !

À quoi sert Exploit-DB ?

Avant de plonger dans les aspects techniques, prenons le temps de découvrir l’outil qui va devenir l’un de nos meilleurs alliés en cybersécurité : Exploit-DB.

Imaginé et maintenu par OffSec, l’équipe à l’origine de la célèbre distribution Kali Linux, Exploit-DB est une immense bibliothèque publique et gratuite qui recense des milliers de vulnérabilités informatiques. 

Pour faire simple, c’est un répertoire géant dans lequel des chercheurs en sécurité du monde entier partagent des démonstrations et des codes d’exploitation (appelés exploits). Lorsqu’une faille est découverte dans un logiciel, un système d’exploitation ou un site web, son fonctionnement y est documenté afin que la communauté puisse analyser le problème.

Concrètement, ce site vous permet d’effectuer plusieurs actions clés au quotidien :

• Rechercher des vulnérabilités spécifiques : Vous pouvez vérifier si une version précise d’un logiciel comporte des failles connues et consulter le code qui permet de les exploiter.
• Télécharger des preuves de concept (Proof of Concept ou PoC) : Le site met à votre disposition des scripts prêts à l’emploi ou des explications détaillées pour reproduire une attaque dans un cadre légal et contrôlé.
• Découvrir des techniques de recherche avancées (GHDB) : Grâce à la Google Hacking Database, vous apprenez à formuler des requêtes de recherche spécifiques pour repérer des fichiers sensibles ou des serveurs mal configurés exposés sur Internet.
• Consulter des articles de recherche : Le site héberge des analyses approfondies et des documents techniques pour comprendre le fonctionnement interne de certaines failles complexes.

Exploit-DB est donc une mine d’or pour comprendre comment les attaquants procèdent, ce qui vous permet de tester la solidité des systèmes et de mieux les protéger.

Rechercher une vulnérabilité sur Exploit-DB

Pour trouver une vulnérabilité spécifique sur Exploit-DB, la plateforme met à votre disposition un moteur de recherche puissant et très complet. Plutôt que de parcourir des milliers de lignes au hasard, ce formulaire vous permet de cibler précisément le logiciel ou le système qui vous intéresse grâce à plusieurs critères filtres.

Pour effectuer une recherche efficace, il convient de comprendre les champs principaux du formulaire :

• Title : Il s’agit du nom du logiciel ou de l’application visée, idéalement accompagné de sa version précise.C’est le champ le plus souvent utilisé.
• CVE : Si vous connaissez déjà l’identifiant universel de la vulnérabilité (sous la forme CVE-YYYY-XXXX),saisir cette référence vous mènera directement au bon exploit.
• Type : Ce filtre permet de catégoriser la nature de l’exploit. On y retrouve par exemple les failles de type webapps (applications web), remote (exécutables à distance sur un serveur), local (nécessitant déjà un accès à la machine) ou encore dos (déni de service).
• Platform : Il vous permet de préciser le système d’exploitation ou l’environnement concerné, comme Windows, Linux, PHP, Hardware ou Android.
• Author et Port : Vous pouvez également affiner votre recherche en renseignant le nom du chercheur qui a publié la preuve de concept ou le numéro du port réseau associé au service vulnérable.

Pour illustrer le déroulement d’une recherche, prenons un exemple concret. Imaginons que vous réalisiez un test d’intrusion sur un serveur web de démonstration et que vous découvriez qu’il héberge une application WordPress en version 7.0.2. Vous souhaitez vérifier s’il existe une faille permettant d’accéder à des fichiers du système par traversée de répertoire (Path Traversal).

Sur la page d’accueil d’Exploit-DB, vous cliquez sur le bouton de recherche pour ouvrir le formulaire avancé. Dans le champ Title, vous tapez simplement WordPress 7.0.2. Pour limiter les résultats aux applications web, vous sélectionnez la catégorie webapps dans le menu déroulant Type.

En validant la recherche, le tableau de résultats s’actualise instantanément. Une ligne correspond exactement à votre demande : elle affiche la date de publication, le titre WordPress 7.0.2 – Path Traversal, le type WebApps, la plateforme Multiple et l’auteur de la découverte.

En cliquant sur le titre de cet enregistrement, vous accédez à la fiche détaillée de l’exploit. Vous y trouverez le code source complet de la preuve de concept, des explications sur la manière de reproduire la faille, ainsi qu’un bouton dédié vous permettant de télécharger le script directement sur votre machine pour l’analyser dans un environnement de test sécurisé.

Télécharger des preuves de concept pour reproduire une attaque

Une fois que vous avez téléchargé le script d’exploitation (souvent écrit en Python, en Bash ou en Perl) depuis Exploit-DB, vous ne devez jamais l’exécuter aveuglément sur une cible. 

Dans le cadre d’un exercice de test d’intrusion éthique, la première étape indispensable consiste à analyser le code dans un environnement de laboratoire sécurisé et isolé. Ouvrez le fichier avec un simple éditeur de texte pour comprendre son fonctionnement interne, repérer les paramètres modifiables et vérifier qu’il ne contient pas de comportements inattendus ou malveillants pour votre propre poste de travail.

Ensuite, vous devez adapter ce script aux spécificités de votre environnement de test. La majorité des preuves de concept (PoC) partagées sur la plateforme nécessitent d’être configurées en renseignant l’adresse IP de la cible, le port d’écoute ou le chemin d’accès exact menant à l’application vulnérable. 

Lisez attentivement les commentaires laissés par l’auteur au début du fichier source : ils indiquent généralement les variables à modifier et les prérequis nécessaires, comme l’installation de bibliothèques logicielles spécifiques.

Avant de lancer l’exécution, préparez votre poste si l’exploit est conçu pour établir une connexion à distance ou un retour de commande. Vous devrez par exemple configurer un écouteur réseau pour intercepter les flux de données générés par le script (voir plus bas). Une fois vos paramètres validés, vous pouvez exécuter le script depuis votre terminal de commande et observer attentivement les retours textuels affichés à l’écran pour suivre le déroulement de l’opération.

Enfin, procédez à la vérification finale pour valider le succès de votre démarche. Si le script exploite une faille de divulgation d’information, vous devriez voir s’afficher les données sensibles ciblées ; s’il s’agit d’une élévation de privilèges ou d’une exécution de commande, vous devez confirmer l’obtention de l’accès escompté. Gardez à l’esprit que de nombreux scripts publiés sur Exploit-DB sont des archives historiques : il est fréquent qu’ils nécessitent de légères corrections de syntaxe ou d’adaptation pour fonctionner correctement sur des architectures ou des versions logicielles modernes.

Configurer un écouteur réseau

Configurer un écouteur réseau (souvent appelé listener en anglais) consiste à préparer votre propre machine (le poste attaquant) pour qu’elle « tienne un canal ouvert » et se tienne prête à recevoir des données ou une connexion venant de la machine cible.

Dans le cadre d’un test d’intrusion, lorsqu’un script d’exploitation réussit à perturber ou à s’exécuter sur le serveur distant, il a souvent besoin de vous renvoyer un accès (par exemple, un terminal de commande à distance, que l’on appelle un reverse shell) ou de vous envoyer des informations dérobées.

Pour que cela fonctionne, le mécanisme se déroule ainsi :

1. Vous lancez l’écouteur sur votre machine en lui indiquant un numéro de port précis (par exemple, le port 4444). Votre machine se met alors à l’écoute de tout ce qui arrive sur ce port.
2. Vous lancez le script d’exploitation en lui donnant votre propre adresse IP et ce même port 4444.
3. Lorsque la faille s’active sur la cible, le script ordonne au serveur distant de se connecter à votre adresse.
4. Votre écouteur réseau intercepte cette connexion entrante, ce qui vous permet de récupérer le contrôle ou les données renvoyées par la cible.

L’outil le plus simple et le plus utilisé pour cela est Netcat (souvent abrégé nc). Par exemple, une commande comme nc -lvnp 4444 dans votre terminal configure instantanément votre machine pour écouter sur le port 4444.

Faut il utiliser Metasploit ?

Pas nécessairement. Pour un simple écouteur réseau destiné à réceptionner une connexion basique avec un script trouvé sur Exploit-DB, utiliser Metasploit n’est pas obligatoire et peut même s’avérer superflu.

La majorité des scripts indépendants (souvent écrits en Python ou en Bash) partagés sur la plateforme fonctionnent parfaitement avec un outil minimaliste et direct comme Netcat. Une simple commande dans votre terminal suffit alors à ouvrir le port d’écoute attendu par le script.

Cependant, vous n’utiliserez Metasploit que dans un cas précis : si le script d’exploitation ou la charge utile (payload) que vous employez provient directement de l’écosystème Metasploit. Dans cette situation particulière, le framework dispose de son propre écouteur intégré (le module exploit/multi/handler),indispensable pour comprendre et intercepter le format de communication spécifique généré par ses propres outils.

Pour un script de démonstration classique issu d’Exploit-DB, un outil léger comme Netcat est généralement privilégié pour sa simplicité et sa rapidité de mise en œuvre.

Comment envoyer ce script sur la machine cible ?

Dans la grande majorité des cas avec les scripts d’Exploit-DB (notamment pour les failles distantes ou remote), vous n’avez pas besoin d’envoyer le script sur la machine cible.

Le script d’exploitation s’exécute entièrement depuis votre propre machine (votre poste de test). C’est lui qui va générer et envoyer des requêtes réseau piégées, des paquets spécifiques ou des commandes à travers le réseau pour frapper le service vulnérable qui tourne sur la machine distante.

Pour reprendre l’exemple d’un serveur web vulnérable, votre script (exécuté sur votre PC) va envoyer une requête HTTP modifiée. Le serveur distant traite cette requête anormale, ce qui provoque l’ouverture d’un accès ou la fuite d’informations, que vous récupérez ensuite directement sur votre poste via votre écouteur réseau.

Cependant, il existe un cas particulier où l’on doit effectivement transférer un fichier sur la cible : lorsqu’on a déjà obtenu un premier accès (un point d’ancrage initial) et que l’on souhaite exécuter un script d’élévation de privilèges ou un outil complémentaire. Dans ce scénario de post-exploitation, on utilise des commandes natives de la machine cible (comme curl ou wget sous Linux, ou des mécanismes de transfert via PowerShell sous Windows) pour aller télécharger le fichier depuis un serveur web que vous hébergez temporairement sur votre propre machine.

Vous saurez que la communication à distance a fonctionné si votre écouteur réseau intercepte une connexion entrante ou si le script affiche directement le résultat de l’exploitation dans votre propre terminal.

Exemple concret sur une faille pour la version 7.0.2 de Wordpress

Pour reproduire une attaque par traversée de répertoire (Path Traversal) dans le cadre d’un test d’intrusion éthique et strictement encadré (sur votre propre environnement de laboratoire), voici la méthodologie pas à pas à suivre.

Préparation de l’environnement de laboratoire : Avant de manipuler le moindre exploit, assurez-vous de disposer d’un environnement complètement isolé (une machine virtuelle locale ou un conteneur Docker) simulant le serveur vulnérable.

Vous devez pouvoir accéder à votre site WordPress de test via votre navigateur (par exemple sur une IP locale comme http://192.168.1.50) et que la page d’accueil s’affiche correctement.

Analyse de la structure de la requête d’origine

Ouvrez la fiche de l’exploit sur Exploit-DB et lisez attentivement la description de la vulnérabilité ainsi que l’exemple de l’URL ou du paramètre piégé. Une faille de type Path Traversal réside généralement dans un paramètre mal nettoyé (par exemple un paramètre de type file=, page= ou load=) qui permet de remonter dans l’arborescence des dossiers du système d’exploitation en utilisant la séquence de caractères ../.

Vous devez identifier clairement quel paramètre de l’application web gère l’inclusion ou le chargement de fichiers.

Formulation de la requête de test (PoC)

À l’aide d’un outil de test d’intrusion comme un navigateur web ou la commande curl depuis votre poste attaquant, envoyez une requête ciblant un fichier sensible standard du système (par exemple /etc/passwd sur un serveur Linux).

Exemple de structure de requête ciblée :

http://192.168.1.50/index.php?page=../../../../etc/passwd

Le serveur ne renvoie pas une erreur 404 classique, mais commence à traiter la requête.

Examinez la réponse HTTP renvoyée par le serveur distant (via l’onglet de réponse de votre outil ou directement dans le terminal).

Si l’attaque a réussi, la page web ou le corps de la réponse affiche le contenu brut du fichier système ciblé (par exemple, la liste des utilisateurs du système Linux avec les lignes root:x:0:0:...), confirmant que le filtre de l’application a failli et que vous pouvez lire des fichiers hors de la racine du site web.

Lancer le script Python téléchargé sur Exploit-DB

Pour utiliser le script d’Exploit-DB, le principe repose sur l’exécution d’une commande en ligne avec Python 3, en pointant vers l’adresse de la machine vulnérable.

Avant de lancer le script, assurez-vous que votre environnement de test réunit les prérequis décrits dans l’en-tête du code, notamment une instance de WordPress accessible, une page publiée et les composants du serveur configurés pour l’exercice d’intrusion.

Pour lancer le script de manière basique depuis votre terminal, la syntaxe générale est la suivante :

python3 cve-2026-87902.py --url http://127.0.0.1:8091

Si le script ne parvient pas à détecter automatiquement une page publiée sur le site de test, vous pouvez spécifier explicitement l’identifiant de la page à l’aide de l’argument --page-id :

python3 cve-2026-87902.py --url http://127.0.0.1:8091 --page-id 12

Deux grandes étapes automatisées par le script :

La première étape consiste à envoyer une requête HTTP POST manipulée. Le script exploite l’absence de validation stricte sur le paramètre de modèle (pagename) combinée à une technique de traversée de répertoire. Il utilise un composant local présent sur le serveur (dans cet exemple, un outil de gestion de paquets PHP nommé PEAR) pour créer et écrire un fichier contenant le code PHP de votre choix (par exemple, la lecture d’un fichier de test ou d’un indicateur de réussite).

La seconde étape consiste à envoyer une nouvelle requête qui force le moteur de WordPress à inclure le fichier généré lors de la première étape. Lorsque le serveur exécute ce fichier inclus, le code s’exécute avec les privilèges du serveur web, ce qui permet au script de récupérer la réponse attendue (le marqueur de succès ou le contenu du fichier cible) et de valider que la démonstration a fonctionné.

En observant les retours du script dans le terminal (les codes de statut HTTP et la présence du marqueur de succès), vous pourrez ainsi visualiser concrètement comment une simple faille de routage de template peut être transformée en exécution de code.

Comment connaître la version d’un site Wordpress

Pour identifier la version d’un site WordPress, plusieurs outils et méthodes d’analyse (du plus automatisé au plus manuel) sont couramment utilisés :

WPScan

C’est l’outil de référence dédié à la sécurité et à la reconnaissance de l’écosystème WordPress.

• Il analyse la cible pour détecter la version exacte du cœur WordPress, les thèmes et les extensions installés, ainsi que leurs vulnérabilités connues.
• Disponible en ligne de commande (préinstallé sous Kali Linux) ou en version conteneurisée via Docker.

👉 Découvrez notre tutoriel complet sur WPScan.

Les outils de numérisation web généraux

• Nmap : Grâce à ses scripts NSE dédiés (comme http-wordpress-enum), Nmap peut identifier la version lors d’une phase de balayage réseau ou de service.
• BuiltWith / Wappalyzer : Ces extensions pour navigateur ou services web identifient les technologies utilisées par un site, y compris le CMS et souvent sa version globale si elle est exposée dans les entêtes HTTP ou les balises HTML.

Inspection manuelle du code source

Sans aucun outil tiers, il est très souvent possible d’identifier la version directement depuis son navigateur web :

• La balise Meta Generator : En affichant le code source de la page d’accueil (Ctrl + U), la balise <meta name="generator" content="WordPress X.Y.Z" /> indique directement la version (si elle n’a pas été masquée par l’administrateur).
• Les fichiers statiques (CSS/JS) : Les liens vers les feuilles de style ou les scripts inclus dans la page contiennent souvent un paramètre de version à la fin de l’URL (ex: style.css?ver=X.Y.Z).
• Le fichier readme.html : Historiquement situé à la racine du site http://exemple.com/readme.html, ce fichier d’information indique la version installée si l’administrateur ne l’a pas supprimé lors du déploiement.

Utiliser la Google Hacking Database (GHDB) sur Exploit-DB

En plus de répertorier des codes d’exploitation et des preuves de concept, la plateforme Exploit-DB intègre un autre outil redoutable pour la phase initiale d’un audit : la Google Hacking Database, plus communément appelée GHDB. Souvent désignée sous le terme de « Google Dorks », cette immense collection de requêtes de recherche sophistiquées permet de dénicher des informations sensibles, des erreurs de configuration ou des fichiers oubliés directement exposés sur le web par les moteurs de recherche.

Pour bien comprendre comment cela fonctionne, il faut s’imaginer un moteur de recherche classique, mais doté d’opérateurs de ciblage très précis. Au lieu de taper de simples mots-clés, vous utilisez des instructions spécifiques qui ordonnent au moteur de chercher des structures de pages particulières.

Par exemple, l’opérateur site: permet de restreindre la recherche à un domaine ou un site web précis, l’opérateur intitle: cible des mots situés dans le titre de la page, et inurl: repère des termes précis intégrés directement dans l’adresse URL.

👉 Tout savoir sur le Google dorking.

Sur le site d’Exploit-DB, la section dédiée à la GHDB est classée par catégories logiques pour vous aider à cibler vos recherches. 

Vous y trouverez des rubriques classant les risques, comme les répertoires sensibles exposés au public, les fichiers de configuration contenant parfois des données oubliées, ou encore les pages d’erreur qui révèlent par inadvertance la version exacte de logiciels vulnérables. 

Chaque entrée de la base de données vous fournit la requête textuelle exacte à copier, accompagnée d’une description détaillée expliquant le contexte de la faille d’exposition.

Prenons un exemple concret dans le cadre d’un exercice de reconnaissance pour un test d’intrusion autorisé. Imaginons que vous souhaitiez vérifier si votre infrastructure de test a par mégarde laissé public un dossier contenant des journaux d’activité ou des fichiers de configuration de sauvegarde. En consultant la GHDB sur Exploit-DB, vous repérez une requête préconisée qui cible les extensions de fichiers spécifiques associées à ces sauvegardes. En adaptant cette requête avec le nom de domaine de votre propre laboratoire dans votre moteur de recherche, vous observez instantanément si des liens sensibles remontent à la surface.

Cette démarche vous démontre toute l’importance de la phase de reconnaissance : elle met en lumière le fait que la sécurité d’un système ne dépend pas seulement de la robustesse de son code, mais aussi de la discrétion des données et des fichiers que l’on laisse involontairement accessibles au grand jour.

Exemple concret

Cette requête issue de la base de données GHDB d’Exploit-DB combine deux éléments précis pour repérer une faille de configuration ou une fuite de données critique directement indexée par les moteurs de recherche.

Le premier élément, l’opérateur ext:nix, indique au moteur de recherche de cibler spécifiquement les fichiers possédant l’extension .nix. 

Ces fichiers sont généralement associés à des scripts de configuration, à des environnements système (notamment liés au gestionnaire de paquets NixOS) ou parfois à des sauvegardes textuelles oubliées sur un serveur web.

Le second élément, la chaîne de caractères exacte "BEGIN OPENSSH PRIVATE KEY", correspond à l’en-tête normalisé qui marque le début d’une clé privée SSH cryptographique. Cette clé sert habituellement à s’authentifier de manière sécurisée et à distance sur des serveurs, agissant comme un passeport numérique absolu.

En associant ces deux critères, cette requête permet de trouver des cas où des administrateurs ou des développeurs ont malencontreusement laissé traîner ou publié publiquement un fichier de configuration contenant une clé d’accès secrète.

L’intérêt de cet exemple est de réaliser qu’une simple erreur de manipulation ou un oubli de configuration peut exposer des accès administrateurs complets à l’ensemble du web, sans même avoir besoin de lancer un exploit technique complexe. Cela démontre toute l’importance de la phase de veille préventive et du nettoyage rigoureux des environnements avant leur mise en production.

Exploit Database Security Papers

La section « Security Papers » d’Exploit-DB constitue une ressource inestimable qui va bien au-delà des simples scripts d’exploitation ou codes de preuve de concept. Alors que les répertoires d’exploits fournissent l’outil technique brut, cette section regroupe des articles de recherche, des livres blancs et des analyses techniques approfondies rédigés par des experts en cybersécurité pour décortiquer en détail le « pourquoi » et le « comment » des failles.

L’intérêt pédagogique de cet espace est fondamental. Plutôt que de se limiter à l’utilisation d’un script prêt à l’emploi, ces documents permettent de comprendre la logique architecturale ou conceptuelle qui rend une vulnérabilité possible. 

Ils abordent des thématiques variées allant des techniques avancées de rétro-ingénierie (reverse engineering) à l’analyse de l’évolution des menaces, en passant par des méthodologies d’audit rigoureuses et des stratégies de défense de pointe.

En intégrant la lecture de ces articles de recherche dans votre cursus, vous apprendrez à développer une véritable culture de la veille technologique et de la rigueur scientifique. C’est le pont idéal entre la théorie fondamentale et la pratique opérationnelle, garantissant qu’un testeur d’intrusion ne se comporte pas comme un simple exécutant d’outils, mais comme un analyste capable de comprendre, d’expliquer et de réparer durablement les systèmes qu’il étudie.

Exploit Database Shellcodes

La section « Shellcodes » d’Exploit-DB aborde un aspect encore plus technique et bas niveau de la cybersécurité : le code machine pur. Un shellcode est un petit bloc de code, généralement écrit en assembleur, dont l’objectif est d’exécuter une action précise sur une machine cible, comme ouvrir une ligne de commande ou un terminal à distance, ce qui lui vaut son nom historique.

Contrairement aux scripts de haut niveau que nous avons vus avec les failles web, les shellcodes interagissent directement avec le processeur et la mémoire du système. Sur la plateforme, cette section répertorie des fragments de code optimisés pour de nombreuses architectures matérielles, qu’il s’agisse de processeurs x86 traditionnels, d’environnements 64 bits ou de puces ARM que l’on retrouve dans les serveurs modernes et les objets connectés.

L’intérêt de cette section est capital dès que l’on aborde des failles de corruption de mémoire, comme les dépassements de tampon (buffer overflows). Plutôt que de manipuler des outils automatisés de manière superficielle, analyser ces codes permet de comprendre comment un attaquant parvient à injecter et à faire exécuter des instructions directement au cœur du système d’exploitation. C’est une ressource précieuse pour comprendre le fonctionnement intime des machines et leur faire réaliser pourquoi les mécanismes modernes de protection de la mémoire sont devenus indispensables.

---

Exploit-DB dépasse largement le simple rôle de répertoire de codes d’exploitation : c’est une véritable boîte à outils pédagogique pour former les futurs experts en cybersécurité.

Qu’il s’agisse de pratiquer la reconnaissance avec la GHDB, d’analyser des vulnérabilités complexes en laboratoire ou de plonger dans la recherche et les codes de bas niveau, chaque ressource enseigne la rigueur. Retenez que l’essence d’un test d’intrusion ne réside jamais dans l’exécution aveugle d’outils, mais dans la compréhension des mécanismes pour mieux concevoir la défense et la remédiation de demain.