panic: runtime error" when nuclei runs custom template against authorized target

TL;DR

A panic on a custom template means the template triggers a bug in nuclei's template engine, usually a nil value in an extractor or matcher. Update nuclei first, since many panics are already fixed upstream. Then shrink the template to a minimal repro, find the crashing block, and rewrite it without the nil path.

panic: runtime error: invalid memory address or nil pointer dereference

Use this when

• The panic happens only with your custom template, not bundled ones.
• The stack trace points into template execution.
• The target is in your authorized scope.

Not for this skill when

• Bundled templates panic too. Then the nuclei binary or environment is broken.
• The template errors but does not panic. Read the error instead.

Steps

1. Update nuclei to the latest release. Verify: nuclei -version shows a current build and the panic is retested.
2. Isolate the template: run it alone against a lab host with -t custom-check.yaml -u https://target.example.com. Verify: the panic reproduces with just this template.
3. Bisect the template: comment out half the matchers and extractors, rerun, and repeat. Verify: you identify the single block that triggers the panic.
4. Rewrite the crashing block defensively. Extractors on missing headers and matchers on empty bodies are the usual nil paths; guard them or drop the block. Verify: the minimal template runs without panic.
5. Rebuild the full template from the fixed minimal version, testing after each added block. Verify: the complete template scans the authorized target cleanly.

Compatibility: nuclei 3.x. Panic behavior varies by version, which is why updating comes first.

Variant phrasings

nuclei panic runtime error custom template

Same fix path, common phrasing.

nuclei nil pointer template

The cause-flavored search.

nuclei crashes on template

Symptom-level search.

Why it happens

nuclei's engine assumes certain template fields produce values. When an extractor runs against a response part that does not exist, or a matcher references a part the request never fetched, the engine can dereference nil and panic. Custom templates explore combinations the bundled ones never hit, so they find these paths first.

Edge cases / pitfalls

• A panic may corrupt the output file. Treat results from a panicking run as untrustworthy and rerun.
• Report the minimal repro upstream. Template-engine panics are bugs worth filing.
• Do not work around a panic by wrapping the scan in a restart loop. Fix the template.
• Only test the repro template against lab or authorized targets. A crashing template still sends requests.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dcwfNwoFzoq7Vm4fk0KI1g