fdir 6.5.0
- Source
- https://github.com/thecodrr/fdir
- Tag scanned
v6.5.0- Compared with
v6.4.6(0 signals introduced since)- Files
- 35 scanned, 11 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 0 warn · 2 info
- Scan time
- 3.9 s
- LLM review
- Reviewed by claude-haiku-5-5 (Anthropic): 2 of 2 warn and critical signals; 2 demoted to info.
- Disclude version
- 4.0.0
- Scanned (UTC)
- 2026-10-14 19:34
Signals
Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.
-
const normalized = ; const = ; ; }likely benign A benchmark script dynamically requires a versioned fdir package based on a normalized version string.Reasoning
This is a benchmark script that loads different published versions of the fdir package by building the module name from a version string passed through normalizeVersion. The specifier comes from a fixed, developer-controlled list of versions, not from external input, and the loaded module is the fdir library being benchmarked. The non-literal require is a common way to compare versions, so this looks like a legitimate pattern. The remaining doubt is that the snippet does not show where the version values originate.
-
const normalized = ; const = await ; return ...; }likely benign A benchmark function dynamically imports a versioned fdir package chosen from a fixed version list and runs a crawl.Reasoning
This is the ESM counterpart of the same benchmark pattern: await import() of fdir with a version suffix taken from a hardcoded versions array (versions[3]) and normalized. The module being loaded is the fdir library under test, and the crawl targets node_modules, which is consistent with a benchmark. No attacker-controlled input or encoded payload is involved, so this is a benign dynamic import.
Reproduce This Scan
Run disclude locally to verify. Add --format sarif for SARIF output. Add --llm (with an API key in the environment) to include the LLM review.
&&