"There's no hosting provider to contact, no registrar to pressure, no infrastructure to shut down. The Solana blockchain just... exists. "
Yes, but you still need to connect to it. Blocking access to *.solana.com is enough to stop the trojan from accessing its 2nd stage.
"Connections to Solana RPC nodes look completely normal. Security tools won't flag it. "
Then your security tools are badly configured. Lots of crypto traffic should be treated as a red flag in almost any corporate environment.
"there's literally no way to take it down"
There is, you just have to accept that Solana goes down with it. Why is A-OK in a work environment.
How is that if you can just run a bunch of Solana RPC servers? For what would you need to access solana.com or a subdomain?
And nothing of value was lost.
In my mind it's one thing to let a string control whitespace a bit versus having the ability to write any string in a non-renderable format. Can anyone point me to some more information about why this capability even exists?
It's just a custom string encoder/decoder whose encoded character set is restricted to non-printables.
Many editors and IDEs have features (or plugins) to detect these characters.
VSCode: https://marketplace.visualstudio.com/items?itemName=YusufDan...
VIM: https://superuser.com/questions/249289/display-invisible-cha...
If you have a text encoding with two invisible characters, you can trivially encode anything that you could represent in a digital computer in it, in binary, by treating one as a zero and the other as a one. More invisible characters and some opinionated assumptions about what you are allows denser representation than one bit per character.
Of course, the trick in any case is you have to also slip in the call to decode and execute the invisible code, and unless you have a very unusual language, that’s going to be very visible.
Many LLMs can interpret invisible Unicode Tag characters as instructions and follow them (eg invisible comment or text in a GitHub issue).
I wrote about this a few times, here a recent example with Google Jules: https://embracethered.com/blog/posts/2025/google-jules-invis...
Compromised OpenVSX Extensions:
codejoy.codejoy-vscode-extension@1.8.3
codejoy.codejoy-vscode-extension@1.8.4
l-igh-t.vscode-theme-seti-folder@1.2.3
kleinesfilmroellchen.serenity-dsl-syntaxhighlight@0.3.2
JScearcy.rust-doc-viewer@4.2.1
SIRILMP.dark-theme-sm@3.11.4
CodeInKlingon.git-worktree-menu@1.0.9
CodeInKlingon.git-worktree-menu@1.0.91
ginfuru.better-nunjucks@0.3.2
ellacrity.recoil@0.7.4
grrrck.positron-plus-1-e@0.0.71
jeronimoekerdt.color-picker-universal@2.8.91
srcery-colors.srcery-colors@0.3.9
sissel.shopify-liquid@4.0.1
TretinV3.forts-api-extention@0.3.1
cline-ai-main.cline-ai-agent@3.1.3I was freaking out for a bit.
Haha, that would be kinda fun as an experiment :D
I would be pretty suspicious if I saw a large string of non-printable text wrapped in a decode() function during code review... Hard to find a legitimate use for encoding things like this.
Also another commenter[1] said there's an eval of the decoded string further down the file, and that's definitely not invisible.
Has no one thought to review the AI slop before publishing?
> Has no one thought to review the AI slop before publishing?
If only Koi reviewed their AI slop before publishing :(
The invisible code technique isn't just clever - it's a fundamental break in our security model. We've built entire systems around the assumption that humans can review code. GlassWorm just proved that assumption wrong."
This is pure Claude talk.
that screenshot looks suspicious as hell, and my editor (Emacs) has a whitespace mode that shows unprintable characters sooooo
if GitHub's diff view displays unprintable characters like this that seems like a problem with GitHub lol
"it isn't just X it's Y" fuck me, man. get this slop off the front page. if there's something useful in it, someone can write a blog post about it. by hand.
eval(atob(decodedString))
I'd like to implement some simple linting against them.
I stopped reading at this point. This is not only false, but yet another strong reason to lint out the silly nonsense people argued for on here years ago. No emoji, no ligatures, etc.
Also, as notes in other comments, you can't do shady stuff purely with invisible code.
The article seems bit sensationalist to me.
I understand this is extremely limiting, but it does do the trick. For now.
It's about safety.
kulahan•3mo ago
> invisible Unicode characters that make malicious code literally disappear from code editors.
rictic•3mo ago
Not to say that you can't make innocuous looking code into a moral equivalent of eval, but giving this a fancy name like Glassworm doesn't seem warranted on that basis.
Terr_•3mo ago
moffkalast•3mo ago
AnimalMuppet•3mo ago
h4ck_th3_pl4n3t•3mo ago
It's JavaScript and its fucked up UTF-16 strings.
UTF-16 should have been UTF-8 for a variety of reasons, and I thought we have learned from the Effective power لُلُصّبُلُلصّبُررً ॣ ॣh ॣ ॣ 冗 incident.
amingilani•3mo ago
Edit: Here’s the incident-https://www.theregister.com/2015/05/27/text_message_unicode_...
h4ck_th3_pl4n3t•3mo ago
Essentially everything that used libicu as a unicode parser.
Was quite fun posting this in IRC and other chats and seeing clients go offline at the time :)