[BUG] Request Parallelization and Hang Monitoring Issues

[zachsanchez113]

Hey y'all,

There are two issues that I've come across that I'd like to bring to your attention, or at least get your thoughts on:

1. Requests are not parallelized in all template cases, causing sequential execution
2. Hang monitoring produces false positives due to a hardcoded timeout value

Context

I'm trying to scan my company's domains en-masse (>10,000 in total), and I discovered these issues while experimenting with batching and:

1. Still triggering the hang monitor despite scanning with a more moderate number of hosts/templates.
2. Seeing dramatic speed dropoffs with high-severity templates when batching scans by severity.

Environment

• Version: 3.4.10, though I debugged this on the dev branch a week or two ago
• Target: any domain that's unreachable or consistently times out, e.g. a firewall doesn't allow you through (can't give a specific case, sorry!)
• Template: bitbucket-oauth-exposure
• Config (minus excluded templates and IDs):

type:
  - http
  - dns
# NOTE: I'm running httpx beforehand in a script
no-httpx: true
stats: true
timeout: 30
no-interactsh: true
restrict-local-network-access: true
hang-monitor: true
rate-limit: 10000
concurrency: 50

Issue 1: Incomplete Request Parallelization

Description: Requests are not parallelized in all template scenarios. Parallelization seems to only occurs for specific template classes (e.g. templates using payloads), while templates with multiple paths execute requests sequentially.

Specifically, in pkg/protocols/http/request.go, the ExecuteWithResults function contains a for loop that processes each request (generator.nextValue) sequentially, even when templates contain multiple paths that could be executed in parallel.

Specific Case: bitbucket-oauth-exposure, which has over 50 distinct requests that get executed sequentially due to the lack of parallelization. As a result, when run against a single domain that's unresponsive or consistently times out, a scan that should take less than a minute ends up taking nearly half an hour. Or even if it does respond and is just slow to do so. (Nevermind a large list of domains with ephemeral domains that could disappear mid-scan!)

Issue 2: Hang Monitor False Positives

Description: The hang monitor incorrectly identifies legitimate sequential processing as hangs due to hardcoded timing assumptions.

Specifically, the hang monitor checks goroutine stacks every 10 seconds, regardless of configured timeout values. This produces a false positive when:

1. The engine processes a single domain with sequential requests
2. Timeout values are higher than 10 seconds
3. Issue 1 causes legitimate sequential delays

Specific Case: Same template and target as before. With 30-second timeouts and sequential request processing, the hang monitor triggers false positives because goroutine stacks remain similar during legitimate timeout periods.

Proposed Fix: In cmd/nuclei/main.go, modify the stackMonitor.Start call:

// Current:
stackMonitor.Start(10 * time.Second)

// Proposed fix:
stackMonitor.Start(time.Duration(options.Timeout+1) * time.Second)