Defender flags the exe in a rea-tools copy of the REA repo

The incident and the checklist built on it cover different install paths. The copy's README sent readers to a downloadable Windows archive ^[8]. The DEV Community post says checks 1 and 2 alone catch the rea-tools copy, and that the other six cover the npm package a config pulls with npx, a path the copy did not take ^[3]. It reports no look-alike npm package and does not say how many of the 172 downloads were run ^[2].

So the evidence supports a narrow reading: a copied README pointing at a binary. Defender flags both the archive and the extracted exe ^[1]. Thirty-seven of the 45 VirusTotal engines did not ^[21]. A scan score is thin ground for trust at that ratio. Repository dates and publisher identity are better evidence, and the post puts it this way: "A lookalike copies the README. The dates and the publisher are harder to copy." ^[5]

Check 1 is string comparison. Take the repo and package names from the project's own README or site and compare them character by character with what is in your config ^[6]. After the issue, REA's maintainer added a line to the README saying that "a similar repository name or copied README does not establish that a download is official." ^[12]

Check 2 is the one that fits this case. The rea-tools organization was created three days before the issue was opened ^[22] and held one repository ^[9]. REA's real repo had about 145,000 stars within days, according to Kunal Ganglani on October 12, and has more than 280,000 now ^[10]. The post describes "an org created three days before you found it, holding one repo of a tool with six-figure stars" as the shape the REA issue described ^[4]. The GitHub API returns a repo's creation date, fork status and parent, and GET /orgs/{org} returns the org's created_at and public_repos count ^[13]. Because a copy pushed up as a new repository reports fork: false, the creation dates tell you more than the fork flag does ^[14].

The npm path is where the remaining checks sit. The repository field in package.json is written by the publisher, so anyone can claim any repo there ^[15]. Provenance is stronger. The latest tag, rea-agents@6.5.0 as of October 16, carries a provenance attestation and was published by GitHub Actions through trusted publishing ^[16]. That tells you which repo and workflow built the tarball ^[18]. npm's docs state the limit: provenance "does not guarantee the package has no malicious code." ^[17]

To check a package and everything it pulls in, the post installs into a scratch folder with --ignore-scripts and then runs npm audit signatures ^[19]. The flag matters because, according to npm's documentation on scripts, the preinstall, install, postinstall and prepare hooks fire on npm install -g as well ^[20].

In our view the two checks that apply to this incident are the ones with evidence behind them. The other six guard a path this copy did not take, and the ones shown cost a scratch folder and a few commands.