CVE-2026-76805: Nuclei: Environment Variable Disclosure via Response-Derived Data in DAST/Fuzz Mode
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 / 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 {{envvarname}} 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.
Other sources
Nuclei is a vulnerability scanner built on a simple YAML-based DSL. From 3.0.0 until 3.10.0, the DAST/fuzz payload path in pkg/fuzz/parts.go can evaluate substituted runtime data more than once, creating a second evaluation pass that allows response content captured by an internal: true extractor in one protocol step to be reinterpreted as template syntax in a later fuzz step. This vulnerability is an incomplete fix for CVE-2026-41645: the prior remediation made expressions.Evaluate() single-pass within one call but did not prevent DAST/fuzz callers from evaluating substituted output again. When -env-vars is enabled, a malicious scan target can return marker-shaped content that resolves against the template variable map and discloses scanner-host environment variables such as credentials, API keys, or tokens. The vulnerability requires a multi-step DAST or fuzz template, response data reused through an internal extractor, and explicit environment-variable expansion; users who do not enable -env-vars are not affected by the sensitive-information disclosure. This issue is fixed in version 3.10.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/projectdiscovery/nuclei/v3to a version that resolves this vulnerability.Fixed in 3.10.0 - Upgrade
Upgrade
Nucleito a version that resolves this vulnerability.Fixed in 3.10.0 - Configuration
Disable -env-vars / -ev when running DAST or fuzz scans with multi-step templates against untrusted targets.
Nuclei DAST/fuzz scanning -env-vars / -ev = disabled
Event History
Frequently Asked Questions
Which deployments are exposed to environment-variable disclosure?
Only scans using a multi-step DAST or fuzz template, an internal: true extractor that reuses response data in a later fuzz step, and the -env-vars option are exposed. Users that do not enable -env-vars are not affected by this sensitive-information disclosure.
What does an attacker need to do to exploit this?
A malicious scan target must return marker-shaped response content that is captured by an internal extractor and reused in a later fuzz step. The second evaluation pass can then resolve that content against the template variable map and disclose scanner-host environment variables.
What should be done if an immediate upgrade is not possible?
Do not run Nuclei with -env-vars enabled, and avoid multi-step DAST or fuzz templates that pass internally extracted response data into later fuzz steps. This prevents the described environment-variable disclosure condition.
How can I determine whether a past scan may have been affected?
Review scan invocations for the -env-vars option and identify multi-step DAST or fuzz templates using internal: true extractors whose response-derived values are reused in later fuzz steps. Scans lacking these conditions are not affected by the described disclosure.