## 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.

```text
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