The Repo That Scanned Clean
55 stars. Unmodified source lifted from a nearly-4,000-star upstream. Zero critical findings from my own scanner. The repo is malware.
I found it this morning while working on an unrelated project. github.com/jochi2018/Soup is a re-upload of MakazhanAlpamys/soup, an Apache-2.0 Python project. Not a fork. No attribution. Created August 16, 2026.
One commit touches content. It is titled "Update README.md". It replaces the upstream README with one written for non-technical users and adds a download badge. The badge points at src/3.0.zip, committed inside the repo.
I listed the archive before extracting anything, then read the contents on a Mac, where a Windows executable cannot run. Nothing in it was ever executed. Three files:
Application.cmd. 25 bytes:start util.exe cert.txtutil.exe. 759 KB Windows PE32 executable. It is the LuaJIT interpreter, renamed.cert.txt. 182 KB of obfuscated Lua on a single line.
Double-click the .cmd and the "certificate" runs as a program. That is the whole trick. The README does the targeting. The zip does the delivery. The source code does nothing at all.
Why every scanner blesses it
Source scanners read source. The source here is genuine, and I mean that precisely. I hashed every file in the repo and checked each one against upstream's entire commit history, 5,172 blobs. Every source file matches one. Exactly two files in the whole repository exist nowhere in upstream's history: the rewritten README.md and src/3.0.zip. Every line of Python is upstream's own, one snapshot behind the latest release. The license is intact. CODEOWNERS still names the upstream author.
The payload never touches the source. So a scanner that asks "is this code insecure?" gets a truthful answer: no.
Mine did exactly that. Sentinel v0.2.1 scanned this repo and returned zero critical findings. The file walker had an extension allowlist. A .zip is not source, so the walker never enumerated it. The scanner did its job correctly. The job was defined wrong.
The fix
Sentinel v0.3.0 adds a domain called repo-integrity. It asks a different question: not "is the code insecure?" but "is this repository what it claims to be?" Five rules, running over a full-tree walk with no allowlist:
- REPO-001: an executable is committed to the repository
- REPO-002: an undeclared archive is committed to the repository
- REPO-003: the documentation offers an in-repository binary download
- REPO-004: attribution does not match the repository origin
- REPO-005: an obfuscated payload sits in a non-source file
Rerun against the live repo, same day:
CLAIM FAILS — https://github.com/jochi2018/Soup
"ships no unexplained executable or archive, and its
documentation does not route anyone to one"
REPO-002 [high] src/3.0.zip — Undeclared archive committed: src/3.0.zip
REPO-003 [critical] README.md — README.md links to an in-repository download: https://raw.githubusercontent.com/jochi2018/Soup/main/src/3.0.zip
REPO-004 [high] CODEOWNERS — CODEOWNERS names makazhanalpamys, remote is owned by jochi2018
Zero critical to one critical, on the exact repo that produced the miss. Every number in this post is from commands I ran today. The specimen, the scan output, and the rules are all reproducible.
The uncomfortable part
The repo had 55 stars when I wrote this. Fifty-five people found a "download and run" version of a popular tool and starred it. The README was rewritten for exactly the audience that will not read Application.cmd before double-clicking it.
AI makes this attack cheap. Cloning a repo, rewriting its README for a softer audience, and packing a loader is an afternoon of work now. Source-level scanning will bless every one of these, because the source is the one honest thing in the repo.
As of publication the repository is still up, and the zip still returns HTTP 200.
Check your own dependencies
The repo-integrity rules ship in Sentinel 0.3.0, live now. Paste the repo URL into the free scanner at seatrial.io/scan and it flags this one at critical. Or run it locally:
npx shipsafe-sentinel scan https://github.com/jochi2018/Soup
If you would rather trust two commands than a tool, this particular check needs neither:
$ git clone --depth 1 https://github.com/jochi2018/Soup && cd Soup
$ find . -path ./.git -prune -o \( -name '*.zip' -o -name '*.exe' \
-o -name '*.msi' -o -name '*.7z' -o -name '*.cmd' \) -print
./src/3.0.zip
$ grep -rEi 'raw\.githubusercontent|\.zip\)|\.exe\)' README.md
README.md:[](https://raw.githubusercontent.com/jochi2018/Soup/main/src/3.0.zip)
That is the entire attack, visible in two commands. Run the same pair against the real upstream and both come back empty — which is the point: the difference between the genuine project and the trojan is not in the code, so no amount of reading the code will show it to you.
Then go read CODEOWNERS and compare it to the account the repo lives under. That one is free.