Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Glassworm is back: A new wave of invisible Unicode attacks hits repositories

aikido.dev

Post reply on HN
Print view View original

171–180 of 201 posts

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#171

Post by globular-toast »

RVuRnvbM2e wrote: post #165
nstart wrote: post #157

I don't quite understand how this is working tbh. I looked at one of the affected repos, ironically named "reworm". The malicious code was introduced in this commit - https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6... It says coauthored by dependabot and refers to a PR opened in 2020 ( https://github.com/pedronauck/reworm/pull/28 ). That PR itself was merged in 2020 here - https://github.com/pedronauck/r…

Someone has maintainer/admin access to the repository and has force-pushed to master overwriting the git history. Notice that the original commit is verified: https://github.com/pedronauck/reworm/commit/df8c1803c519f599... While the malicious one is not: https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6...

This reveals a deeper flaw in the whole git/npm pipeline (would apply to other systems like PyPI etc, not npm exclusively). These systems should operate on a "pull" model, not a push. The system should have rejected a build that wasn't derived from the latest in its repository. It would be quite easy in concept to set up one's own system to pull every source on npm and alert when the upstream has deviated.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#172

Post by _flux »

bawolff wrote: post #161
fhars wrote: post #100

Earlier quoted context omitted.

You are arguing against the opposite of what the comment you answered to said.

Am i? "Can you think of any reasons beyond performance?" implies that the comment author thinks performance would be a valid reason.

Quoting my original message:

> And why do we not anymore make use of it, but instead implemented separate JSON loading functionality in JavaScript?

In other words: I'm asking for reasons why was native JSON JavaScript module created, if we already had eval.

> Can you think of any reasons beyond performance?

One of the reasons is that native JSON parser is faster than eval: give some other reason.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#173

Post by athrowaway3z »

btown wrote: post #8

IMO while the bar is high to say "it's the responsibility of the repository operator itself to guard against a certain class of attack" - I think this qualifies. The same way GitHub provides Secret Scanning [0], it should alert upon spans of zero-width characters that are not used in a linguistically standard way (don't need an LLM for this, just n-tuples). Sure, third-party services like the OP can provide bots that…

For some reason I was under the impression this was already the default.

I first heard about the possibility of this kind of attack >10 years ago, and I'll sometimes do a xxd if i'm feeling a bit paranoid.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#174

Post by rhysfonixone »

rvnx wrote: post #115

This shows the failure of human reviews alone, an LLM-based reviewer would have caught it. Both approaches are complementary

Exactly this. I think a hybrid approach is going to be mandatory before long, if it's not already. A well-prompted frontier-lab LLM would catch things like this easily.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#175

Post by hananova »

krior wrote: post #138
hananova wrote: post #89

My hot take is that all programming languages should go back to only accepting source code saved in 7-bit ASCII. With perhaps an exception for comments.

Yeah, fuck those non-english-speaking peasants /s.

I'm a non-english-speaking peasant. I code in English, because it's the lingua franca of coding, and because they form the only characters that you can reliably use everywhere.

Besides, that's why the ban only extends to syntax and string literals (use escapes instead), and not comments.

From my experience, the only two nationalities that insist on mixing their native languages with the mostly English syntax of programming languages are the French and the Japanese. And they can just suck it up for the other 8 billion of us.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#176

Post by OJFord »

mmsc wrote: post #124

GitHub advertises itself as warning about those Unicode characters: https://github.blog/changelog/2025-05-01-github-now-provides... Of course, it doesn't work though. I reported this to their bug bounty, they paid me a bounty, and told me "we won't be fixing it": https://joshua.hu/2025-bug-bounty-stories-fail#githubs-utf-f... The exact quote is "Thanks for the submission! We have reviewed your report and validated yo…

That's bizarre. They won't be fixing it, and yet the changelog post is unretracted.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#177

Post by OJFord »

btown wrote: post #8

IMO while the bar is high to say "it's the responsibility of the repository operator itself to guard against a certain class of attack" - I think this qualifies. The same way GitHub provides Secret Scanning [0], it should alert upon spans of zero-width characters that are not used in a linguistically standard way (don't need an LLM for this, just n-tuples). Sure, third-party services like the OP can provide bots that…

They advertise that they do do it, they just don't/it doesn't work.

See commenter on their 2025 bounty for reporting it, won't-fix resolution: https://news.ycombinator.com/item?id=47393393

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#179

Post by hrmtst93837 »

nine_k wrote: post #6
DropDead wrote: post #2

Why didn't some make av rule to find stuff like this, they are just plain text files

The rule must be very simple: any occurrence of `eval()` should be a BIG RED FLAG. It should be handled like a live bomb, which it is. Then, any appearance of unprintable characters should also be flagged. There are rather few legitimate uses of some zero-width characters, like ZWJ in emoji composition. Ideally all such characters should be inserted as \xNNNN escape sequences, and not literal characters. Simple lint…

[flagged]

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#180

Post by ancillary »

codechicago277 wrote: post #41

I wonder if this could be used for prompt injection, if you copy and paste the seemingly empty string into an LLM does it understand? Maybe the affect Unicode characters aren’t tokenized.

There's at least one paper (though pretty recent) about it: https://arxiv.org/html/2603.00164v1
Post reply on HN