Nuclei : scanner de vulnérabilités rapide

Mise à jour : 13/12/2025

nucei cli

En 2023, un chercheur en sécurité découvre une vulnérabilité critique dans un pare-feu populaire. En quelques heures, un template Nuclei est publié par la communauté. Le lendemain, des milliers de professionnels ont déjà scanné leurs sites pour vérifier s’ils sont exposés. Cette réactivité illustre la puissance de l’écosystème Nuclei : des 11000+ templates maintenus par la communauté, prêts à détecter les dernières vulnérabilités.

Dans ce guide, je présente :

Ce qu’est Nuclei et pourquoi il se démarque
Comment l’installer sur différents systèmes
Les commandes essentielles pour débuter
L’utilisation des templates et leur personnalisation
L’intégration dans un pipeline CI/CD

Vocabulaire essentiel

Avant de plonger dans Nuclei, clarifions quelques termes qui reviendront souvent dans ce guide.

Le DAST (Dynamic Application Security Testing) désigne les tests de sécurité effectués sur une application en cours d’exécution. Contrairement au SAST qui analyse le code source, le DAST teste l’application comme le ferait un attaquant — c’est un test en “boîte noire”.

Un template est le cœur de Nuclei : c’est un fichier YAML qui décrit comment détecter une vulnérabilité spécifique. Chaque template contient les requêtes à envoyer et les critères pour identifier un problème.

Les CVE (Common Vulnerabilities and Exposures) sont des identifiants uniques attribués aux vulnérabilités connues. Par exemple, CVE-2021-44228 désigne la fameuse faille Log4Shell. Nuclei dispose de templates pour des milliers de CVE.

Un matcher est la règle qui vérifie si une réponse correspond à une vulnérabilité. Il peut chercher un mot spécifique, un code HTTP, ou un pattern regex dans la réponse du serveur.

La sévérité indique la gravité d’une vulnérabilité. Nuclei utilise cinq niveaux : info (informatif), low (faible), medium (modéré), high (élevé) et critical (critique). Cette classification aide à prioriser les corrections.

Enfin, les tags sont des étiquettes qui catégorisent les templates. On trouve par exemple cve pour les vulnérabilités référencées, exposure pour les fichiers exposés, ou wordpress pour les failles spécifiques à ce CMS.

Qu’est-ce que Nuclei ?

Nuclei est un scanner de vulnérabilités rapide et extensible développé par ProjectDiscovery ↗. Il teste des sites web, applications web, API REST et services réseau exposés (HTTP, DNS, TCP). Contrairement aux scanners traditionnels qui embarquent leurs propres signatures, Nuclei repose sur des templates YAML décrivant comment détecter une vulnérabilité.

Concrètement, quand on lance Nuclei sur une cible, l’outil commence par charger les templates depuis le dossier ~/nuclei-templates/. Ensuite, pour chaque template, il envoie une ou plusieurs requêtes à la cible. Il analyse alors la réponse pour voir si elle correspond aux critères définis dans le template. Si c’est le cas, il signale une potentielle vulnérabilité avec tous les détails utiles : sévérité, URL concernée, et pattern détecté.

Pourquoi Nuclei ?

Ce qui distingue Nuclei des scanners traditionnels, c’est d’abord sa vitesse. Écrit en Go avec une architecture hautement concurrente, il peut tester des milliers de cibles en parallèle. Là où un scanner classique prendrait des heures, Nuclei termine en minutes.

L’extensibilité est son second atout majeur. Les templates YAML sont simples à lire et à écrire. Pas besoin de maîtriser un SDK complexe pour ajouter une détection personnalisée — quelques lignes de YAML suffisent.

La communauté fait le reste. Avec plus de 11000 templates maintenus par des contributeurs du monde entier, Nuclei couvre un spectre impressionnant de vulnérabilités. Quand une nouvelle CVE tombe, un template apparaît souvent dans les heures qui suivent.

