Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/projectdiscovery/nuclei/v3 >= 3.0.0, < 3.8.0
Fixed in
3.8.0· Vendor fix available
Issue
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…
Recommended action: Upgrade to 3.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/projectdiscovery/nuclei/v3 >= 3.0.0, < 3.8.0
Fixed in
3.8.0· Vendor fix available
Issue
A vulnerability in Nuclei's JavaScript protocol runtime allows JavaScript templates to read local .js and .json files through the require() function, bypassing the default local file access restriction. Affected Component The issue is in the JavaScript runtime's module loading system. The goja require() function used a default host filesystem loader without routing through the allow-local-file-access check. Description The goja require() function in Nuclei's JavaScript protocol runtime used the default host filesystem loader, which allowed JavaScript templates to import .js and .json files from anywhere on the host filesystem, ignoring the allow-local-file-access (-lfa) option that controls file access outside the template directory. The impact is limited to .js and .json files, as goja's module loader only resolves those extensions. That said, this is still enough to expose sensitive data stored in JSON configuration files like package.json, credential stores, or cloud configuration…
Recommended action: Upgrade to 3.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/projectdiscovery/nuclei/v3 >= 3.0.0, < 3.3.2
Fixed in
3.3.2· Vendor fix available
Issue
A vulnerability has been identified in Nuclei's template signature verification system that could allow an attacker to bypass the signature check and possibly execute malicious code via custom code template. Affected Component The vulnerability is present in the template signature verification process, specifically in the signer package. Description The vulnerability stems from a discrepancy between how the signature verification process and the YAML parser handle newline characters, combined with the way multiple signatures are processed. This allows an attacker to inject malicious content into a template while maintaining a valid signature for the benign part of the template. Affected Users 1. CLI Users: Those executing custom code templates from unverified sources. This includes templates authored by third parties or obtained from unverified repositories. 2. SDK Users: Developers integrating Nuclei into their platforms, particularly if they permit the execution of custom…
Recommended action: Upgrade to 3.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Find a way to execute code template without -code option and signature. Details write a code.yaml: using nc to listen on 80: execute PoC template with nuclei: and nc will get id command output. We use -w to specify a workflow file, not -t to template file. and notice there is a workflows field in code.yaml to pretend to be a workflow file. Test in Linux and Nuclei v3.2.9 Impact Some web applications inherit from Nuclei and allow users to edit and execute workflow files. In this case, users can execute arbitrary commands. (Although, as far as I know, most web applications use -t to execute)
Recommended action: Upgrade to 3.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/projectdiscovery/nuclei/v3 >= 3.0.0, < 3.2.0
Fixed in
3.2.0· Vendor fix available
Issue
A significant security oversight was identified in Nuclei v3, involving the execution of unsigned code templates through workflows. This vulnerability specifically affects users utilizing custom workflows, potentially allowing the execution of malicious code on the user's system. This advisory outlines the impacted users, provides details on the security patch, and suggests mitigation strategies. Affected Users 1. CLI Users: Those executing custom workflows from untrusted sources. This includes workflows authored by third parties or obtained from unverified repositories. 2. SDK Users: Developers integrating Nuclei into their platforms, particularly if they permit the execution of custom workflows by end-users. Security Patch The vulnerability is addressed in Nuclei v3.2.0. Users are strongly recommended to update to this version to mitigate the security risk. Mitigation - Immediate Upgrade: The primary recommendation is to upgrade to Nuclei v3.2.0, where the vulnerability…
Recommended action: Upgrade to 3.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.