CVE-2026-76803 is a medium-severity (CVSS 5.3) 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.
Nuclei: Local File Read via MySQL Client Sandbox Bypass
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-76803.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-76803 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/projectdiscovery/nuclei/v3Real-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 MySQL client library allows arbitrary local file reads that bypass the -allow-local-file-access (-lfa) sandbox restriction.
Affected Component
The issue is in the nuclei/mysql JavaScript library used by javascript: protocol templates. The MySQL client connection logic did not enforce the local file access sandbox when handling the allowAllFiles DSN parameter used by LOAD DATA LOCAL INFILE.
Description
Without -lfa, Nuclei confines local file access to the templates directory. However, a javascript: template could connect to a MySQL server with allowAllFiles=true in the connection DSN. With this option enabled, a malicious MySQL server can issue LOAD DATA LOCAL INFILE requests for arbitrary paths on the scanner host. The MySQL client reads the full file contents and sends them to the server, bypassing the same sandbox that blocks direct filesystem reads through other APIs.
javascript: templates execute without the -code flag and unsigned javascript: templates run by default, making this reachable from untrusted third-party templates when scanning attacker-controlled MySQL endpoints.
[!NOTE] The
-allow-local-file-access(-lfa) option is off by default. This issue allows bypassing that restriction, not merely expanding an already-enabled capability.
Affected Users
- CLI users running untrusted or third-party
javascript:templates against MySQL-compatible targets. - SDK users who integrate Nuclei into platforms where end users can supply JavaScript templates and rely on the default
-lfarestriction to limit filesystem access.
Patches
- The vulnerability is fixed in Nuclei v3.10.0. Upgrading is strongly recommended.
- Fix reference: https://github.com/projectdiscovery/nuclei/pull/7473
Mitigation
Upgrade to Nuclei v3.10.0, where the allowAllFiles DSN option is stripped unless -lfa is explicitly enabled.
In the meantime, avoid running JavaScript templates from unverified sources, especially against untrusted database endpoints.
Workarounds
If upgrading is not an option, avoid running untrusted JavaScript templates. There is no flag or configuration that mitigates this bypass on affected versions.
Acknowledgments
Thanks to @daffainfo for reporting this issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/projectdiscovery/nuclei/v3 | ≥ 3.0.0&&< 3.10.0 | 3.10.0go get github.com/projectdiscovery/nuclei/v3@v3.10.0 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
Fix
Update github.com/projectdiscovery/nuclei/v3 to 3.10.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-76803 is resolved across your whole dependency graph.
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
Is CVE-2026-76803 in your dependencies?
Find it across Go, including transitive dependencies.