Côté intégration, Nuclei est pensé CLI-first. Il s’intègre naturellement dans les pipelines CI/CD, là où beaucoup de scanners commerciaux nécessitent une interface graphique. Et cerise sur le gâteau : il est open source et gratuit.

Ce que Nuclei détecte

Nuclei couvre un large spectre de problèmes de sécurité. Les CVE connues constituent une part importante : Log4Shell, ProxyShell, les RCE Confluence… tous les grands classiques sont couverts.

Au-delà des CVE, Nuclei excelle dans la détection de misconfigurations : headers de sécurité manquants, mode debug activé en production, CORS trop permissifs. Ces problèmes ne sont pas des vulnérabilités au sens strict, mais ils facilitent les attaques.

Les templates d’exposition recherchent les fichiers et pages qui ne devraient pas être accessibles : répertoires .git exposés, backups oubliés, panels d’administration sans authentification.

Nuclei peut aussi identifier les technologies utilisées par une cible : version de WordPress, type de serveur web, frameworks JavaScript. Ces informations aident à cibler les tests suivants.

Enfin, certains templates détectent des secrets dans les réponses HTTP : clés API, tokens d’authentification, credentials exposés par erreur.

Installation

Nuclei s’installe facilement sur tous les systèmes. Le choix de la méthode dépend de l’environnement et du niveau de confort avec les outils.

Pour les débutants sans Go installé, Homebrew (sur macOS ou Linux) ou le binaire précompilé sont les options les plus simples. Les développeurs habitués à Go préféreront go install pour des mises à jour faciles.

Avec Go (recommandé)

# Nécessite Go 1.21+
# Remplacer v3.6.0 par la dernière version stable
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@v3.6.0

# Vérifier l'installation
nuclei -version

Avec Homebrew (macOS/Linux)

brew install nuclei

Binaire précompilé

Télécharger le binaire depuis les releases GitHub ↗ :

# Linux AMD64 (remplacer v3.6.0 par la version souhaitée)
wget https://github.com/projectdiscovery/nuclei/releases/download/v3.6.0/nuclei_3.6.0_linux_amd64.zip
unzip nuclei_3.6.0_linux_amd64.zip
sudo mv nuclei /usr/local/bin/

# Vérifier
nuclei -version

Installation et mise à jour des templates

Au premier lancement, Nuclei télécharge automatiquement les templates communautaires dans ~/nuclei-templates/. Pour les mettre à jour :

nuclei -update-templates

Premiers scans

Pour pratiquer sans risque légal, on va utiliser OWASP Juice Shop : une application web intentionnellement vulnérable, conçue pour l’apprentissage de la sécurité. Elle contient des dizaines de failles que Nuclei peut détecter.

Déployer un environnement de test

# Lancer Juice Shop avec Docker (version épinglée)
docker run --rm -d -p 3000:3000 --name juice-shop bkimminich/juice-shop:v17.1.1

# Vérifier que l'application est accessible
curl -s http://localhost:3000 | head -5

L’application est maintenant disponible sur http://localhost:3000. On peut aussi y accéder via un navigateur pour explorer l’interface. Ce sera notre cible pour tous les exemples qui suivent.

Comprendre le déroulement d’un scan

Quand on lance Nuclei, l’outil commence par charger tous les templates depuis le dossier ~/nuclei-templates/. Ensuite, pour chaque template, il envoie une ou plusieurs requêtes à la cible. Les réponses sont alors comparées aux matchers définis dans chaque template. Enfin, les correspondances sont affichées dans le terminal avec tous les détails utiles.

Le premier scan peut prendre du temps — parfois 10 à 30 minutes — car Nuclei teste des milliers de templates. Pour des tests plus rapides, on peut filtrer par sévérité ou par tags comme expliqué plus loin.

Scanner notre cible de test

# Scan rapide sur Juice Shop (exposures et misconfigs seulement)
nuclei -u http://localhost:3000 -tags exposure,misconfig

# Scan complet avec tous les templates (plus long)
nuclei -u http://localhost:3000

