MAL-LOADER Fetch-to-Eval Remote Code Load
Source that downloads code and then runs it. The first stage that ships in the repository is deliberately thin so it looks harmless in review, while the real payload is fetched from a host the author controls at run time. Because the second stage lives off-repo, reading the clone byte for byte cannot show what actually runs.
What Vulkro detects
MAL-LOADER-001 fires when a fetch token and an execution-sink token fall within a small window of source lines in the same file. Both on the same line is the direct nested eval(fetch(...)) shape and reads as the strongest case; a few lines apart is the download-then-run variant.
Shapes covered across JS/TS and Python include eval(await (await fetch(url)).text()), a new Function(res.data) fed by a fetch a few lines up, child_process.execSync(downloaded) after a curl / wget / fetch, Python exec(requests.get(url).text), pickle.loads(requests.get(...).content), and download-to-tempfile-then-execute.
What this does not claim: it is not dataflow. It does not prove the downloaded bytes reach the sink, only that a fetch and an execution sink are present and adjacent. A lone fetch (an ordinary API client) or a lone eval (config templating) must not fire here. It never certifies code safe.
Remediation. Do not run the repository until you have fetched the remote URL yourself, out of band, and read what it serves. Replace runtime code download with a pinned, integrity-checked dependency so the bytes that execute are the bytes that were reviewed.
See also
- Confidence model - what
High,Medium, andLowmean for findings in this category. - Safety - what Vulkro does and does not access on your machine.
References
This page is generated by vulkro rules export <out-dir> from Vulkro's built-in detector catalogue. Edits made by hand are overwritten on the next regeneration.