AdGuard Extra (Beta)

AI Security Review

Evidence context: threat category none; evidence quality strong.

AdGuard Extra (Beta) is published under [email protected], the support address AdGuard has used across its extension lineup, and the listing describes it as a supplement for cases that regular ad blocking rules miss. The whole scan produced two findings, both medium severity, both network, both inside a single file.

NET-XMLHTTPREQUEST-userscript.js-4470 points at userscript.js:4470:0, where the code opens an XMLHttpRequest. NET-FETCH-userscript.js-4479 points at userscript.js:4479:0, where the same file calls fetch. An ad blocker that pulls or refreshes filter rules needs at least one of those calls, so both hits describe the extension doing what its description says it does. Neither finding records a destination, so there is no external domain to weigh.

Everything an actual threat would leave behind is missing. The extractor pulled zero indicators of compromise, so no suspicious host or IP survives from userscript.js. No malware signature matched. No obfuscation finding fired on the file. There are no secret findings, no dependency findings, no manifest analysis findings, and no tool-poisoning findings. The extension declares no permissions and no host permissions in this build.

The strongest case against a clean read is that an ad blocker with no host permissions looks contradictory, and that two network calls with no recorded destination could reach anywhere. That argument has a concrete answer. AdGuard Extra is built to run inside the host AdGuard extension as a userscript, which is why the file is named userscript.js and why the manifest requests nothing of its own. A script loaded by another extension inherits that extension's access instead of asking for its own. The missing endpoints are a limit of the call-site detector, which logs the API used and its line number and does not capture the URL argument. What would settle it is reading the arguments passed at userscript.js:4470 and userscript.js:4479 and comparing them against AdGuard's documented filter update hosts.

Nothing here describes data leaving the browser to an unknown party. There is no credential or cookie access, no search hijack, no proxy or relay code, and no naming that copies another product. The two network hits are the mechanics of a rule-updating script from the vendor whose support address sits on the listing.

Key Reasons

• Publisher is AdGuard ([email protected]), a long-established ad-blocking vendor, and the extension is a declared companion to its main product.
• Only two findings exist, both medium-severity call-site hits: NET-XMLHTTPREQUEST-userscript.js-4470 and NET-FETCH-userscript.js-4479 in userscript.js.
• Zero IoCs, malware signatures, obfuscation, secret, dependency, manifest-analysis or tool-poisoning findings.
• Network calls are the expected mechanics of a script that updates or applies filter rules.
• No permissions or host permissions declared, consistent with a userscript loaded by the host AdGuard extension.

False Positive Considerations

• Generic XMLHttpRequest and fetch call-site detections that record no destination URL
• Ad-blocking scripts legitimately make network requests to fetch filter rules
• Known-vendor attribution (AdGuard) driving a clean finding set with no malware indicators
• Userscript distribution model that inherits host extension permissions rather than declaring its own

Reviewed 2026-10-15; recommended action: suppress false positive; model confidence 92%.