How to Verify and Sandbox a Trending Agent Repo Like REA Before You Install It

A repo you've never heard of hits 200,000 stars in a week. Your feed tells you to run one npx command and hand it to your coding agent. That's exactly the shape of a supply-chain attack, and it's also the shape of plenty of legitimate projects. The skill is telling them apart quickly, then running the thing so a mistake costs you a disposable box instead of your SSH keys.

REA ("Reverse Engineer Anything", morluto/rea) is the case study here because it combines everything risky: viral growth, a one-line installer that edits your agent's config, and a job (opening untrusted binaries) that attracts bad actors. This post is about the method. I did not install REA for this post; I read its public docs on 2026-10-23.

What is actually known about the "fake trojan copy" of REA?

Less than the headlines imply. Here is the chain of evidence as far as I could check.

• A fact-check article on pasqualepillitteri.it (published in many languages) says a fake copy of the repo distributed malware, that Microsoft Defender classified the archive and executable as Wacatac trojans, and that 8 of 45 engines on VirusTotal flagged it as a dropper. I got these details from a search-engine summary of the article. The page itself returned an HTTP 502 when I fetched it, so I haven't read it. Treat it as single-sourced and unconfirmed by me.
• The official README on github.com/morluto/rea, which I did fetch, says to get REA from github.com/morluto/rea, rea.tools or the rea-agents npm package, and that "a similar repository name or copied README does not establish that a download is official." That wording is consistent with the story but doesn't prove it.
• Star counts in the press range widely. The same fact-check reportedly cites 234,477 stars on 14 October. The GitHub page I fetched on 2026-10-23 reported about 370.5k stars and 92.8k forks. I couldn't read the API (HTTP 403), so I can't give you a history.

The lesson doesn't depend on the fake being proven. When a repo goes viral, clones with the same name, README and logo appear within hours, often with a binary release attached, and search results and social posts link to whichever one ranks. Verify the source before you run anything.

How do I confirm I have the official repo?

Work through these in order. Each takes a minute.

1. Start from the maintainer's own pointer. Open the project's site or the npm page and follow its link to GitHub, rather than a search result or a post. For REA, the README lists three official sources, so cross-check them against each other.
2. Match the identity three ways. The GitHub owner (morluto), the npm package's repository field (the registry shows git+https://github.com/morluto/rea.git) and the npm maintainer name (morluto) should agree. Mismatches are a stop sign.
3. Read the history, not the badge. Stars and forks can be bought or manufactured, and a copy can display them too. Look at commit history age, number of contributors, issue discussion, and whether the account has older, unrelated work. The REA page I read listed 4,487 commits on main, though I can't say how that compares with a clone.
4. Check releases and signatures. The REA Releases section was empty when I fetched it, so there are no release artefacts or signatures to verify there. Be suspicious of any "release" zip or .exe for a project that distributes through npm. If a project does publish signed releases or checksums, verify them against a key published on the project's own site.
5. Check the npm page. Look at publisher, version history and weekly downloads. A brand-new package with a name one letter off from a famous one is a typosquat pattern. Install by exact name, copied from the official README.
6. Search for the exact package name plus "malware". Quick, imperfect, free.

How do I check install scripts before running npx?

npx downloads and executes code in one step. Break that apart:

npm view rea-agents version maintainers repository.url scripts dist.tarball

That prints the latest version, who can publish it, where it claims to live and the declared lifecycle scripts, without installing anything. Then download the tarball without running it, into a scratch folder:

npm pack rea-agents --pack-destination /tmp/inspect

Unpack it and read package.json and any script files the lifecycle hooks call. In the registry data I read for rea-agents, an older version (2.5.0) had a postinstall that runs node scripts/prepare-node-pty.mjs, and a later one (3.0.0) used prepare and prepack hooks. The latest tag was 6.7.0 and the registry response was truncated, so I did not read its scripts. A native-module helper like node-pty is a normal reason for a postinstall, which is exactly why you read the script instead of reacting to the word.

What you're looking for in any hook: network calls to unfamiliar hosts, reads of ~/.ssh, ~/.aws or browser profile paths, base64 blobs, eval, or writes outside the package folder. Also run npm install --ignore-scripts when you only need to inspect. Remember this is a filter. A package can behave on install and misbehave on first run, and dependencies bring their own hooks.

