CVE-2026-76805 is a medium-severity (CVSS 5.3) Information Exposure vulnerability in github.com/projectdiscovery/nuclei/v3. A fix is available for github.com/projectdiscovery/nuclei/v3 — see the affected versions and patch details below.
Nuclei: Environment Variable Disclosure via Response-Derived Data in DAST/Fuzz Mode
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-76805.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-76805 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/projectdiscovery/nuclei/v3Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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 {{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/-evoption 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-evflag enabled. - SDK users who integrate Nuclei with the fuzz pipeline enabled,
EnvironmentVariablesset totrue, 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/projectdiscovery/nuclei/v3 | ≥ 3.0.0&&< 3.10.0 | 3.10.0go get github.com/projectdiscovery/nuclei/v3@v3.10.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/projectdiscovery/nuclei/v3, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/projectdiscovery/nuclei/v3 to 3.10.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-76805 is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.
Frequently Asked Questions
Is CVE-2026-76805 in your dependencies?
Find it across Go, including transitive dependencies.