[BUG] matcher-status only outputs last failure when multiple requests fail

[reta-ygs]

Is there an existing issue for this?

• I have searched the existing issues.

Current Behavior

When using the -matcher-status (-ms) flag with templates containing multiple requests, only the last failed request is output when multiple or all requests fail to match. This is a regression introduced after August 2024.

For example, when running a template with 3 paths that all fail to match:

• Without -ms: No output (expected)
• With -ms: Only 1 failure event is output (the last request)
• Expected with -ms: All 3 failure events should be output

This affects both standard output and JSONL (-j) output formats.

Expected Behavior

When -matcher-status is enabled, ALL failed matcher results should be output, not just the last one.

Standard output example:

[test-all-fail] [failed] [http] [info] example.com/
[test-all-fail] [failed] [http] [info] example.com/test  
[test-all-fail] [failed] [http] [info] example.com/admin

JSONL output example:

{"template-id":"test-all-fail","host":"example.com","path":"/","matcher-status":false,...}
{"template-id":"test-all-fail","host":"example.com","path":"/test","matcher-status":false,...}
{"template-id":"test-all-fail","host":"example.com","path":"/admin","matcher-status":false,...}

Steps To Reproduce

1. Create a test template file test-multiple-failures.yaml:

id: test-multiple-failures

info:
  name: Test Multiple Failures
  author: test
  severity: info

http:
  - method: GET
    path:
      - "{{BaseURL}}/"
      - "{{BaseURL}}/test"
      - "{{BaseURL}}/admin"
    
    matchers:
      - type: word
        words:
          - "THIS_STRING_WILL_NOT_MATCH"
        part: body

2. Run without -ms flag (no output expected):

nuclei -t test-multiple-failures.yaml -u https://example.com -silent

3. Run with -ms flag:

nuclei -t test-multiple-failures.yaml -u https://example.com -ms -silent

4. Observe that only one failure is shown instead of three

5. For JSONL output, run:

nuclei -t test-multiple-failures.yaml -u https://example.com -ms -j -silent | wc -l

This outputs 1 instead of the expected 3

Relevant log output

[test-multiple-failures] [failed] [http] [info] example.com

Environment

- OS: macOS Darwin 24.6.0
- Nuclei: v3.4.7 (current dev branch)
- Go: go1.22.0

Anything else?

Root Cause Analysis:

The regression was introduced in commit cc5c5509 (feat: global matchers #5701) on October 14, 2024. The bug is in pkg/tmplexec/exec.go lines 184-189:

wr := writer.WriteResult(event, e.options.Output, e.options.Progress, e.options.IssuesClient)
if wr && !isGlobalMatchers {
    matched.Store(true)
} else {
    lastMatcherEvent = event  // Bug: overwrites even when wr is true
}

The problem is that lastMatcherEvent is being set in the else block even when WriteResult returns true (successful write) if isGlobalMatchers is true. This causes all events to overwrite the previous one, resulting in only the last event being retained.

Impact:

• This affects audit and logging use cases where all request results need to be tracked
• The -matcher-status flag is commonly used for security assessments to log all attempted checks
• JSONL output for data analysis is incomplete

Proposed Fix:
The else condition should be corrected to only set lastMatcherEvent when WriteResult returns false:

wr := writer.WriteResult(event, e.options.Output, e.options.Progress, e.options.IssuesClient)
if wr {
    if !isGlobalMatchers {
        matched.Store(true)
    }
} else {
    lastMatcherEvent = event
}

[dwisiswant0]

likely same root cause of #6252 & #6351 issues

[reta-ygs]

After investigating the history, I found this behavior is actually by design, not a bug.

In PR #3770, the -ms flag was intentionally changed to show only one failure per template (specifically the last one) to address issue #2693 where it was showing multiple failure lines for the same template. The -msr flag for per-request output was initially proposed but was removed before merging, with the decision that the feature should focus on template-level status only.

While this is working as designed, I find the current behavior confusing when debugging templates with multiple requests since you can't see which specific requests are failing.

I'd like to propose two improvements:

1. Update the documentation to clarify that -ms only shows the last failed request per template
2. Consider reimplementing -msr for those who need detailed per-request debugging

Example of what -msr would provide:

# Current (-ms): Shows only last failure
$ nuclei -t template.yaml -u http://example.com -ms
[template-id] [failed] [http] [info] http://example.com

# Proposed (-msr): Shows all failures
$ nuclei -t template.yaml -u http://example.com -msr
[template-id] [failed] [http] [info] http://example.com/path1
[template-id] [failed] [http] [info] http://example.com/path2
[template-id] [failed] [http] [info] http://example.com/path3

This would maintain backward compatibility while providing the debugging flexibility that was originally intended in PR #3770.

[ehsandeep]

@reta-ygs thanks for the suggestion! However, I don’t think -msr fits well with Nuclei’s template system. There are many edge cases this would introduce. For example:

• Some templates use large payload lists (hundreds or thousands of items). With -msr, each payload could generate a separate result for each request, it might be useful in certain context, but it will introduce confusion with diffrent kind of templates.
• Nuclei supports multiple protocols (not just HTTP). For non-HTTP templates, the concept of “multiple status responses” doesn’t apply at all.
• And there are other cases as well that would be difficult to cover comprehensively.

Since Nuclei doesn’t operate at the request level and is intentionally focused on template-level configuration, adding this functionality would be inconsistent with its design. More importantly, it’s not something we could confidently maintain in the long run.

For those reasons, I don’t think it’s a good idea to introduce -msr at this point.

Moving this to discussion to keep it as idea for future!