Build1 distinct publisher3 min readPublished
A dropper committed straight into repos executes from .vscode/tasks.json the moment VS Code opens the project, and resolves its server from an Ethereum transaction. One sample sat five months.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The two hiding tricks are aimed at different readers. A file in `public/fonts/` is not opened by anyone reviewing a diff, and this one is not a font: it begins with 507 spaces where a real WOFF2 begins with the bytes `wOF2` [5]. The `postcss.config.js` is aimed at the person who does open the file. It renders as four correct lines of Tailwind plugin config and weighs 9,205 bytes, because line five runs 9,135 characters past the closing brace, mostly spaces, then payload [6]. That is about 99 percent of the file sitting off the right edge of an unwrapped pane [18]. Five months of dwell time on one sample [2], per the field guide published on dev.to, is what that buys.
Read the task flags rather than the label: `hide: true`, `reveal: never`, `echo: false`, and `runOn: folderOpen`, which is what makes the editor the trigger [3]. What it executes is `node ./public/fonts/fa-solid-400.woff2` [4]. A developer who never opens the folder in VS Code is not out of it either, because Next.js `require()`s the postcss config on every `next dev` and `next build` [7].
The loader carries no server address at all [8]. It reads the newest outbound transaction from a hardcoded wallet through Blockscout, then decodes the first eight bytes of the 20-byte destination address into a primary and a fallback IPv4 address [9]. Eight of twenty bytes used, twelve ignored [19]: there is room in that field for more than the operator currently needs. Cutting off one RPC provider does nothing, because the resolution falls through four of them [8]. And the stage-two fetch is plain HTTP pointed at port 443 [10], so an egress rule written around port numbers rather than protocols has nothing to object to.
The four suggested checks [15] have a sequencing problem worth naming. Grepping `.vscode/tasks.json` for `folderOpen` requires the clone to be on disk, which means fetch and inspect must happen before the editor is ever pointed at the directory. Once it has run, `spawn` with `detached: true` followed by `unref()` reparents the process to init, so it outlives the editor that started it [13]; quitting VS Code is not a remedy, and the `ps` check is the only one of the four that finds a live loader [15]. The wallet grep, including the history pass, catches this operator only, since deleting the file does not remove it from Git [17].
The observed payload polls the clipboard every 200 ms [14]. That is five reads a second, 18,000 an hour [20]. A token pasted once into a terminal on that machine is captured whether or not it has anything to do with the repository.
Ranked by verification strength, evidence, and original report placement.
A dropper family is being committed directly into developer repositories; it does not require npm install, and runs when the dev server starts or when VS Code opens the folder.
One sample sat in a repository for five months before anyone noticed.
The committed .vscode/tasks.json defines a shell task labelled eslint-check with hide: true, presentation reveal: never and echo: false, and runOptions runOn: folderOpen, so VS Code executes it when the folder is opened.
The task command executes node ./public/fonts/fa-solid-400.woff2.
public/fonts/fa-solid-400.woff2 begins with 507 spaces followed by JavaScript; a genuine WOFF2 file begins with the magic bytes wOF2. Disguising the payload as a binary asset keeps it out of review.
The committed postcss.config.js displays as four correct lines of Tailwind plugin config but is 9,205 bytes; line 5 is 9,135 characters long, consisting of roughly nine thousand spaces after the closing brace followed by the payload, with no wrapping or horizontal scrollbar to reveal it.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed single-source technical analysis, no external corroboration
The mechanism claims are unusually specific and internally checkable: verbatim tasks.json flags, the wOF2 magic-byte contrast, exact byte and line-length figures for postcss.config.js, the de-obfuscated address-decoding code, and a published operator wallet. That specificity is what a reader can verify against their own clones. But every claim in the cluster traces to one dev.to post by one author, with no vendor advisory, CVE, platform statement, or second outlet confirming the samples, the five-month dwell time, or the attribution to EtherHiding as used here, and no dataset behind 'observed in the wild'.
In-the-wild presence asserted, scope entirely unquantified
There is more than a proof of concept: the author reports live samples committed into repositories, at least one resident for five months, a working stage-two clipboard stealer, and a specific operator wallet usable as an indicator. But nothing quantifies spread — no affected repository or package names, no victim or infection counts, no telemetry, and no third-party sighting — so real-world footprint cannot be assessed beyond 'observed at least once'.
Mechanism justified, scale rhetoric ahead of the evidence
The framing that blocklists cannot see this is substantiated by the mechanism itself — blockchain-resolved C2 with RPC fallbacks and in-memory stage two genuinely defeats IP blocking and takedown. What runs ahead of the evidence is scale and urgency: 'a dropper family', 'developers who lost work to this', and a five-month dwell time are presented without any count, named victim, or independent confirmation, and the piece routes readers to the author's own scanner as the fix. The overstatement is modest and partly self-corrected, since the author discloses his tool's blind spots and flags folderOpen as a legitimate feature that produces false hits.
Author markets his own scanner, mitigated by disclosed limits
The post's canonical URL points to the author's own project page and the piece culminates in install instructions for 'snare', his scanner — a direct distribution interest in readers accepting that manual checking 'does not scale'. Countervailing signals: the tool is free and MIT, ships no token and uses the reader's own gh credentials, the post gives working shell commands that need no tool at all, and it explicitly states the guard polls only once per second, cannot see code already running, misses variants on other infrastructure, and that removing the malware is the actual fix.
Mechanism credible, scope and attribution unverified
Confidence is split. The technical mechanism — folderOpen task execution, whitespace-padded config, blockchain-derived C2 address, in-memory detached stage two — is described with enough precision and internal consistency that a reader can test it, and each element uses documented platform behavior. Confidence in everything surrounding it is low: one publisher, one author, no corroboration, no quantified scope, no explanation of how the files get committed in the first place, and remediation guidance that is also a product pitch.
build
Retry budgets are sized against outages, not jitter: 45 seconds lost all sixteen clips1 distinct publisher
build
A GAN beauty filter is a device budget allocation, not a feature toggle1 distinct publisher
build
Every viewer hits your HLS key endpoint in the same second, and almost nobody tests it1 distinct publisher
build
912MB to 108MB is mostly typing now, and that weakens the base-image excuse in review1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 25, 2026