GHSA-jpf4-98qj-qr67: OS Command Injection
A vulnerability in Nuclei's DAST template loading path allows unsigned code: protocol templates to execute, bypassing the cryptographic signature requirement that is meant to prevent arbitrary command execution from untrusted templates.
Affected Component
The issue is in the template loader's DAST loading branch. When -dast is enabled and a template contains a fuzzing: block, the loader accepted the template through a code path that omitted the unsigned-code-template signature check present in the normal loading branch.
Description
Nuclei requires code: protocol templates to be cryptographically signed before execution. Unsigned code templates are normally skipped with a warning. However, when a template combined a fuzzing: block (making it DAST-eligible) with an unsigned code: block, enabling -dast routed the template through the DAST loader branch, which did not enforce signature verification.
For multiprotocol templates containing both HTTP and code: blocks, the unsigned code request was included in the execution queue regardless of whether -code was set. This allowed arbitrary shell command execution from an unsigned code: block with only -dast enabled.
[!NOTE] Both DAST mode (-dast) and code-protocol templates are disabled by default. Code templates normally require both the -code flag and a valid template signature. This issue bypassed the signature and -code controls only when -dast was explicitly enabled.
Affected Users
- CLI users running DAST/fuzzing scans (-dast) with untrusted or attacker-supplied templates that contain both fuzzing: and code: blocks. - SDK users who integrate Nuclei with DAST mode enabled and allow end users to supply custom templates.
Patches
- The vulnerability is fixed in Nuclei v3.10.0. Upgrading is strongly recommended. - Fix reference: https://github.com/projectdiscovery/nuclei/pull/7472
Mitigation
Upgrade to Nuclei v3.10.0, where code template signature verification is enforced before DAST loading.
In the meantime, avoid running DAST scans with untrusted templates.
Workarounds
If upgrading is not an option, do not use -dast with templates from unverified sources.
Acknowledgments
Thanks to @daffainfo for reporting this issue.
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 v3.10.0 - Compensating control
If upgrading is not possible, do not enable -dast for scans using untrusted or unverified templates, especially templates containing both fuzzing: and code: blocks.
Event History
Frequently Asked Questions
Which Nuclei runs are exposed to this bypass?
Runs with -dast enabled are exposed when they load a template that combines a fuzzing: block with an unsigned code: block. Multiprotocol templates containing HTTP and code: blocks can queue the unsigned code request even when -code was not set.
What does an attacker need to exploit this issue?
An attacker needs to get an affected user to run Nuclei with -dast against an attacker-controlled or otherwise untrusted template containing the required fuzzing: and unsigned code: blocks. User interaction is required because the template must be loaded and executed by the user.
What is the impact if exploitation succeeds?
The unsigned code: block can execute arbitrary shell commands on the system running Nuclei. The signature requirement intended to prevent command execution from untrusted code templates is bypassed.
How can I reduce risk before a fix is available?
Do not enable -dast when loading templates that are not trusted. In particular, avoid templates that combine fuzzing: with code: blocks, and do not rely on omitting -code to prevent code execution in affected multiprotocol templates.