First Self-Propagating Worm Using Invisible Code Hits Openvsx and vs Code
Posted2 months agoActive2 months ago
koi.aiTechstory
skepticalmixed
Debate
80/100
Code SecurityMalwareIde Extensions
Key topics
Code Security
Malware
Ide Extensions
A new self-propagating worm using invisible Unicode characters has been discovered in VS Code and OpenVSX extensions, sparking discussion on code review and security practices.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1h
Peak period
53
0-6h
Avg / period
11.8
Comment distribution59 data points
Loading chart...
Based on 59 loaded comments
Key moments
- 01Story posted
Oct 20, 2025 at 3:05 PM EDT
2 months ago
Step 01 - 02First comment
Oct 20, 2025 at 4:35 PM EDT
1h after posting
Step 02 - 03Peak activity
53 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 24, 2025 at 2:23 AM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45647853Type: storyLast synced: 11/20/2025, 2:24:16 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
> invisible Unicode characters that make malicious code literally disappear from code editors.
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.
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.
Edit: Here’s the incident-https://www.theregister.com/2015/05/27/text_message_unicode_...
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 :)
"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.
And nothing of value was lost.
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?
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?
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...
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...
Compromised OpenVSX Extensions:
Compromised Microsoft VSCode Extensions:I 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?
[1] https://news.ycombinator.com/item?id=45649224
> 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.
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.
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.
I'd like to implement some simple linting against them.
[0] https://secureannex.com/