# Scan avec sortie détaillée (voir ce qui se passe)
nuclei -u http://localhost:3000 -v

Sur Juice Shop, Nuclei détecte plusieurs problèmes en quelques secondes. Voici un exemple de sortie réelle :

[swagger-api] [http] [info] http://localhost:3000/api-docs/swagger.json
[missing-sri] [http] [info] http://localhost:3000 ["//cdnjs.cloudflare.com/..."]
[prometheus-metrics] [http] [medium] http://localhost:3000/metrics
[http-missing-security-headers:strict-transport-security] [http] [info] http://localhost:3000
[http-missing-security-headers:content-security-policy] [http] [info] http://localhost:3000
[http-missing-security-headers:permissions-policy] [http] [info] http://localhost:3000

Comprendre la sortie

Chaque ligne de résultat suit un format standard. Prenons l’exemple de la ligne [prometheus-metrics] [http] [medium] http://localhost:3000/metrics :

Le premier élément [prometheus-metrics] est l’identifiant du template qui a déclenché l’alerte. Ici, Nuclei a détecté que l’endpoint /metrics de Prometheus est exposé publiquement — ce qui peut révéler des informations sensibles sur l’infrastructure.

Le deuxième élément [http] indique le protocole utilisé pour le test. Nuclei supporte HTTP, DNS, TCP, et d’autres protocoles.

Le troisième élément [medium] est la sévérité. Sur les 12 résultats de notre scan, un seul est de sévérité moyenne (les métriques Prometheus exposées), les autres sont informatifs (headers manquants).

Enfin, l’URL montre exactement où le problème a été détecté. Certains résultats incluent des détails supplémentaires entre crochets, comme les ressources externes sans SRI (Subresource Integrity).

Gérer les faux positifs

Nuclei est conçu pour minimiser les faux positifs, mais ils existent. La première règle est de vérifier manuellement chaque finding avant de le reporter ou de paniquer. Un résultat de scan n’est pas une preuve d’exploitation.

Pour réduire le bruit, on peut exclure les templates bruyants via le fichier de configuration. Après quelques scans, on identifie vite les templates qui génèrent des résultats non pertinents dans son contexte.

L’option -ms (matcher-status) affiche les échecs de matching, ce qui aide à comprendre pourquoi un template s’est déclenché. C’est utile pour distinguer un vrai positif d’un faux positif.

Enfin, la communauté Nuclei accueille volontiers les contributions. Si on identifie un template qui génère trop de faux positifs, on peut proposer une correction sur le dépôt GitHub.

Nettoyer l’environnement

Une fois les tests terminés, arrêter le conteneur :

docker stop juice-shop

Filtrer par sévérité

Les sévérités permettent de prioriser les résultats :

Sévérité	Signification	Action recommandée
critical	Exploitation immédiate possible (RCE, auth bypass)	Corriger immédiatement
high	Risque élevé, exploitation probable	Corriger rapidement
medium	Risque modéré, exploitation sous conditions	Planifier la correction
low	Risque faible, impact limité	À évaluer selon contexte
info	Information, pas de vulnérabilité	Pour investigation

# Uniquement les vulnérabilités critiques et hautes
nuclei -u http://localhost:3000/metrics -severity critical,high

# Exclure les informatives (recommandé pour un premier scan)
nuclei -u http://localhost:3000/metrics -es info

Filtrer par tags

Les templates sont catégorisés par tags, ce qui permet de cibler précisément le type de vulnérabilités à rechercher.

Le tag cve regroupe les templates qui détectent des vulnérabilités référencées : Log4Shell, ProxyShell, et des milliers d’autres. Le tag exposure cible les fichiers et pages qui ne devraient pas être accessibles : backups, fichiers de configuration, répertoires .git exposés.

Pour les erreurs de configuration, le tag misconfig détecte les problèmes comme les headers de sécurité manquants, les CORS trop permissifs ou le mode debug activé en production. Le tag tech permet d’identifier les technologies utilisées par la cible : CMS, frameworks, serveurs web.