Also read what setup changes. The README says npx rea-agents setup shows the proposed changes, backs up existing configuration and adds an MCP server entry and workflow instructions to your agent. Review that diff. It is the permission grant that matters.

Where should I run it?

On a machine that has nothing worth stealing.

Best: a throwaway VM. A local VM (VirtualBox, UTM, KVM) costs nothing and can be reset from a snapshot. Create a fresh Linux guest, with no shared folders, no clipboard sync, and no copy of your home directory. Take a snapshot before you install. Revert after the session.

Good: a cheap rented box. If you'd rather not load your laptop, a small cloud VPS you delete afterwards works. Hostinger KVM 2 is one affordable option I've written about, and its isolation is a real separate machine, but the free local VM does the same job for most people. See our VPS hardening checklist for basic SSH and firewall settings.

Acceptable: a container. Fine for a first look, weaker for hostile code since it shares the host kernel. Run it as a non-root user, read-only root filesystem where possible, and no mounted home directory.

Whatever you choose:

• No credentials. No SSH keys, cloud CLIs logged in, browser profiles, .env files or personal API keys. Create a fresh, low-limit model API key just for the session and revoke it after.
• Fresh agent profile. REA's own SECURITY.md says it is not a sandbox and that targets are parsed by local providers (Hopper or Ghidra) with your user's permissions. A separate OS user or VM is a reasonable inference from that.
• Untrusted samples stay inside. If you're opening unknown binaries, that is a separate hazard from the tool itself. The project's DISCLAIMER.md says untrusted targets should be run in a suitable isolated environment.

How do I limit network egress?

Default deny, then allow only what the session needs.

1. Do all downloads first (the package, Ghidra, the model CLI), then cut the network if the analysis is static-only.
2. If the agent needs a model API, allow outbound HTTPS to that one provider's hostname and nothing else. On a Linux guest, an nftables or ufw rule set with default-deny outbound and explicit allows does this; the VM's host firewall works too.
3. Log DNS and connection attempts. A static analysis tool that tries to reach a random domain is telling you something.
4. Keep inbound closed. No exposed ports on the guest.

Remember that the model provider still receives whatever the agent sends it. The REA README says analysis runs locally, but also that the agent's model provider has its own data policy. Don't send binaries or logs you aren't allowed to share.

How do I give the MCP server least privilege?

Local MCP servers run with your user's privileges, so reduce what that user can reach. The details are in our MCP server security checklist; the short version for a tool like REA:

• Configure it for one project or profile, not globally across everything your agent opens.
• Prefer per-call confirmation in your client for tools that execute code. REA's docs say it has no per-call approval flags of its own and that tool annotations such as destructiveHint are hints, so your client's prompts are the real gate. Its runtime capture tools (process, browser, Electron scenarios) execute foreign code.
• Start with static tools only. Add runtime capture later, inside the VM.
• Pin the version you reviewed rather than @latest, and re-review before updating.
• Treat text returned from a target as hostile. REA tags such results as untrusted content, which helps, but the agent and you are still the decision makers. See prompt injection for tool-using agents.

A reusable checklist

• Reached the repo from the maintainer's own link, not a search result
• GitHub owner, npm maintainer and package repository field agree
• Looked at history and contributors, not only stars and forks
• Ran npm view and npm pack, and read the lifecycle scripts
• Read the diff that setup proposes for my agent config
• Running in a disposable VM or container with a snapshot
• No keys, tokens, browser profiles or personal files in the environment
• Outbound network restricted to the one provider I need
• Version pinned, runtime-execution tools set to ask first
• Revoked the temporary API key and reverted the VM afterwards

If you're running an agent against a paid model API for this kind of work, AICredits lets you top up in rupees via UPI, which makes a small throwaway-key budget easy.

Disclosure: the Hostinger and AICredits links are affiliate links.

Sources checked

• REA README, DISCLAIMER.md, SECURITY.md and docs/mcp-contracts.md, github.com/morluto/rea, fetched 2026-10-23.
• npm registry entry for rea-agents, fetched 2026-10-23 (truncated response).
• Fact-check on pasqualepillitteri.it, via search summary only on 2026-10-23, as explained above.