Overview of Nuclei Templates
mainvuln, cve, xss), authors, directories (e.g., http, dns, file), severity levels, and template types.repository·main·Indexed 11 days ago
https://github.com/projectdiscovery/nuclei-templatesA community-driven repository of scanning definitions for the Nuclei engine. It provides templates for automating the detection of vulnerabilities, misconfigurations, and exposed assets, including specialized sets for OSINT, credential stuffing, token-spraying, and phishing detection.
vuln, cve, xss), authors, directories (e.g., http, dns, file), severity levels, and template types.The OSINT templates in this directory are designed for two primary security tasks:
-V or -var flag.Nuclei supports different modes for processing credential lists:
-at or -attack-type clusterbomb option. This mode tests every entry in the password list against every entry in the username list, which is useful for verifying weak credentials across a list of email addresses.A standard Nuclei template consists of an id for identification, an info block for metadata (name, author, severity, description, references, classification, tags), and a protocol-specific block (like http or network) containing requests and matchers.
Key metadata fields include:
severity: critical|high|medium|low|infoclassification: Can include cve-id, cwe-id, or cvss-metrics.tags: Comma-separated strings for categorization.id: template-identifier
info:
name: Human Readable Vulnerability Name
author: your-github-username,vulnerability-discoverer-handle
severity: critical|high|medium|low|info
description: Clear explanation of what this template detects
reference:
- https://link-to-vulnerability-details
classification:
cve-id: CVE-2024-1234
cwe-id: CWE-89
tags: cve,sqli,rce
metadata:
verified: true
shodan-query: 'http.title:\"VulnApp\"'
http:
- method: GET
path:
- "{{BaseURL}}/vulnerable-endpoint"
matchers:
- type: word
words:
- "vulnerability_indicator"
part: bodyAvoid weak matchers that rely on generic terms (like admin or login) or version-only detection, as these cause high false positive rates. Instead, use a Multi-Layer Verification Strategy by setting matchers-condition: and and combining multiple layers:
Use condition: or within a layer if multiple proof methods are available.
# Multi-layer verification example
matchers-condition: and
matchers:
- type: word # Layer 1: Identify application
words:
- "Grafana Dashboard"
- "grafana.com/login"
part: body
- type: regex # Layer 2: Confirm version
regex:
- 'version.*[6-8]\.[0-5]\.[0-9]'
part: body
- type: word # Layer 3: Verify exploit success
words:
- "unauthorized_data_access"
- "/api/snapshots/{{randstr}}"
part: body
condition: orFor high-fidelity templates, use a multi-layered approach by setting matchers-condition: and and defining multiple matcher layers. This strategy typically involves:
# Use multiple verification layers
matchers-condition: and
matchers:
- type: word # Layer 1: Identify the application
words:
- "VulnApp Management Console"
part: body
- type: regex # Layer 2: Confirm vulnerable version
regex:
- 'Version: [1-2]\.[0-5]\.[0-9]'
part: body
- type: word # Layer 3: Verify vulnerability exists
words:
- "debug_info_exposed"
- "configuration_leak"
part: body
condition: orThe token-spray templates are designed to test an API token against multiple static API service endpoints. Unlike standard Nuclei templates that require target URLs as input, these templates are self-contained because the API endpoints are predefined within the templates themselves.
This is particularly useful for testing API keys that lack context (i.e., you have a key but do not know which service it belongs to). Nuclei will iterate through the known endpoints for the provided token and report any successful matches.
HTTP templates define requests using methods (GET, POST, PUT, DELETE), paths, headers, and bodies.
Key features:
{{BaseURL}} or {{Hostname}} to reference the target.headers and body (supports multi-line strings using |).disable-cookie: false (default) to reuse cookies.matchers-condition: and to require all matchers to pass, or or for any.http:
- method: GET|POST|PUT|DELETE
path:
- "{{BaseURL}}/endpoint"
# Alternative dynamic variable
- "{{Hostname}}/another-path"
headers:
User-Agent: Custom-Agent-String
Content-Type: application/json
Origin: https://example.com
body: |
{"param": "{{payload}}"}
disable-cookie: false
matchers-condition: and
matchers:
- type: word
words:
- "success_indicator"
part: bodyTo test self-hosted software instances, you must provide the target URL using the -u or --url option, along with the necessary credentials via the -var option.
nuclei -u https://jira.projectdiscovery.io/ -id jira-login-check -var username=testing@projectdiscovery.io -var password=test123 To avoid false positives, use a multi-layer verification strategy:
Use matchers-condition: and to combine these layers.
matchers-condition: and
matchers:
- type: word # Layer 1: App identification
words:
- "Apache Struts Framework"
- "struts-tags"
part: body
- type: regex # Layer 2: Version detection
regex:
- 'Struts 2\.[0-4]\.[0-9]+'
part: body
- type: word # Layer 3: Exploitation proof
words:
- "ognl.OgnlException"
- "java.lang.SecurityException"
part: body
condition: or