On trouve aussi des tags spécifiques à certaines technologies. Par exemple, wordpress regroupe toutes les vulnérabilités connues de ce CMS. Le tag panel recherche les interfaces d’administration exposées sans protection.

# Scanner uniquement les CVE
nuclei -u http://localhost:3000 -tags cve

# Scanner les expositions et misconfigurations
nuclei -u http://localhost:3000 -tags exposure,misconfig

# Scanner une technologie spécifique
nuclei -u http://localhost:3000 -tags wordpress

Combiner les tags permet d’affiner la recherche selon le contexte. Sur un site WordPress, on utilisera -tags wordpress,cve. Pour un audit rapide, -tags exposure,misconfig donne de bons résultats en peu de temps.

Exporter les résultats

Il est possible d’exporter les résultats dans plusieurs formats pour analyse ou intégration dans des outils tiers.

# Format JSON (recommandé pour l'automatisation)
nuclei -u http://localhost:3000 -jsonl -o results.jsonl

# Format SARIF (intégration GitHub/GitLab)
nuclei -u http://localhost:3000 -sarif-export results.sarif

# Format Markdown
nuclei -u http://localhost:3000 -markdown-export ./reports/

Le format JSONL (JSON Lines) est idéal pour le traitement automatisé et l’ingestion dans des outils comme Elasticsearch ou Splunk. Le format SARIF s’intègre nativement avec GitHub Security et GitLab.

Comprendre les templates

Les templates sont le cœur de Nuclei. Chaque template est un fichier YAML qui répond à une question simple : “Comment détecter cette vulnérabilité ?”

On peut penser aux templates comme des “recettes de détection”. Les ingrédients sont l’URL cible, les headers HTTP, le corps de requête. Les instructions décrivent quelle requête envoyer et quel pattern chercher. Le résultat attendu est simple : si on trouve X dans la réponse, la cible est potentiellement vulnérable.

Un template se compose de quatre éléments. Le bloc info contient l’identité du check : son identifiant unique, son nom, l’auteur, la sévérité et les tags. Le bloc http (ou dns, tcp selon le protocole) décrit ce qu’on envoie à la cible. Les matchers définissent les critères pour détecter une vulnérabilité. Enfin, les extractors (optionnels) permettent d’extraire des informations utiles de la réponse.

Structure d’un template

Voici un template simple commenté pour comprendre chaque partie :

# Identifiant unique du template (utilisé dans les rapports)
id: git-config-exposure

# Métadonnées : qui, quoi, gravité
info:
  name: Git Config File Exposure
  author: ice3man
  severity: medium
  description: Détecte l'exposition du fichier .git/config
  tags: git,config,exposure

# La requête HTTP à envoyer
http:
  - method: GET
    path:
      # {{BaseURL}} sera remplacé par l'URL cible
      - "{{BaseURL}}/.git/config"

    # Conditions pour déclarer une vulnérabilité
    matchers:
      - type: word
        words:
          # Si ces deux mots sont présents dans la réponse...
          - "[core]"
          - "[remote"
        # ...ET qu'ils sont tous les deux présents
        condition: and

Ce template fait une chose simple : il accède à /.git/config et vérifie si la réponse contient des marqueurs d’un fichier de configuration Git. Si oui, le fichier est exposé publiquement — problème de sécurité.

Lister les templates disponibles

# Lister tous les templates
nuclei -tl

# Lister les tags disponibles
nuclei -tgl

# Afficher un template spécifique
nuclei -t cves/2021/CVE-2021-44228.yaml -td

Utiliser des templates spécifiques

# Exécuter un template précis
nuclei -u http://localhost:3000 -t cves/2021/CVE-2021-44228.yaml

# Exécuter tous les templates d'un dossier
nuclei -u http://localhost:3000 -t cves/2024/

# Combiner plusieurs sources
nuclei -u http://localhost:3000 -t cves/ -t exposures/

