NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

Nuclei: Local File Read via require() Module Loader BypassGHSA-29rg-wmcw-hpf4

MEDIUMFix: projectdiscovery/nuclei#7332

GHSA-29rg-wmcw-hpf4 is a medium-severity (CVSS 5.5) CWE-284 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.

Also known asCVE-2026-41646GO-2026-4965
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 9, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-29rg-wmcw-hpf4.

EPSS Exploitation Probability

via FIRST.org ↗
0.1%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs2th percentile — riskier than 2% of all scored CVEsHighest risk
0.00%0.22%0.44%0.66%0.0%0.1%Jun 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
🐹github.com/projectdiscovery/nuclei/v3

Real-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 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 files sitting on the host filesystem.

Affected Users

  • CLI users running untrusted or third-party JavaScript templates.
  • SDK users who have integrated Nuclei into platforms where end-users can supply JavaScript templates, especially when relying on the default file access restriction to limit filesystem reads.

[!NOTE] The require() module loader only resolves .js and .json files. Other file types cannot be read through this vector.

Patches

  • The vulnerability is fixed in Nuclei v3.8.0. Upgrading is strongly recommended.
  • Fix reference: #7332

Mitigation

Upgrade to Nuclei v3.8.0, where the require() registry is rebuilt per execution and file-backed module loads are routed through the same allow-local-file-access check as the rest of the filesystem operations.

In the meantime, avoid running JavaScript templates from unverified sources.

Workarounds

If upgrading is not an option, avoid running untrusted JavaScript templates entirely. There is no flag or configuration that mitigates this on affected versions.

Acknowledgments

Nuceli thanks @AkashHamal0x01 for reporting this issue through responsible disclosure via [email protected]

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/projectdiscovery/nuclei/v3≥ 3.0.0&&< 3.8.03.8.0go get github.com/projectdiscovery/nuclei/v3@v3.8.0

Affected Products

1 product · 1 configurations
Application
nucleiprojectdiscovery
≥ 3.0.0 && < 3.8.0
range

Detection & mitigation playbook

Open-source dependency

  1. Detect

    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.

  2. Fix

    Update github.com/projectdiscovery/nuclei/v3 to 3.8.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-29rg-wmcw-hpf4 is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

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 .
O3 Security · Impact-Aware SCA

Is GHSA-29rg-wmcw-hpf4 in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works
Nuclei: Local File Read via require() Module Loader Bypass