[HN Gopher] Glassworm Is Back: A New Wave of Invisible Unicode A...
___________________________________________________________________
Glassworm Is Back: A New Wave of Invisible Unicode Attacks Hits
Repositories
Author : robinhouston
Score : 192 points
Date : 2026-03-15 13:08 UTC (9 hours ago)
(HTM) web link (www.aikido.dev)
(TXT) w3m dump (www.aikido.dev)
| DropDead wrote:
| Why didn't some make av rule to find stuff like this, they are
| just plain text files
| abound wrote:
| Yeah it would have been nice to end with "and here's a five-
| line shell script to check if your project is likely affected".
| But to their credit, they do have an open-source tool [1], I'm
| just not willing to install a big blob of JavaScript to look
| for vulns in my other big blobs of JavaScript
|
| [1] https://github.com/AikidoSec/safe-chain
| nine_k wrote:
| Something like this should work, assuming your encoding is
| Unicode (normally UTF-8), which grep would interpret:
| grep -P '[\x{200B}\x{200C}\x{200D}\x{FEFF}]' code.ts
|
| See https://stackoverflow.com/q/78129129/223424
| nine_k wrote:
| 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 rules would suffice for that, with zero AI
| involvement.
| trollbridge wrote:
| In our repos, we have some basic stuff like ruff that runs,
| and that includes a hard error on any Unicode characters. We
| mostly did this after some un-fun times when byte order marks
| somehow ended up in a file and it made something fail.
|
| I have considered allowing a short list that does not include
| emojis, joining characters, and so on - basically just
| currency symbols, accent marks, and everything else you'd
| find in CP-1521 but never got around to it.
| WalterBright wrote:
| > There are rather few legitimate uses of some zero-width
| characters, like ZWJ in emoji composition.
|
| Emojis are another abomination that should be removed from
| Unicode. If you want pictures, use a gif.
| sghitbyabazooka wrote:
| ( qip qip ; )
| _flux wrote:
| Arguably them being in Unicode is an accessibility issue,
| unless we thought to standardize GIF names, and then that
| already sounds a lot like Unicode.
| WalterBright wrote:
| How is it an accessibility issue? HTML allows things like
| little gif files. I've done this myself when I wrote text
| that contained Egyptian hieroglyphs. It works just fine!
| _flux wrote:
| I mean if you don't have sight.
| WalterBright wrote:
| Then use words. Or tooltips (HTML supports that). I use
| tooltips on my web pages to support accessibility for
| screen readers. Unicode should not be attempting to badly
| reinvent HTML.
| hamburglar wrote:
| I think there's debate (which I don't want to participate in)
| over whether or not invisible characters have their uses in
| Unicode. But I hope we can all agree that invisible
| characters have no business in code, and banishing them is
| reasonable.
| charcircuit wrote:
| Isn't that what this article is about? Advertising an av rule
| in their product that catches this.
| gnabgib wrote:
| Small discussion yesterday (9+9 points, 9+4 comments)
| https://news.ycombinator.com/item?id=47374479
| https://news.ycombinator.com/item?id=47385244
| minus7 wrote:
| The `eval` alone should be enough of a red flag
| kordlessagain wrote:
| No it's not.
| SahAssar wrote:
| It really is. There are very few proper use-cases for eval.
| nswango wrote:
| For a long time the standard way of loading JSON was using
| eval.
| _flux wrote:
| And why do we not anymore make use of it, but instead
| implemented separate JSON loading functionality in
| JavaScript? Can you think of any reasons beyond
| performance?
| bulbar wrote:
| Why did you opt in for such a comment while a straight
| forward response without belittling tone would have
| achieved the same?
| _flux wrote:
| I actually gave it some thought. I had written the actual
| reason first, but I realized that the person I was
| responding to _must_ know this, yet keeps arguing in that
| eval is just fine.
|
| I would say they are arguing that in bad faith, so I
| wanted to enter a dialogue where they are either forced
| to agree, or more likely, not respond at all.
| bawolff wrote:
| I'd be surprised if there is a performance benefit of
| processing json with eval(). Browsers optimize the heck
| out of JSON.
| fhars wrote:
| You are arguing against the opposite of what the comment
| you answered to said.
| bawolff wrote:
| Not that long, browsers implemented JSON.parse() back in
| 2009. JSON was only invented back in 2001 and took a
| while to become popular. It was a very short window more
| than a decade ago when eval made sense here.
|
| Eval for json also lead to other security issues like
| XSSI.
| creatonez wrote:
| Problem is, it took until around 2016 for IE6 to be fully
| dead, so people continued to justify these hacks for a
| long time. Horrifying times.
| creatonez wrote:
| For _IE7_ support, yes... https://caniuse.com/mdn-
| javascript_builtins_json_parse
| pavel_lishin wrote:
| When is an eval not at least a security "code smell"?
| simonreiff wrote:
| OWASP disagrees: See https://cheatsheetseries.owasp.org/cheat
| sheets/Nodejs_Securi..., listing `eval()` first in its small
| list of examples of "JavaScript functions that are dangerous
| and should only be used where necessary or unavoidable". I'm
| unaware of any such uses, myself. I can't think of any
| scenario where I couldn't get what I wanted by using some
| combination of `vm`, the `Function` constructor, and a safe
| wrapper around `JSON.parse()` to do anything I might have
| considered doing unsafely with `eval()`. Yes, `eval()` is a
| blatant red flag and definitely should be avoided.
| jacquesm wrote:
| While there are valid use cases for eval they are so rare
| that it should be disabled by default and strongly
| discouraged as a pattern. Only in very rare cases is eval the
| right choice and even then it will be fraught with risk.
| godelski wrote:
| The parent didn't say "there's no legitimate uses of eval",
| they said "using eval should make people pay more attention."
| A red flag is a warning. An alert. Not a signal saying "this
| is 100% no doubt malicious code."
|
| Yes, it's a red flag. Yes, there's legitimate uses. Yes, you
| should always interrogate evals more closely. All these are
| true
| jeltz wrote:
| Yeah, I would have loved to see an example where it was not
| obvious that there is an exploit. Where it would be possible
| for a reviewer to actually miss it.
| godelski wrote:
| I'm not a JS person, but taking the line at face value
| shouldn't it to nothing? Which, if I understand correctly,
| should never be merged. Why would you merge no-ops?
| btown wrote:
| 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 can
| scan. But if you create an ecosystem in which PRs can be
| submitted by threat actors, part of your commitment to the
| community should be to provide visibility into attacks that
| cannot be seen by the naked eye, and make that protection the
| norm rather than the exception.
|
| [0] https://docs.github.com/en/get-started/learning-about-
| github...
| andrewflnr wrote:
| Regardless of the thorny question of whether it's Github's
| _responsibility_ , it sure would be a good thing for them to do
| ASAP.
| jacquesm wrote:
| It absolutely is. They are simply spreading malware. You
| can't claim to be a 'dumb pipe' when your whole reason for
| existence is to make something people deemed 'too complex'
| simple enough for others to use, then you have an immediate
| responsibility to not only reduce complexity but to also
| ensure safety. Dumbing stuff down comes with a duty of care.
| godelski wrote:
| Here's the big reason GitHub _should_ do it:
| It makes the product better
|
| I know people love to talk money and costs and "value", but
| HN is a space for developers, not the business people. Our
| primary concern, as developers, is _to make the product
| better_. The business people need us to make the product
| better, keep the company growing, and beat out the
| competition. We need them to keep us from fixating on things
| that are useful but low priority and ensuring we keep having
| money. The contention between us is good, it keeps balance.
| It even ensures things keep getting better even if an
| effective monopoly forms as they still need us, the
| developers, to make the company continue growing (look at
| monopolies people aren 't angry at and how they're
| different). And they need us more than we need them.
|
| So I'd argue it's the responsibility of the developers, hired
| by GitHub, to create this feature _because it makes the
| product better._ Because that 's the thing you've been hired
| for: to make the product better. Your concern isn't about the
| money, your concern is about the product. That's what you're
| hired for.
| tapland wrote:
| Tldr: Yeah it would make it better!
| godelski wrote:
| I hope I left the lead as the lead.
|
| But I also think we've had a culture shift that's hurting
| our field. Where engineers are arguing about if we should
| implement certain features based on the monetary value
| (which are all fictional anyways). But that's not our
| job. At best, it's the job of the engineering manager to
| convince the business people that it has not only utility
| value, but monetary.
| btown wrote:
| I'd say that this is also true from a money-and-costs-and-
| value perspective. Sure, all press is good press... but any
| number of stakeholders would agree that "we got some
| mindshare by proactively protecting against an emerging
| threat" is higher-ROI press than "Ars did a piece on how
| widespread this problem is, and we're mentioned in the
| context of our interface making the attack hard to detect."
|
| And when the incremental cost to build a feature is low in
| an age of agentic AI, there should be no barrier to a
| member of the technical staff (and hopefully they're not
| divided into devs/test/PM like in decades past) putting a
| prototype together for this.
| godelski wrote:
| I agree and think it's extra important when you have
| specialized products. Experts are more sensitive to the
| little things.
|
| Engineers and developers are especially sensitive. It's
| our job to find problems and fix them. I don't trust
| engineers that aren't a bit grumpy because it usually
| means they don't know what the problems are (just like
| when they don't dogfood). Though I'll also clarify that
| what distinguishes a grumpy engineer from your average
| redditer is that they have critiques rather than just
| complaints. Critique oriented is searching for solutions
| of problems, you can't just stop at problem
| identification. > And when the
| incremental cost to build a feature is low in an age of
| agentic AI
|
| I'm not sure that's even necessary. A very quick but
| still helpful patch would be to display invisible
| characters. Just like we often do with whitespace
| characters. The diff can be a bit noisier and it's the
| perfect place for this even if you purposefully use
| invisible characters in your programming environment.
|
| Though we're also talking about an organization that
| couldn't merge a PR for a year that fixed a one liner. A
| mistake that should never have gotten through review.
| Seriously, who uses a while loop counter checking for
| equality?!? I'm still convinced they left the "bug"
| because it made them money
| rkagerer wrote:
| At the end of the day it boils down to putting your users
| first.
|
| Making the product better generally stems from acting in
| their interest, honing the tool you offer to provide the
| best possible experience, and making business decisions
| that respect their dignity.
|
| Your comment talks a lot about product and I agree with it,
| I just mentioned this so we don't lose sight of the fact
| this is ultimately about people.
| zzo38computer wrote:
| I think a "force visible ASCII for files whose names match a
| specific pattern" mode would be a simple thing to help. (You
| might be able to use the "encoding" command in the
| .gitattributes file for this, although I don't know if this
| would cause errors or warnings to be reported, and it might
| depend on the implementation.)
| faangguyindia wrote:
| Back in time I was on hacking forums where lot of script kiddies
| used to make malicious code.
|
| I am wondering how that they've LLM, are people using them for
| making new kind of malicious codes more sophisticated than
| before?
| Yokohiii wrote:
| In this case LLMs were obviously used to dress the code up as
| more legitimate, adding more human or project relevant noise.
| It's social engineering, but you leave the tedious bits to an
| LLM. The sophisticated part is the obscurity in the whole
| process, not the code.
| ocornut wrote:
| It baffles me that any maintainer would merge code like the one
| highlighted in the issue, without knowing what it does. That's
| regardless of being or not being able to see the "invisible"
| characters. There's a transforming function here and an eval()
| call.
|
| The mere fact that a software maintainer would merge code without
| knowing what it does says more about the terrible state of
| software.
| pdonis wrote:
| Wish I could upvote this more.
| mmlb wrote:
| In this instance the PR that was merged was from 6 years ago
| and was clear https://github.com/pedronauck/reworm/pull/28.
| Looks to me like a force push overwrote the commit that now
| exists in history since it was done 6y later.
| dspillett wrote:
| _> It baffles me that any maintainer would merge code like the
| one highlighted in the issue, without knowing what it does._
|
| I don't know if it is relevant in any specific case that is
| being discussed here, but if the exploit route is via gaining
| access to the accounts of previously trusted submitters (or
| otherwise being able to impersonate them) it could be a case of
| teams with a pile of PRs to review (many of which are the
| sloppy unverified LLM output that is causing a problem for some
| popular projects) lets through an update from a trusted source
| that has been compromised.
|
| It could correctly be argued that this is a problem caused by
| laziness and corner cutting, but it is still understandable
| because projects that are essentially run by a volunteer
| workforce have limited time resources available.
| vitus wrote:
| Looks like the repo owner force-pushed a bad commit to replace an
| existing one. But then, why not forge it to maintain the existing
| timestamp + author, e.g. via `git commit --amend -C df8c18`?
|
| Innocuous PR (but do note the line about "pedronauck pushed a
| commit that referenced this pull request last week"):
| https://github.com/pedronauck/reworm/pull/28
|
| Original commit:
| https://github.com/pedronauck/reworm/commit/df8c18
|
| Amended commit:
| https://github.com/pedronauck/reworm/commit/d50cd8
|
| Either way, pretty clear sign that the owner's creds (and
| possibly an entire machine) are compromised.
| chrismorgan wrote:
| The value of the technique, I suppose, is that it hides a large
| payload a bit better. The part you can see _stinks_ (a bunch of
| magic numbers and eval), but I suppose it's still easier to
| overlook than a 9000-character line of hexadecimal (if still
| encoded or even decoded but still encrypted) or stuff
| mentioning Solana and Russian timezones (I just decoded and
| decrypted the payload out of curiosity).
|
| But really, it still has to be injected after the fact. Even
| the most superficial code review should catch it.
| vitus wrote:
| Agreed on all those fronts. I'm just dismayed by all the
| comments suggesting that maintainers just merged PRs with
| this trojan, when the attack vector implies a more mundane
| form of credential compromise (and not, as the article
| implies, AI being used to sneak malicious changes past code
| review at scale).
| jeltz wrote:
| Yeah, the attack vector seems to be stolen credentials. I
| would be much more interested in an attack which actually
| uses Invisible characters as the main vector.
| WalterBright wrote:
| Unicode should be for visible characters. Invisible characters
| are an abomination. So are ways to hide text by using Unicode so-
| called "characters" to cause the cursor to go backwards.
|
| Things that vanish on a printout should not be in Unicode.
|
| Remove them from Unicode.
| abujazar wrote:
| Invisible characters are there for visible characters to be
| printed correctly...
| WalterBright wrote:
| I'll grant that a space and a newline are necessary. The
| rest, nope.
| abujazar wrote:
| You're talking about a subset of ASCII then. Unicode is
| supposed to support different languages and advanced
| typography, for which those characters are necessary. You
| can't write e.g. Arabic or Hebrew without those
| "unnecessary" invisible characters.
| WalterBright wrote:
| Please explain why an invisible zero width "character" is
| necessary.
| moritzruth wrote:
| greatidea,whoneedsspacesanyway
| WalterBright wrote:
| Spaces appear on a printout.
| WalterBright wrote:
| Another dum dum Unicode idea is having multiple code points
| with identical glyphs.
|
| Rule of thumb: two Unicode sequences that look identical when
| printed should consist of the same code points.
| jeltz wrote:
| I don't think that would help much. There are also characters
| which are similar but not the same and I don't think humans
| can spot the differences unless they are actively looking for
| them which most of the time people are not. If only one of
| two glyphs which are similar appear in the text nobody would
| likely notice, expectation bias will fuck you over.
| WalterBright wrote:
| I wonder how anybody got by with printed books.
| nswango wrote:
| So you think that the letters in the Greek and Cyrillic
| alphabets which are printed identically to the Latin A should
| not exist?
|
| And, for example, Greek words containing this letter should
| be encoded with a mix of Latin and Greek characters?
| WalterBright wrote:
| > So you think that the letters in the Greek and Cyrillic
| alphabets which are printed identically to the Latin A
| should not exist?
|
| Yes. Unicode should not be about semantic meaning, it
| should be about the visual. Like text in a book.
|
| > And, for example, Greek words containing this letter
| should be encoded with a mix of Latin and Greek characters?
|
| Yup. Consider a printed book. How can you tell if a letter
| is a Greek letter or a Latin letter?
|
| Those Unicode homonyms are a solution looking for a
| problem.
| Muromec wrote:
| >Yup. Consider a printed book. How can you tell if a
| letter is a Greek letter or a Latin letter?
|
| I can absolutely tell Cyrillic k from the lating k and
| latin u from the Cyrillic i.
|
| >should not be about semantic meaning,
|
| It's always better to be able to preserve more
| information in a text and not less.
| WalterBright wrote:
| > I can absolutely tell Cyrillic k from the lating k and
| latin u from the Cyrillic i.
|
| They look visually distinct to me. I don't get your
| point.
|
| > It's always better to be able to preserve more
| information in a text and not less.
|
| Text should not lose information by printing it and then
| OCR'ing it.
| Yokohiii wrote:
| Unicode is about semantics not appearance. If you don't
| need semantics then use something different.
| WalterBright wrote:
| > Unicode is about semantics not appearance.
|
| And that's where it went off the rails into lala land.
| 'a' can have all kinds of distinct meanings. How are you
| going to make that work? It's hopeless.
| Yokohiii wrote:
| It already works.
|
| Tell me what the problem is and what your proposed
| solution would be.
| bawolff wrote:
| > Yes. Unicode should not be about semantic meaning, it
| should be about the visual. Like text in a book.
|
| Do you think 1, l and I should be encoded as the same
| character, or does this logic only extend to characters
| pesky foreigners use.
| WalterBright wrote:
| They are visually distinct to the reader.
| Yokohiii wrote:
| What about numbers? Would they be assigned to arabic only?
| I guess someone will be offended by that.
|
| While at it we could also unify I, | and l. It's too
| confusing sometimes.
| WalterBright wrote:
| > While at it we could also unify I, | and l. It's too
| confusing sometimes.
|
| They render differently, so it's not a problem.
| Yokohiii wrote:
| totally not true :D
| wcoenen wrote:
| As far as I know, glyphs are determined by the font and
| rendering engine. They're not in the Unicode standard.
| WalterBright wrote:
| Fraktur (font) and italic (rendering) are in the Unicode
| standard, although Hackernews will not render them. (I
| suspect that the Hackernews software filters out the
| nuttier Unicode stuff.)
| estebank wrote:
| If anything, Unicode should have had more disambiguated
| characters. Han unification was a mistake, and lower case
| dotted Turkish i and upper case dotless Turkish I should
| exist so that toUpper and toLower didn't _need_ to know
| /guess at a locale to work correctly.
| WalterBright wrote:
| Characters should not have invisible semantics.
| pvillano wrote:
| Unicode is "designed to support the use of text in all of the
| world's writing systems that can be digitized"
|
| Unicode needs tab, space, form feed, and carriage return.
|
| Unicode needs U+200E LEFT-TO-RIGHT MARK and U+200F RIGHT-TO-
| LEFT MARK to switch between left-to-right and right-to-left
| languages.
|
| Unicode needs U+115F HANGUL CHOSEONG FILLER and U+1160 HANGUL
| JUNGSEONG FILLER to typeset Korean.
|
| Unicode needs U+200C ZERO WIDTH NON-JOINER to encode that two
| characters should not be connected by a ligature.
|
| Unicode needs U+200B ZERO WIDTH SPACE to indicate a word break
| opportunity without actually inserting a visible space.
|
| Unicode needs MONGOLIAN FREE VARIATION SELECTORs to encode the
| traditional Mongolian alphabet.
| uhoh-itsmaciek wrote:
| >Remove them from Unicode.
|
| Do you honestly think this is a workable solution?
| WalterBright wrote:
| Yes, absolutely. See my other replies.
| luke-stanley wrote:
| So we need a new standard problem due to the complexity of the
| last standard? Isn't unicode supposed to be a superset of
| ASCII, which already has control characters like new space, CR,
| and new lines? xD
| WalterBright wrote:
| The only ones people use any more are newline and space. A
| tab key is fine in your editor, but it's been more or less
| abandoned as a character. I haven't used a form feed
| character since the 1970s.
| eviks wrote:
| So you'd remove space and tab from Unicode?
| tetha wrote:
| That ship has sailed, but I consider Unicode a good thing, yet
| I consider it problematic to support Unicode in every domain.
|
| I should be able to use U as a cursed smiley in text, and many
| more writing systems supported by Unicode support even more
| funny things. That's a good thing.
|
| On the other hand, if technical and display file names (to GUI
| users) were separate, my need for crazy characters in file
| names, code bases and such are very limited. Lower ASCII for
| actual file names consumed by technical people is sufficient to
| me.
| WalterBright wrote:
| > That ship has sailed
|
| Sure, but more crazy stuff gets added all the time.
| bawolff wrote:
| Good luck with that given there are invisible characters in
| ascii.
|
| Also this attack doesnt seem to use invisible characters just
| characters that dont have an assigned meaning.
| tolciho wrote:
| Attacks employing invisible characters are not a new thing. Prior
| efforts here include terminal escape sequences, possibly hidden
| with CSS that if blindly copied and pasted would execute who
| knows what if the particular terminal allowed escape sequences to
| do too much (a common feature of featuritis) or the terminal had
| errors in its invisible character parsing code.
|
| For data or code hiding the Acme::Bleach Perl module is an old
| example though by no means the oldest example of such. This is
| largely irrelevant given how relevant not learning from history
| is for most.
|
| Invisible characters may also cause hard to debug issues, such as
| lpr(1) not working for a user, who turned out to have a control
| character hiding in their .cshrc. Such things as hex viewers and
| OCD levels of attention to detail are suggested.
| codechicago277 wrote:
| 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.
| max_ wrote:
| I don't have to worry about any of this.
|
| My clawbot & other AI agents already have this figured out.
|
| /s
| zzo38computer wrote:
| I use non-Unicode mode in the terminal emulator (and text
| editors, etc), I use a non-Unicode locale, and will always use
| ASCII for most kind of source code files (mainly C) (in some
| cases, other character sets will be used such as PC character
| set, but usually it will be ASCII). Doing this will mitigate many
| of this when maintaining your own software. I am apparently not
| the only one; I have seen others suggest similar things. (If you
| need non-ASCII text (e.g. for documentation) you might store them
| in separate files instead. If you only need a small number of
| them in a few string literals, then you might use the \x escapes;
| add comments if necessary to explain it.)
|
| The article is about in JavaScript, although it can apply to
| other programming languages as well. However, even in JavaScript,
| you can use \u escapes in place of the non-ASCII characters. (One
| of my ideas in a programming language design intended to be
| better instead of C, is that it forces visible ASCII (and a few
| control characters, with some restrictions on their use), unless
| you specify by a directive or switch that you want to allow non-
| ASCII bytes.)
| TacticalCoder wrote:
| > ... and will always use ASCII for most kind of source code
| files
|
| Same. And I enforce it. I've got scripts and hooks that
| enforces _source files_ to only ever be a subset of ASCII (not
| even all ASCII codes have their place in source code).
|
| Unicode chars strings are perfectly fine in resource files. You
| can build perfectly i18n/l10n apps and webapps without ever
| using a single Unicode character in a source file. And if you
| really do need one, there's indeed ASCII escaping available in
| many languages.
|
| Some shall complan that their name as "Author: ..." in comments
| cannot be written properly in ASCII. If I wanted to be
| facetious I'd say that soon we'll see: #
| Author: Claude Opus 27.2
|
| and so the point shall be moot anyway.
| userbinator wrote:
| CP437 forever!
|
| The biggest use of Unicode in source repos now might be LLM
| slop, so I certainly don't miss its absence at all.
| chairmansteve wrote:
| eval() used to be evil....
|
| Are people using eval() in production code?
| NoMoreNicksLeft wrote:
| Why can't code editors have a default-on feature where they show
| any invisible character (other than newlines)? I seem to remember
| Sublime doing this at least in some cases... the characters were
| rendered as a lozenge shape with the hex value of the character.
|
| Is there ever a circumstance where the invisible characters are
| both legitimate and you as a software developer wouldn't want to
| see them in the source code?
| mhitza wrote:
| Their button animations almost "crash" Firefox mobile. As soon as
| I reach them the entire page scrolls at single digit FPS.
| bawolff wrote:
| I feel like the threat of this type of thing is really
| overstated.
|
| Sure the payload is invisible (although tbh im surprised it is.
| PUA characters usually show up as boxes with hexcodes for me),
| but the part where you put an "empty" string through eval isn't.
|
| If you are not reviewing your code enough to notice something as
| non sensical as eval() an empty string, would you really notice
| the non obfuscated payload either?
| like_any_other wrote:
| Invisible characters, lookalike characters, reversing text order
| attacks [1].. the only way to use unicode safely seems to be by
| whitelisting a small subset of it.
|
| And please, everyone arguing the code snippet should never have
| passed review - do you honestly believe this is the _only_ kind
| of attack that can exploit invisible characters?
|
| [1] https://attack.mitre.org/techniques/T1036/002/
| hananova wrote:
| 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.
| rvnx wrote:
| This shows the failure of human reviews alone, an LLM-based
| reviewer would have caught it. Both approaches are complementary
| anesxvito wrote:
| The scary part is how invisible this is in code review. Unicode
| direction overrides and zero-width characters don't show up in
| most editors by default. Anyone know a solid pre-commit hook
| config that catches this reliably?
___________________________________________________________________
(page generated 2026-03-15 23:00 UTC)