Écrire un template personnalisé

Créer un template pour détecter une page de debug exposée :

id: debug-page-exposure

info:
  name: Debug Page Exposure
  author: votre-nom
  severity: low
  description: Détecte des pages de debug exposées
  tags: debug,exposure,custom

http:
  - method: GET
    path:
      - "{{BaseURL}}/debug"
      - "{{BaseURL}}/_debug"
      - "{{BaseURL}}/debug.php"

    matchers-condition: or
    matchers:
      - type: word
        words:
          - "Debug Information"
          - "Stack Trace"
          - "Environment Variables"

      - type: status
        status:
          - 200

Valider un template personnalisé

Avant de déployer un template en production, il est essentiel de le valider. Nuclei charge et parse le YAML, puis exécute les requêtes définies. Un template mal formé sera rejeté au chargement, mais un template syntaxiquement correct peut quand même produire des faux positifs ou rater des vulnérabilités.

La démarche de validation se fait en trois étapes. D’abord, créer le fichier template dans un dossier dédié :

# Créer un dossier pour les templates personnalisés
mkdir -p ~/nuclei-templates-custom

# Créer le fichier template
cat > ~/nuclei-templates-custom/debug-page.yaml << 'EOF'
id: debug-page-exposure

info:
  name: Debug Page Exposure
  author: votre-nom
  severity: low
  description: Détecte des pages de debug exposées
  tags: debug,exposure,custom

http:
  - method: GET
    path:
      - "{{BaseURL}}/debug"
      - "{{BaseURL}}/_debug"

    matchers:
      - type: word
        words:
          - "Debug Information"
          - "Stack Trace"
EOF

Ensuite, exécuter le template avec le flag -v (verbose) pour voir exactement ce que Nuclei fait :

nuclei -u http://localhost:3000 -t ~/nuclei-templates-custom/debug-page.yaml -v

La sortie verbose montre chaque requête envoyée. Si le template est valide, Nuclei affiche le nombre de templates chargés (1) et les requêtes HTTP effectuées. Un message “No results found” est normal si la cible ne présente pas la vulnérabilité recherchée — cela confirme que le template fonctionne mais n’a rien détecté.

Optimiser les scans

Par défaut, Nuclei envoie jusqu’à 150 requêtes par seconde. Cette agressivité est parfaite pour scanner ses propres infrastructures, mais elle peut poser problème dans certains contextes : saturer un serveur de test, déclencher des alert WAF, ou simplement être mal perçu lors d’un audit client.

L’optimisation des scans consiste à trouver le bon équilibre entre vitesse et discrétion, tout en évitant les templates inutiles pour son contexte.

Contrôler la vitesse

Le rate limiting est essentiel pour les scans en environnement sensible. Une valeur de 100 requêtes par seconde est généralement bien tolérée. Pour les audits discrets, descendre à 20-50 r/s évite de déclencher les systèmes de détection d’intrusion.

# Limiter le nombre de requêtes par seconde
nuclei -l targets.txt -rate-limit 100

# Ajuster la concurrence
nuclei -l targets.txt -c 50 -bulk-size 25

Flag	Description	Défaut
`-rate-limit`	Requêtes par seconde maximum	150
`-bulk-size`	Hosts en parallèle par template	25
`-c`	Templates en parallèle	25
`-timeout`	Timeout par requête (secondes)	10

Exclure des templates

Tous les templates ne sont pas adaptés à tous les contextes. Les templates taggés dos (denial of service) peuvent perturber un service en production. Ceux taggés fuzz génèrent un grand volume de requêtes avec des payloads exotiques, ce qui peut déclencher des alertes ou surcharger les logs.

En environnement de production ou lors d’un audit client, il est prudent d’exclure ces catégories. On peut aussi exclure des templates spécifiques qu’on a identifiés comme générant des faux positifs dans son contexte.

# Exclure par tags
nuclei -u http://localhost:3000 -etags dos,fuzz

