ProjectDiscovery Nuclei EUVD-2026-80901

Requires: (1) local write access to Nuclei's on-disk templates so the attacker can replace file contents and reset mtime via a Chtimes-style call; (2) the target template must have been previously signature-verified and cached (IndexVersion 1 metadata keyed on ModTime); (3) Nuclei must run against the tampered template with signature verification active (the default, DisableUnsignedTemplates=false), using the javascript/code protocol that executes OS commands; and (4) a victim actually invoking a scan (UI:P). Limiting factors: this is NOT remotely exploitable - an attacker with no local file access cannot trigger it, and templates that were never cached as verified are re-checked normally. Upgrading to 3.11.1 (which binds cache reuse to a content digest) fully mitigates.

This is a genuine but access-gated supply-chain integrity flaw, not a remotely-wormable emergency. The vendor CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H = 7.0) is internally consistent with the description: exploitation is LOCAL (an attacker must be able to rewrite template files on disk and reset their mtime), requires some existing privilege/foothold (PR:L), and is PASSIVE on the victim's side (UI:P - the victim must run Nuclei against the tampered template). The CWE-347 (improper signature verification) root cause is confirmed by the patch diff, which adds a ContentDigest and VerifierFingerprint to the cache metadata so verification is bound to content rather than modification time alone. No EPSS score, no CISA KEV entry, and no public POC were provided; VulnCheck published an advisory and the fix commit is public, but exploitation status is 'no public exploit identified at time of analysis.' The high VC/VI/VA (arbitrary OS command execution via the javascript/code protocol) is the reason the score is elevated despite local-only access. Net: a real fix-worthy trust-model bug for anyone caching verified templates in a shared or attacker-writable location, but not a mass-exploitation priority - the requirement for local file write plus a subsequent Nuclei run makes it targeted rather than widespread.

An attacker who can write to Nuclei's template directory (e.g., a shared CI runner, a compromised low-priv account, or a poisoned template repo synced to disk) waits until a legitimate signed template has been verified and cached, then overwrites that file with malicious javascript/code-protocol content and uses os.Chtimes to restore the original modification time. Because Nuclei's cache keyed verification solely on mtime, the next scan reuses the stale 'verified' result and executes the attacker's OS commands. No public exploit code is identified, but the VulnCheck advisory and the fix commit's regression test demonstrate the mechanism precisely.