GHSA-jpvm-9frm-hjcq

A vulnerability in Nuclei's DAST/fuzz expression evaluation path allows a malicious target server to trigger disclosure of scanner-host environment variables when the `-env-vars` / `-ev` option is explicitly enabled.

This is an incomplete fix for [CVE-2026-41645](https://github.com/projectdiscovery/nuclei/security/advisories/GHSA-jm34-66cf-qpvr) / GHSA-jm34-66cf-qpvr. The original fix hardened `expressions.Evaluate()` to be single-pass within one call, but did not address callers that invoked evaluation multiple times on substituted output in the DAST/fuzz pipeline.

**Affected Component**

The issue is in the DAST/fuzz payload evaluation path (`pkg/fuzz/parts.go`) and the shared template rendering boundary. When a multi-step template captures response data via an internal extractor and reuses it in a subsequent fuzz step, the fuzz evaluator could treat the substituted response content as fresh template syntax on a second evaluation pass.

**Description**

In DAST/fuzz mode, payload evaluation previously ran expression substitution more than once on the same value. Response-derived content captured by an `internal: true` extractor in a prior protocol step could flow into a fuzz payload and be reinterpreted as DSL/helper syntax on a subsequent pass.

When `-env-vars` (`-ev`) is enabled, environment variables are merged into the template variable map. A malicious target can return response data containing expressions like `{{env_var_name}}` which, when reused in a subsequent fuzz step, resolve to actual environment variable values. This can expose sensitive host data such as API keys, credentials, and tokens.

Without `-ev` enabled (the default), response-derived data may still cause other DSL helpers to run, but that behavior is not treated as a security issue and has no meaningful security impact beyond unexpected behavior.

> [!NOTE] The `-env-vars` / `-ev` option is off by default. Users who have not explicitly enabled it are not affected by this vulnerability.

**Affected Users**

- **CLI users** running `nuclei -dast` (or fuzzing) with multi-step templates that chain an internal extractor into a subsequent fuzz step against untrusted targets, with the `-ev` flag enabled. - **SDK users** who integrate Nuclei with the fuzz pipeline enabled, `EnvironmentVariables` set to `true`, and scan targets that are not fully trusted.

**Patches**

- The vulnerability is fixed in Nuclei v3.10.0. Upgrading is strongly recommended. - Fix reference: https://github.com/projectdiscovery/nuclei/pull/7499 - Related original fix: https://github.com/projectdiscovery/nuclei/pull/7221, https://github.com/projectdiscovery/nuclei/pull/7321

**Mitigation**

Upgrade to Nuclei v3.10.0, where template-authored text is rendered once through a shared rendering boundary and runtime values from responses, extractors, and constants remain opaque data.

If you have `-ev` enabled, disable it when scanning untrusted targets to avoid environment variable disclosure.

**Workarounds**

If upgrading is not an option, ensure `-env-vars` / `-ev` is not enabled when running DAST/fuzz scans with multi-step templates against untrusted targets.

**Acknowledgments**

Thanks to @BerSecHub for reporting this issue.