# Exclure des templates spécifiques
nuclei -u http://localhost:3000 -exclude-templates cves/2020/CVE-2020-XXXX.yaml

Configuration persistante

Créer un fichier de configuration pour éviter de répéter les options :

# Créer le fichier de config
mkdir -p ~/.config/nuclei
cat > ~/.config/nuclei/config.yaml << EOF
# Sévérités à scanner par défaut
severity:
  - critical
  - high
  - medium

# Tags à exclure
exclude-tags:
  - dos
  - fuzz

# Rate limiting
rate-limit: 100

# Headers personnalisés (bug bounty)
header:
  - "X-Bug-Bounty: votre-pseudo"
EOF

Intégration CI/CD

Intégrer Nuclei dans un pipeline CI/CD permet de détecter les vulnérabilités avant qu’elles n’atteignent la production. L’idée est d’exécuter un scan automatisé à chaque déploiement ou de manière planifiée.

Deux approches complémentaires existent. Les scans planifiés (quotidiens ou hebdomadaires) effectuent un audit complet de l’infrastructure. Les scans au déploiement vérifient rapidement que la nouvelle version n’introduit pas de vulnérabilité critique.

Les exemples ci-dessous montrent comment configurer les deux approches sur GitHub Actions et GitLab CI.

GitHub Actions

Ce workflow exécute un scan à chaque push sur main et quotidiennement à 2h du matin. Il exporte les résultats au format SARIF pour une intégration native avec GitHub Security, et archive les résultats JSON pour analyse ultérieure.

name: Security Scan
on:
  push:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'  # Tous les jours à 2h

jobs:
  nuclei-scan:
    runs-on: ubuntu-latest
    steps:
      # Épingler les actions par hash SHA pour la sécurité supply chain
      - name: Checkout
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

      - name: Install Nuclei
        run: |
          # Épingler la version pour reproductibilité
          go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@v3.6.0
          nuclei -update-templates

      - name: Run Nuclei
        run: |
          nuclei -l targets.txt \
            -severity critical,high \
            -sarif-export nuclei.sarif \
            -jsonl -o nuclei-results.jsonl

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@48ab28a6f5dbc2a99bf1e0131198dd8f1df78169 # v3.28.0
        with:
          sarif_file: nuclei.sarif

      - name: Upload Results
        uses: actions/upload-artifact@b4b15b8c7c6ac21ea08fcf65892d2ee8f75cf882 # v4.4.3
        with:
          name: nuclei-results
          path: nuclei-results.jsonl

GitLab CI

Sur GitLab, l’image Docker officielle simplifie l’intégration. Le job suivant s’exécute lors des pipelines planifiés et sur les commits de la branche main. Les résultats sont archivés pendant une semaine.

nuclei-scan:
  # Épingler la version pour reproductibilité
  image: projectdiscovery/nuclei:v3.6.0
  stage: security
  script:
    - nuclei -l targets.txt
        -severity critical,high
        -jsonl -o nuclei-results.jsonl
  artifacts:
    paths:
      - nuclei-results.jsonl
    expire_in: 1 week
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
    - if: $CI_COMMIT_BRANCH == "main"

Bonnes pratiques CI/CD

Quelques recommandations pour une intégration réussie dans les pipelines.

Épingler les versions des images Docker et des actions GitHub. Utiliser projectdiscovery/nuclei:v3.6.0 plutôt que :latest garantit la reproductibilité des scans et évite les mauvaises surprises lors des mises à jour automatiques.

En CI/CD, limiter la sévérité aux niveaux critical et high évite de bloquer les déploiements pour des problèmes mineurs. On pourra toujours exécuter des scans complets en dehors du pipeline.

Exclure les templates destructifs avec -etags dos,fuzz est essentiel. Ces templates peuvent perturber l’application ou générer un volume de requêtes problématique.

Penser à définir un timeout global pour éviter les scans qui s’éternisent. Un pipeline bloqué pendant des heures sur un scan de sécurité n’est pas acceptable.

