JSON Extractors do not allow variables in queries

[5731la]

When processing a JSON extractor, compiling occurs prior to runtime (compile.go#L33), and as such, templated variables are not processed.

Template example:

id: catapi
info:
  name: catapi test template
  author: Stella
  severity: critical
  description: test template call that should always return as critical
  tags: meow,meowmeow,meowmeowmeow
variables:
  catid: '[a-zA-Z0-9]'
http:
  - id: bulk-sisid-takeover
    method: GET
    path:
      - "https://api.thecatapi.com/v1/images/search?limit=10"
    extractors:
      - type: json
        part: body
        name: id
        # Find a URL based on a catid specified in a variable or extractor, if it exists, extract it. 
        json:
          - '(.[] | select(.id | test("{{catid}}")) | .url)'

Expected behavior:

This always returns a finding as this regular expression is checking if the URL contains any letters/numbers.

Actual behavior:

Never returns, as it is testing for {{catid}} literally rather than filling the variable.

Proposed fixes:

1. Clearly document that this is a limitation of this (and ALL) extractors (this limitation also applies to extractors, built-in variables like {{BaseURL}}, etc)
2. Perform Just-In-Time compilation of extractors with the variables substituted in
3. Use gojq's WithVariables

[tayfuryldz]

Your diagnosis still matches current dev: JSON extractor queries are parsed and compiled in pkg/operators/extractors/compile.go with gojq.Parse(query) + gojq.Compile(query), and ExtractJSON later only runs the precompiled gojq.Code. I also checked the current tree for gojq.WithVariables; JSON extractors do not use it. So {{catid}} inside json: is treated as part of the jq program rather than being substituted by Nuclei at request time; this is not a syntax mistake in the example template.

A template-level workaround is to keep dynamic values in Nuclei’s normal runtime variable/DSL path (or extract a broader value first and filter it afterward), rather than embedding a Nuclei template variable inside the jq query itself. Supporting the exact form in the example would require an engine change: either compiling the query after Nuclei variable substitution or explicitly plumbing runtime values into gojq variables. Documenting this limitation would also be useful because the current behavior is easy to mistake for a broken extractor.