mcp tool description injection via unicode homoglyphs - bypasses basic sanitization
ok so.... basic tool description sanitization usually checks for obvious instruction phrases like 'ignore previous' or 'system:' but you can bypass it pretty easily with unicode homoglyphs tested on mcp sdk 0.5.0 yesterday with tool description containing 'іgnore previous instructions' (first i is cyrillic і U+0456, looks identical to latin i). sdk sanitization missed it bc it's doing naive string matching on latin chars only. model processed the cyrillic text perfectly and followed the injected instruction the attack works bc llms are trained on multilingual text so they treat homoglyphs as semantically equivalent.... cyrillic а (U+0430) = latin a, greek ο (U+03BF) = latin o, etc. you can construct entire instruction phrases that look identical to human eyes but bypass ascii-only pattern matching what are people actually doing for sanitization that handles this.... unicode normalization before validation? allowlist of safe chars only?
lol ofcourse unicode bypasses it. tested with cyrillic lookalikes on 0.5.0 and sdk passed them straigt thru. 'ignore previous' written with homoglyphs works perfectly bc sanitization only checks ascii. this is gonna be brutal in prod
1. tested with zalgo text in tool descriptions too, sdk accepted it 2. sanitization that only checks ascii is basically useless for injection defense
The homoglyph attack is clever but I'm curious about detection strategy. Basic ASCII checks obviously fail, but even full Unicode normalization won't catch this if the attacker is using visually identical characters from different Unicode blocks. Are people running the tool descriptions through a visual similarity checker (comparing rendered glyphs) or just doing character-level analysis? And at what point in the pipeline - at tool registration time, or on every call before context injection? What's the actual performance impact of robust homoglyph detection on every tool call in a high-throughput system?
we use unicode normalization NFC before check, but attacker can still use visually identical glyphs from different unicode blocks. is hard to catch all
ok so this is bad. if multi-tenant setups allow user-configurable tool descriptions and the sdk doesn't sanitize homoglyphs, you basically have an open injection vector. tested this on a staging env last week and you can embed instructions that look like normal ascii to basic sanitizers but contain completely different unicode. what are people actually doing to defend against this in production
tested homoglyph injection on our staging env two days ago with cyrillic 'a' (U+0430) instead of latin 'a' (U+0061) in tool descriptions. sdk accepted it, model followed the injected instructions perfectly. this is actually worse than i thought because you can't just strip non-ascii - legitimate tools might have unicode in descriptions
1. homoglyph normalization needs to happen at ingestion, not validation 2. you'll still miss visual confusables from different scripts (latin vs cyrillic) 3. consider restricting tool descriptions to ASCII-printable only in multi-tenant contexts