lru-cache 11.5.3
- Source
- https://github.com/isaacs/node-lru-cache
- Tag scanned
v11.5.3- Compared with
v11.5.2(0 signals introduced since)- Files
- 62 scanned, 7 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 0 warn · 7 info
- Scan time
- 4.9 s
- LLM review
- Reviewed by claude-haiku-5-5 (Anthropic): 6 of 6 warn and critical signals; 6 demoted to info.
- Disclude version
- 4.0.0
- Scanned (UTC)
- 2026-10-14 18:58
Signals
Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.
-
likely benign Benchmark loader that requires an LRU cache library chosen by name.
Reasoning
The require specifier is the name of a benchmark implementation taken from a local list, and the code is in a benchmark harness. This is a plugin-style loader for comparing LRU cache libraries, not an attack.
-
}likely benign Benchmark loader that requires mnemonist submodules by computed path.Reasoning
Requires of impl plus a fixed suffix select sub-modules of a benchmarked package. The specifier is derived from the benchmark's own impl name, consistent with a benchmark harness.
-
MnemonistLRUMap = MnemonistLRUCache = exports = exports =likely benign Benchmark loader that requires a second mnemonist submodule by computed path.Reasoning
Same pattern as the adjacent finding: a computed require for a benchmark library's submodule, with no network, shell, or decoding involved.
-
}likely benign Benchmark registry that requires the hashlru package by name.Reasoning
Requires the library named by impl in a benchmark implementation registry. The dynamic specifier is the expected way to load several competing packages in one benchmark.
-
}likely benign Benchmark registry that requires the lru-fast package by name.Reasoning
Requires the lru-fast package named by impl inside a benchmark registry. No suspicious behavior appears in the snippet.
-
const dir = process.env. || __dirname const caches = const num = +process.env. || 10_000 const evict = num * 2likely benign Benchmark worker that requires impls.js from a directory set by an environment variable.Reasoning
The require path comes from the __LRU_BENCH_DIR environment variable with __dirname as fallback, so it is dynamic and env-controlled. Within a benchmark worker this is a configuration convenience. Env-controlled require paths merit a note, but the code only loads the local impls.js and no payload or exfiltration is visible.
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.
&&