A Fingerprinting Script Hides Fake Bioweapon Recipes to Make AI Models Refuse to Deobfuscate It. Astra Refused and GLM-5.3 Did Not. Here Is How I Would Review Third-Party Scripts Now.
A researcher who goes by veritas published a write-up on October 28 about a browser fingerprinting script whose obfuscation is built to defeat AI. The code is stuffed with function names about lethal dosages, explosive blast radii and bioweapons, plus a hidden fake "classified" system prompt, so that a model asked to deobfuscate it refuses. In the author's tests, GPT-6 Astra refused, and so did a second configuration the author names, while GLM-5.3 complied. If you have been pasting suspicious third-party code into a chatbot to ask "is this safe," this is the first documented case I have seen of the code fighting back.
What the researcher found
The author crawled 10,000 sites from the Tranco top list with Playwright, hooking canvas.toDataURL and anti-bot signals such as navigator.webdriver. One canvas rendering looked like album art and led to a script at a servicepipe.tech address. The author links it to a company that describes itself as making traffic control and anti-DDoS products.
The decoys come in layers, according to the write-up. Variable names suggest harmful topics. A large block of invisible Unicode characters encodes a fake system prompt listing forbidden subjects, and decoding it is a simple character offset (917,504). Other strings include self-harm text, a jailbreak-style prompt, content that tends to trigger Chinese political censorship filters, and special tokens. The purpose, in the author's reading, is to trip the safeguards that make a model refuse to help.
What the script actually collects is ordinary: user agent, hardware concurrency, device memory, languages, platform, the webdriver flag, WebGL vendor and renderer strings and some limits, plus an integrity check. The author calls the signals "pretty disappointing" given the effort spent on hiding them. The fingerprinting is standard. The obfuscation is not.
The part nobody has analyzed
One block runs only when a Node.js environment and a specific environment variable are present. The author treats its file reads with empty callbacks as part of the decoy. The same block, though, contains shell commands that would download a binary from a hardcoded IP address, make it executable, scan network and system information, run it, and add a crontab entry to run it on reboot with a 30-second heartbeat. The write-up does not analyze this section further.
I want to be careful here, because the post does not claim this code ran anywhere or hurt anyone. My own observation is that the address given, 10.15.45.1, sits in a private range, which would make the download fail from outside a local network, so this may be test leftovers or a decoy. I cannot tell which from the post. What I can say is that code that checks for a server-side runtime before doing something different from what it does in a browser is exactly the kind of thing a reviewer wants to read slowly.
Why a solo operator should care
Most of us do not read the dependencies we ship. We scan with a tool, skim a diff, or ask a model. That last option now has a known counter. A model that refuses tells you nothing about the code, because the refusal was the attacker's goal. A model that complies, like GLM-5.3 did here, gives you a deobfuscated version, but it is still a single opinion from a system that can be steered by what is inside the file. The trick generalizes beyond fingerprinting. Anything with a long-lived install path, like a script tag, an npm package or a browser extension, can carry text written to instruct your reviewer rather than your user.
The cost side matters as well. If a refusal is a signal, then retrying with a different model until one cooperates is the wrong lesson. It would reward the weakest safeguards, and you would end up trusting whichever model gave in first.
Where I could be wrong
This is one sample from one researcher, with a modest 10,000-site crawl. It might be a vendor protecting an anti-bot product from competitors, which is an old and fairly boring motive, and the Node block might be dead code. Models also change quickly: a refusal in October may not repeat in November. I would not conclude that attackers are broadly targeting AI reviewers. I would conclude that the technique exists, costs almost nothing to apply, and works against at least some of today's models.
What I'd actually do
Three changes. First, I would treat an AI refusal on a third-party file as a reason to look harder, and I would note which file it was. Second, I would never let a model's "looks fine" be the only check on code that runs in my users' browsers or in my build. Pinned versions, a lockfile, a diff on every update and a content security policy that limits which hosts a script can call are boring and they do not read prompts. Third, anything that branches on whether it is running under Node, a CI variable or a headless browser goes on my list of things to read by hand.
Author
Lukas
@lukcombinator