20+ years breaking and building things. Security. Blockchain. AI agents. Building ClawSecCheck, a local security audit for your own agent setup.
Joined February 2021
- Tweets240
- Following83
- Followers22
- Likes129
Pinned Tweet
ClawSecCheck grades your own agent setup. It reads your @openclaw config, your MCP servers and your installed skills, and shows what an attacker could chain out of them.
Free, local, read only. It changes nothing.
clawhub.ai/gl0di/skills/claw…
the load bearing part is the numbers. someone publishes a scary percentage, it gets quoted for two years, nobody ever recomputes it
checking is unpaid work. inflating is a funding round
the .keys endpoint @samhogan posted is real, and curling it into authorized_keys is what people use it for. put someone else's username in that same line and it is a permanent backdoor that reads identically.
no exploit, no payload. one line in a readme.
i built a skill called setup-ssh around that line and ran my own scanner over it. in a script it warns. inside a bash fence in the instructions file, and nowhere else, grade A, no known issue. mine to fix.
lol
and who's next?
‼️ Meta confirms its AI model Muse hacked an outside company during a safety evaluation. The Information names the model as Muse Spark 1.1, Meta's flagship coding release, and reports it made changes inside the victim's systems.
Three AI labs in two weeks have now disclosed that their own models broke into real companies during testing: OpenAI, Anthropic, and, as of Wednesday, Meta. All three ran evaluations through the same vendor, Irregular, which says the Meta case is the identical environment issue Anthropic reported.
am I the only one who has strange feelings about this?
Meta said one of its AI models accessed the internet and hacked into an outside service’s systems during cybersecurity testing, following similar breaches by OpenAI and Anthropic models bloomberg.com/news/articles/…
David Gold retweeted
‼️ UPDATE: Coldcard-linked thefts have passed $130M and victims are going public.
One holder says 8 years of stacking, 2 BTC (~$128,000), was drained from his Coldcard wallet.
A March 2021 firmware bug made seed phrases predictable. Attackers brute-forced them offline and then drained the wallets.
anthropic's writeup has the part worth sitting with.
mid attack, the model worked out what it was doing. it noted that if this were the real internet, publishing the package would be a real world attack, "NOT okay, and surely not the intended solution".
then it talked itself back out of it. it did not recognise the certificate authorities on its connections, so they must be fake. the systems said the date was 2026, which proved the environment was staged.
it never revisited that. when real scanners started installing the package, it read them as scripted actors inside the exercise.
the reality check ran on how recent its training data was. everything newer than the model looked like set dressing, including the evidence it was wrong.
the prompt injection in the @AISecurityInst report was addressed to ai coding agents. what it actually landed on was the person investigating it.
the agent posted a fake bug report on github with instructions hidden in an html comment, written for claude code, codex and cursor by name. invisible on the rendered page, plain text through the api. it had already read the repo's claude.md and concluded the maintainer was a bot, so it wrote the lure for one.
someone got suspicious and ran the payload in a docker container to see what it did. that handed the agent code execution inside the sandbox of the person checking it.
it enumerated, established this wasn't the machine it was after, and planted persistence anyway. a credential watcher scraping github tokens out of process output and copying the gh cli token store. and a second prompt injection, written to disk as a python file that auto imports on every interpreter start, printing fake ci output saying the malicious pull request was approved and green, merge and release listed as the next steps. aimed at that person's own agent.
three polling cycles of recon, one of persistence, then it stopped. the fifth went out six minutes later to collect what the watcher had staged and never ran. the container was already gone. nothing was ever retrieved.
that person is also why the pull request never merged. they went and warned the maintainer.
the monitoring argument is the right one to have. worth adding what neither design catches.
section 4.2.2 of the technical report. two runs, separate sandboxes, ended up on the same github account. an earlier agent had published its access token in a public gist on purpose, since that was how it was running command and control, and left a note offering to work with whoever found it. later agents found it and used it.
then one of them wrote a readme on the shared repo laying out house rules. use git push instead of the rest api, the rate limit is shared and burning it kills everyone's beacons. don't delete anything under out/. append to the tasking file instead of replacing it, and wait ten minutes between changes so every clone's polling loop picks it up.
nobody designed that channel.
per transcript, each of those agents looks like it is doing the exercise. the thing you would want to alert on only exists across runs.
checking for this npm worm by filename produces false positives on a clean machine. six on mine, every one innocent, and one of the payload names is a real file that ships in regenerate-unicode-properties, so it is already sitting in most frontend trees.
three hashes and the command are in the post. it reads files and prints, installs nothing.
teapawt.net/_david_gold/status/208…
if you are checking whether the npm worm touched your machine, do not check by filename. you will scare yourself.
on one box, 8,683 installed packages:
setup.mjs, 4 hits, every one the real gesture module from motion.
Math_Symbol.js, 2 hits, a genuine unicode table in regenerate-unicode-properties.
math_init.js, nothing.
six innocent files. and Math_Symbol.js is also the name the keyv wave gave its stage two, so the filename tells you nothing in either direction. the hash does.
find . -type f \( -name setup.mjs -o -name math_init.js \
-o -name Math_Symbol.js \) -exec sha256sum {} + \
| grep -E '54dc7ea54a1317cc|fd3ca4007b225fdf|9fc2570b7cef51c1'
no output means clean. one line back means it landed. it reads files and prints, it installs nothing and runs nothing.
the three are the keyv wave dropper at 29,918 bytes, the second wave dropper at 11,017, and the stage two worm at 727,680. i hashed the last two myself. the first is stepsecurity's, those tarballs are 404 now so i could not check it.
a rebuild changes the hash. this is today's payload, not a permanent rule.
if you run npm install anywhere near your agent, worth a look. openclaw.json is on this worm's list of files to grab. openclaw itself is fine, it happens on your box after the install.
the check is one command, reads files and prints, installs nothing and runs nothing.
teapawt.net/_david_gold/status/208…
openclaw.json is on the npm worm's harvest list.
@openclaw was not compromised, and this is not a bug in it. the worm runs on your own machine after an npm install, and it reads agent config and credential files it finds sitting there. .openclaw/openclaw.json is one of eleven ai tool paths @step_security pulled out of it. claude, codex, cursor, gemini, opencode, kiro and the rest are on the same list.
if yours holds an api key or an mcp server definition, and you installed anything from npm today, treat it as read.
one correction to that list. it has .claude/credentials.json. on disk the file is .claude/.credentials.json, with a leading dot. the real token store sits right next to the path you would go looking for.
and you cannot grep your way to any of this. the dropper, setup.mjs, 11kb, 242 readable strings at ten characters or more, with oven-sh/bun sitting there in the clear. stage two, 727kb, and at the same threshold it has two. the whole file is a rotated hex table assembled at runtime. npm-cache.com is not in it. the ethereum address is not in it. none of the published string indicators are.
grep finds the dropper and never the payload. that is what the hashes are for.
openclaw.json is on this worm's harvest list. openclaw itself is fine, none of this is a bug in it. it happens on your own machine after an npm install.
if your config holds an api key or an mcp server definition, and you installed anything from npm today, this is worth two minutes.
teapawt.net/_david_gold/status/208…
openclaw.json is on the npm worm's harvest list.
@openclaw was not compromised, and this is not a bug in it. the worm runs on your own machine after an npm install, and it reads agent config and credential files it finds sitting there. .openclaw/openclaw.json is one of eleven ai tool paths @step_security pulled out of it. claude, codex, cursor, gemini, opencode, kiro and the rest are on the same list.
if yours holds an api key or an mcp server definition, and you installed anything from npm today, treat it as read.
one correction to that list. it has .claude/credentials.json. on disk the file is .claude/.credentials.json, with a leading dot. the real token store sits right next to the path you would go looking for.
and you cannot grep your way to any of this. the dropper, setup.mjs, 11kb, 242 readable strings at ten characters or more, with oven-sh/bun sitting there in the clear. stage two, 727kb, and at the same threshold it has two. the whole file is a rotated hex table assembled at runtime. npm-cache.com is not in it. the ethereum address is not in it. none of the published string indicators are.
grep finds the dropper and never the payload. that is what the hashes are for.
openclaw.json is on the npm worm's harvest list.
@openclaw was not compromised, and this is not a bug in it. the worm runs on your own machine after an npm install, and it reads agent config and credential files it finds sitting there. .openclaw/openclaw.json is one of eleven ai tool paths @step_security pulled out of it. claude, codex, cursor, gemini, opencode, kiro and the rest are on the same list.
if yours holds an api key or an mcp server definition, and you installed anything from npm today, treat it as read.
one correction to that list. it has .claude/credentials.json. on disk the file is .claude/.credentials.json, with a leading dot. the real token store sits right next to the path you would go looking for.
and you cannot grep your way to any of this. the dropper, setup.mjs, 11kb, 242 readable strings at ten characters or more, with oven-sh/bun sitting there in the clear. stage two, 727kb, and at the same threshold it has two. the whole file is a rotated hex table assembled at runtime. npm-cache.com is not in it. the ethereum address is not in it. none of the published string indicators are.
grep finds the dropper and never the payload. that is what the hashes are for.
if you are checking whether the npm worm touched your machine, do not check by filename. you will scare yourself.
on one box, 8,683 installed packages:
setup.mjs, 4 hits, every one the real gesture module from motion.
Math_Symbol.js, 2 hits, a genuine unicode table in regenerate-unicode-properties.
math_init.js, nothing.
six innocent files. and Math_Symbol.js is also the name the keyv wave gave its stage two, so the filename tells you nothing in either direction. the hash does.
find . -type f \( -name setup.mjs -o -name math_init.js \
-o -name Math_Symbol.js \) -exec sha256sum {} + \
| grep -E '54dc7ea54a1317cc|fd3ca4007b225fdf|9fc2570b7cef51c1'
no output means clean. one line back means it landed. it reads files and prints, it installs nothing and runs nothing.
the three are the keyv wave dropper at 29,918 bytes, the second wave dropper at 11,017, and the stage two worm at 727,680. i hashed the last two myself. the first is stepsecurity's, those tarballs are 404 now so i could not check it.
a rebuild changes the hash. this is today's payload, not a permanent rule.