What causes "regex extractor group must be >= 0, got %d" in projectdiscovery/nuclei?

Remove `group:` entirely if you want the full regex match (group 0 behavior)

regex extractor group must be >= 0, got %d

Error message

regex extractor group must be >= 0, got %d

What it means

Template compilation error from Extractor.CompileExtractors (pkg/operators/extractors/compile.go:24). For regex extractors only, the `group:` field (RegexGroup, the capture-group index used to extract a subgroup) must be >= 0; the default regexp convention in nuclei uses 0 for the full match. A negative value is rejected because regexp.MatchString-style subgroup access with a negative index is meaningless.

Source

Thrown at pkg/operators/extractors/compile.go:24

	"strings"

	"github.com/itchyny/gojq"
	"github.com/projectdiscovery/govaluate"
	"github.com/projectdiscovery/nuclei/v3/pkg/operators/cache"
	"github.com/projectdiscovery/nuclei/v3/pkg/operators/common/dsl"
)

// CompileExtractors performs the initial setup operation on an extractor
func (e *Extractor) CompileExtractors() error {
	// Set up the extractor type
	computedType, err := toExtractorTypes(e.GetType().String())
	if err != nil {
		return fmt.Errorf("unknown extractor type specified: %s", e.Type)
	}
	e.extractorType = computedType

	if e.extractorType == RegexExtractor && e.RegexGroup < 0 {
		return fmt.Errorf("regex extractor group must be >= 0, got %d", e.RegexGroup)
	}

	// Compile the regexes
	for _, regex := range e.Regex {
		if cached, err := cache.Regex().GetIFPresent(regex); err == nil && cached != nil {
			e.regexCompiled = append(e.regexCompiled, cached)
			continue
		}
		compiled, err := regexp.Compile(regex)
		if err != nil {
			return fmt.Errorf("could not compile regex: %s", regex)
		}
		_ = cache.Regex().Set(regex, compiled)
		e.regexCompiled = append(e.regexCompiled, compiled)
	}
	for i, kval := range e.KVal {
		e.KVal[i] = strings.ToLower(kval)
	}

View on GitHub (pinned to 265b3a3dec)

Solutions

Remove `group:` entirely if you want the full regex match (group 0 behavior)
Set `group: 0` for the whole match or `group: N` for an existing capture group N (>= 1)
Count capture parentheses in the regex to confirm the intended group index exists
Validate with `nuclei -validate -t template.yaml` before deployment

Example fix

# before
extractors:
  - type: regex
    regex:
      - 'id=([0-9]+)'
    group: -1
# after
extractors:
  - type: regex
    regex:
      - 'id=([0-9]+)'
    group: 1

Defensive patterns

Strategy: validation

Validate before calling

if ex.Type != nil && ex.GetType() == ea.RegexExtractor && ex.RegexGroup < 0 {
	return fmt.Errorf("rejecting template: regex extractor group %d < 0", ex.RegexGroup)
}

Type guard

func validRegexGroup(group int) bool { return group >= 0 }

Try / catch

// let CompileExtractors surface it, but map to author-friendly text:
if err := ex.CompileExtractors(); err != nil && strings.Contains(err.Error(), "regex extractor group") {
	return fmt.Errorf("template %s: fix 'group:' (must be >= 0)", tplPath)
}

Prevention

Omit group when the full match is wanted; use 0 explicitly if clearer
Never use Python-style negative group indices
Lint templates in CI with -validate to catch this pre-scan

When it happens

Trigger: An extractor with `type: regex` plus `group: -1` (sometimes written intending 'all groups' or a Python-style negative index), or a templating arithmetic mistake that renders group as a negative number.

Common situations: Copy-paste from PoC code using Python re semantics (group -1 = last group); attempting to reference the whole match and mistakenly writing -1 instead of omitting group or using 0; YAML anchors merging unexpected values.

Related errors

AI-assisted analysis of projectdiscovery/nuclei@265b3a3dec (2026-08-15). Data as JSON: /api/errors/5b284b2eeb5a2c28. Report an issue: GitHub.