L’export en SARIF permet une intégration native avec GitHub Security et GitLab. Les vulnérabilités apparaissent directement dans l’interface de la plateforme.

Enfin, archiver les résultats permet de suivre l’évolution de la posture de sécurité dans le temps et d’identifier les régressions.

Cas d’usage avancés

Les scans de base couvrent les vulnérabilités accessibles sans authentification. Mais une grande partie de la surface d’attaque se trouve derrière une authentification : dashboards d’administration, API internes, espaces clients. Nuclei propose plusieurs mécanismes pour scanner ces zones protégées.

Scan authentifié

Pour scanner des endpoints protégés, on passe les headers d’authentification directement à Nuclei. Cela peut être un token Bearer pour une API REST, un cookie de session pour une application web classique, ou un header custom.

L’idéal est de récupérer ces credentials via l’API de l’application ou de les générer dans le pipeline CI/CD. Éviter de stocker des credentials en dur dans les scripts.

# Avec un header d'authentification
nuclei -u https://app.example.com \
  -H "Authorization: Bearer eyJhbGc..." \
  -t authenticated/

# Avec des cookies
nuclei -u https://app.example.com \
  -H "Cookie: session=abc123" \
  -t authenticated/

Scan avec Interactsh (OAST)

Certaines vulnérabilités ne se manifestent pas dans la réponse HTTP immédiate. Une injection SSRF peut déclencher une requête vers un serveur externe. Une RCE blind exécute du code sans retourner le résultat directement. Pour détecter ces cas, Nuclei utilise Interactsh : un serveur qui capture les callbacks générés par les payloads injectés.

Concrètement, Nuclei insère des URLs Interactsh dans ses payloads. Si la cible est vulnérable et exécute le payload, elle contacte le serveur Interactsh. Nuclei détecte alors la callback et signale la vulnérabilité.

# Activer Interactsh (activé par défaut)
nuclei -u http://localhost:3000 -tags oast

# Désactiver si nécessaire
nuclei -u http://localhost:3000 -no-interactsh

Workflows

Les workflows permettent d’enchaîner des templates conditionnellement. Par exemple, le workflow WordPress commence par détecter si la cible utilise ce CMS. Si oui, il exécute tous les templates spécifiques à WordPress. Sinon, il passe à la cible suivante sans perdre de temps.

Cette approche optimise les scans sur de larges listes de cibles hétérogènes : chaque cible ne reçoit que les tests pertinents pour sa stack technique.

# Exécuter un workflow
nuclei -u http://localhost:3000 -w workflows/wordpress-workflow.yaml

Les workflows disponibles couvrent les CMS populaires (WordPress, Joomla, Drupal), les technologies courantes (PHP, Java, .NET) et certains produits spécifiques (GitLab, Confluence, Grafana).

Conclusion

Nuclei s’impose comme l’outil de référence pour le DAST grâce à sa rapidité, son extensibilité et sa communauté active. En quelques minutes, on peut scanner une infrastructure pour les dernières CVE et misconfigurations.

Pour démarrer efficacement, commencer par installer Nuclei via Go ou le binaire précompilé. Ensuite, prendre l’habitude de mettre à jour les templates régulièrement avec -update-templates — c’est là que réside la valeur de l’outil.

Lors des scans, filtrer par sévérité et tags selon le contexte évite de se noyer dans les résultats. Pour les équipes, intégrer Nuclei dans la CI/CD avec export SARIF automatise la détection.

Avec le temps, on apprend à personnaliser l’outil avec des templates maison pour les checks spécifiques à son environnement. Et toujours, vérifier manuellement les findings avant de les reporter — un scanner n’est pas infaillible.

La puissance de Nuclei réside dans son écosystème : quand une nouvelle CVE tombe, un template est souvent disponible dans les heures qui suivent.

Ressources externes

Documentation officielle Nuclei ↗
Dépôt des templates ↗
Guide d’écriture de templates ↗
ProjectDiscovery Cloud ↗ — dashboard et gestion centralisée