Nuclei: Local File Read via require() Module Loader Bypass

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]

Basic information

Type
reviewed
Severity
medium
Advisory on GitHub
Open advisory ↗
Repository advisory
Open repository advisory ↗
Source code
Browse source ↗
Published (advisory)
2026-04-22 19:58:47 UTC
Updated
2026-05-11 13:30:21 UTC
GitHub reviewed
2026-04-22 19:58:47 UTC
NVD published
2026-05-08

EPSS Score

Score Percentile
0.01% 1.35%

CVSS Scores

Base score Version Severity Vector
5.5 3.1
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N Click to expand
Attack vector (AV:L)
They already need access on the box, or another person has to do something wrong; it’s not a remote drive-by.
Attack complexity (AC:L)
Once they can reach the bug, pulling it off is straightforward—no weird race conditions or rare setup.
Privileges required (PR:N)
No account or special rights needed—anonymous or random user is enough.
User interaction (UI:R)
A real person has to do something—click, install, enable—otherwise it doesn’t land.
Scope (S:U)
Damage stays in the same “trust bubble” as the broken component—no big spill into unrelated systems.
Confidentiality (C:H)
Serious risk that confidential data gets exposed in a big way.
Integrity (I:N)
Data isn’t meaningfully altered or forged.
Availability (A:N)
Service keeps running; no real outage angle.

Identifiers

CWEs

CWE id Name
CWE-284 Improper Access Control

Credits

  • AkashHamal0x01 (finder)

Affected packages (1)

Vulnerable version ranges and first patched releases as published by GitHub.

Ecosystem Package Vulnerable range First patched Vulnerable functions
go github.com/projectdiscovery/nuclei/v3 >= 3.0.0, < 3.8.0 3.8.0

References

cvelogic Threat Intelligence