AdGuard AdBlocker (Beta)

AI Security Review

Evidence context: threat category none; evidence quality moderate.

AdGuard AdBlocker (Beta) 5.5.2.56 ships under the developer contact [email protected], an identity matching the long-standing AdGuard ad-blocking product line. The manifest scan lists no host permissions and no API permissions, which matters because an ad blocker without declared host permissions works through content scripts and blocking rules rather than blanket site access.

Every network finding traces into shipped library code: vendors/tswebextension.js:31818, pages/popup.js:26766, shared/editor.js:4217, shared/editor.js:11525, vendors/xstate.js:678 and pages/options.js:18837. tswebextension and tsurlfilter form AdGuard's own filtering engine, and xstate is a general-purpose state machine library. A filter engine that blocks ads on Facebook and YouTube has to observe requests and refresh filter lists, so fetch and XMLHttpRequest calls in these files describe the product's core function. The finding at web-accessible-resources/redirects/google-ima3-dai.js:637 matches scriptlet injection, a standard ad-blocking technique where the extension substitutes a stub for a Google ad SDK instead of loading it.

No malware signature matched, and the IoC extractor surfaced nothing. The obfuscation bucket has no malware behind it. OBFUSCATION-UNICODE_HEAVY-vendors/tswebextension.js-3229, OBFUSCATION-UNICODE_HEAVY-vendors/tsurlfilter.js-644 and OBFUSCATION-UNICODE_HEAVY-pages/background.js-20636 fire on files carrying filter syntax and non-Latin rule text. OBFUSCATION-INVISIBLE_ZERO_WIDTH-filters/filters_i18n.json-0, OBFUSCATION-INVISIBLE_ZERO_WIDTH-filters/declarative/ruleset_6/ruleset_6.json-0 and OBFUSCATION-INVISIBLE_ZERO_WIDTH-_locales/fa/messages.json-0 fire on zero-width joiners that function as ordinary characters in Farsi and related scripts. OBFUSCATION-LARGE_BASE64-shared/editor.js-28921 and OBFUSCATION-LARGE_BASE64-pages/background.js-116110 sit in a rule editor that embeds its assets inline. Unicode and base64 flags tell you the scanner could not read the text as plain English, nothing more.

A skeptic would say the severity labels look bad: 22 network findings plus obfuscation marked high, in a beta build that could change without notice. That reading treats volume and severity as evidence of intent. The findings themselves name no external endpoint, no credential domain, and no payload. They live in vendors/, shared/, pages/ and the filter directories, which is where a filter engine, a state machine library and a localization set belong. A beta channel explains the version string, not hidden behavior, and adguard.com is a real publisher with a support address attached to the build.

The one thing that would change this picture: an outbound request from these files to a domain AdGuard does not operate. Nothing in the scan shows one.

Key Reasons

• Developer identity [email protected] matches the established AdGuard ad-blocking product
• Zero malware signatures, zero IoC matches, zero suspicious domains across 23 findings
• All network findings sit in bundled engine and vendor files such as vendors/tswebextension.js and vendors/xstate.js
• Unicode and zero-width obfuscation flags land on filter data and Farsi locale files, well documented false-positive sources
• No host permissions or API permissions declared in the manifest

False Positive Considerations

• Unicode-heavy obfuscation flags on multilingual filter and rule text
• Zero-width characters in filters/filters_i18n.json and _locales/fa/messages.json
• Network fetch findings inside bundled vendor libraries and the filtering engine
• Base64 flags on embedded editor assets in shared/editor.js

Reviewed 2026-10-02; recommended action: suppress false positive; model confidence 90%.