EUVD-2026-28498
GHSA-jm34-66cf-qpvr
Severity by source
AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N
Lifecycle Timeline
4DescriptionGitHub Advisory
A vulnerability in Nuclei's expression evaluation engine makes it possible for a malicious target server to inject and execute supported DSL expressions. This happens when HTTP response data containing helper/function syntax gets reused by multi-step templates. If the -env-vars / -ev option is explicitly enabled, this can expose host environment variables. That option is off by default, so standard configurations are not affected by the information disclosure risk.
Affected Component
The issue lives in expressions.Evaluate() at pkg/protocols/common/expressions/ and in the unresolved-variable validation path (hasLiteralsOnly()).
Description
expressions.Evaluate() replaces placeholders first, then scans the substituted output for expressions. Because of this two-pass approach, response-derived values (including extractor output and response body content) can be reinterpreted as DSL/helper syntax on the second pass.
When -env-vars (-ev) is enabled, environment variables get 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 template request, resolve to actual environment variable values. This can expose sensitive host data like API keys, credentials, and tokens.
Without -ev enabled (the default), injected DSL expressions may still trigger helper functions such as {{md5("test")}}, but this has no meaningful security impact beyond unexpected behavior.
There is also a separate issue in hasLiteralsOnly(): it was evaluating helper expressions while deciding whether {{...}} contained unresolved variables, which caused validation logic to run side-effectful helpers even when the final request kept the value as a literal.
> [!NOTE] The -env-vars / -ev option is off by default. Users who have not explicitly turned it on are not affected by the information disclosure aspect of this vulnerability.
Affected Users
- CLI users running multi-step templates (with extractors or flow-based request chaining) that reuse response-derived values against untrusted or attacker-controlled targets, with the
-evflag enabled. - SDK users who have integrated Nuclei into platforms where
EnvironmentVariablesis set totrueand scan targets are not fully trusted.
Patches
- The vulnerability is fixed in Nuclei v3.8.0. Upgrading to this version is strongly recommended.
- Relevant fix references: #7221, #7321.
Mitigation
Upgrade to Nuclei v3.8.0. The updated evaluation logic now collects expressions from the original template text before placeholder substitution and only evaluates those template-authored expressions.
If you have -ev enabled, disable it when scanning untrusted targets to avoid environment variable disclosure.
Workarounds
If upgrading is not an option right now, make sure -env-vars / -ev is not enabled when running multi-step templates against untrusted targets.
Acknowledgments
Nuclei thanks @gnuletik for reporting this issue through responsible disclosure via security@projectdiscovery.io
AnalysisAI
Expression injection in Nuclei's template evaluation engine allows malicious HTTP servers to inject and execute DSL expressions via response data reused in multi-step templates. When the -env-vars flag is enabled (off by default), attackers can exfiltrate host environment variables including API keys and credentials; without this flag, injected expressions may trigger helper functions with limited security impact. Nuclei v3.8.0+ patches the vulnerability by collecting expressions from template source before placeholder substitution, preventing response-derived data from being reinterpreted as executable DSL syntax.
Technical ContextAI
Nuclei is a template-based vulnerability scanner that uses a domain-specific language (DSL) with helper functions for dynamic request generation. The vulnerability exists in the expressions.Evaluate() function (CWE-94: Code Injection) within pkg/protocols/common/expressions/. The root cause is a two-pass evaluation mechanism: first, placeholders in templates are replaced with values from prior steps or HTTP responses, then the substituted output is scanned for expressions like {{function()}} or {{variable_name}}. This design inadvertently allows response content to be reinterpreted as executable DSL. When the -env-vars flag merges environment variables into the template variable map, a malicious server can return payloads such as {{env_variable_name}} which resolve during subsequent template execution. A secondary issue in hasLiteralsOnly() validation logic caused unintended evaluation of helper expressions during variable resolution checks, triggering side-effectful operations.
RemediationAI
Upgrade to Nuclei v3.8.0 or later immediately. The patched version corrects the evaluation engine to collect and validate expressions from the original template source before placeholder substitution, preventing response-derived data from being reinterpreted as DSL syntax. Apply patches via go get -u github.com/projectdiscovery/nuclei/v3@v3.8.0 for Go module installations or download the latest release from https://github.com/projectdiscovery/nuclei/releases. If immediate upgrade is not possible, disable the -env-vars / -ev flag when scanning untrusted or attacker-controlled targets; this eliminates the information disclosure risk but does not prevent other injected helper functions from executing. Do not rely on workarounds long-term - the expression injection itself remains exploitable even without -ev enabled, and upgrade is the only complete fix. For organizations running Nuclei in CI/CD or scanning untrusted target environments, audit configurations to ensure -ev is not enabled by default in automation templates.
Same weakness CWE-94 – Code Injection
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today