YesCaptcha assistant

AI Security Review

Evidence context: threat category none; evidence quality moderate.

YesCaptcha assistant is a Chrome extension for handling captcha challenges, published by [email protected] and installed by roughly 100,000 users. The manifest data here shows no permissions and no host permissions, and no network endpoints were extracted from the package. Whatever the extension does at runtime, nothing in this build claims access to tabs, cookies, storage or page content.

The full finding set is one item: OBfuscation-UNICODE_HEAVY-content/index.js-917, a high-severity flag on line 917 of content/index.js. There are no IoC entries, no malware signatures, no network findings, no code-smell rules, no dependency flags and no secret matches. The detection name describes a file with a high proportion of non-ASCII or escaped Unicode characters. That is what minified and bundled JavaScript looks like. Build tools such as webpack, esbuild and rollup emit non-Latin text, emoji and symbols as escape sequences, and a captcha assistant that runs on pages in many languages would carry a lot of them. The same pattern appears in the minified output of most large extensions.

The counterargument is worth stating plainly. content/index.js is a content script, and content scripts run inside every page the extension has access to. Heavy Unicode escaping is one way to hide strings from a reader. If someone wanted to smuggle a payload into this package, a content script at line 917 is a plausible address. What makes that reading unlikely is the absence of everything that normally travels with a hidden payload: no decode-then-eval chain, no string array reassembled at runtime, no call to a host outside the captcha service, no permission that would let the script read credentials or cookies. A content script that declares no host permissions cannot reach the page it runs on. A single heuristic flag with zero supporting evidence looks like scanner noise.

What would change the verdict: a network finding pointing at a domain that is not the captcha service's own API, a second obfuscation indicator in the same file, or any permission that widens what the content script can reach. None of those are present in this data. The publisher email matches the service the extension is named after, which is the pattern we would expect from the vendor's own tooling rather than a copycat.

The flag on content/index.js:917 is best explained by how the file is written. With no permissions, no endpoints and no malware or IoC matches anywhere in the package, there is no behavior here for a user to worry about.

Key Reasons

• Only finding is one obfuscation heuristic, OBfuscation-UNICODE_HEAVY-content/index.js-917, with no malware, IoC, network or code-smell findings alongside it
• Manifest declares no permissions and no host permissions, so a content script has no access to page data even if it were hostile
• Publisher email [email protected] matches the captcha service the extension is named for, with no impersonation signals
• Unicode-heavy character sets are normal in minified and bundled JavaScript content scripts

False Positive Considerations

• UNICODE_HEAVY obfuscation heuristic fires on minified and bundled JavaScript such as content/index.js
• Finding set contains nothing else to corroborate concealment: zero IoC, malware-signature, network and code-smell matches
• No decode-and-eval chain or runtime string reassembly in the same file to pair with the obfuscation flag
• Publisher identity matches the brand being served, removing the usual typosquatting signal

Reviewed 2026-10-11; recommended action: monitor; model confidence 72%.