GHSA-qgw5-7j4f-fg97

A vulnerability in Nuclei's workflow template loader allows `file:` protocol templates to execute without the `-file` flag, bypassing a security gate that is meant to prevent local file reads on the scanner host. **Affected Component** The issue is in the workflow template loading path. The main template loader enforces the `-file` gate for file-protocol templates, but the workflow loader did not apply the same check when resolving templates referenced by a workflow. **Description** Nuclei disables file-protocol templates by default because they read local files from the host running the scanner. Operators must explicitly enable them with the `-file` flag. When a workflow references a file-protocol template, the workflow loader accepted and executed that template without verifying that `-file` was enabled. Because workflows run unsigned by default, an untrusted workflow could load and execute a file-protocol template and read local files from the scan target path, even though the operator had not enabled file templates. > [!NOTE] File-protocol templates are disabled by default. This issue only affects users who run workflows from untrusted sources without having explicitly enabled `-file`. **Affected Users** - **CLI users** running workflows (`-w`) that reference file-protocol templates from untrusted or third-party sources. - **SDK users** who integrate Nuclei into platforms where end users can supply workflow files and rely on the default `-file` restriction to block local file access. **Patches** - The vulnerability is fixed in Nuclei v3.10.0. Upgrading is strongly recommended. - Fix reference: https://github.com/projectdiscovery/nuclei/pull/7489 **Mitigation** Upgrade to Nuclei v3.10.0, where template execution requirements (including the `-file` gate) are enforced consistently across the main loader, workflow parsing, and request compilation paths. In the meantime, avoid running workflows from unverified sources. **Workarounds** If upgrading is not an option, do not run untrusted workflow files. There is no configuration flag that mitigates this bypass on affected versions. **Acknowledgments** Thanks to @daffainfo for reporting this issue.