MEGA

AI Security Review

Evidence context: threat category none; evidence quality moderate.

What the package contains

The scanned tree reads like MEGA's web client: mega/js/utils/api.js, mega/js/utils/network.js, mega/js/ui/transfer/core.js and mega/js/ui/transfer/js/ui/pages/fm.js. Every one of the 101 network findings lands inside those directories, marking fetch and XMLHttpRequest call sites for transfers, session handling and file listing. That volume follows from what a cloud drive does. No endpoint list came back with the scan, and the extracted domain set holds nothing pointing outside the extension's own service.

The four obfuscation hits

These carry the only high severities in the package, and they cluster on two files. mega/pdf.worker.js triggers OBFUSCATION-unicode_heavy, OBFUSCATION-hex_string_heavy and OBFUSCATION-fromcharcode_bulk. That worker ships with PDF.js, Mozilla's open-source renderer, whose font tables, CMap data and glyph maps generate dense unicode ranges, long hex literals and bulk String.fromCharCode decoding. mega/js/mDB.js triggers OBFUSCATION-unicode_heavy on MEGA's local database layer, where key and attribute tables run unicode-dense as well. Malware signature matches across the whole package: zero. Credential rules: zero. Secrets: zero. Obfuscation paired with a payload signature is the pattern that matters, and the pairing here is obfuscation with a well-known library file.

The strongest counterargument

A skeptic would ask why developer_name came back blank and why the manifest scrape returned no permissions and no host permissions. Both are fair worries, since a cloud storage client must request something, and the empty publisher field removes the shortcut of a named brand. The identification rests on the source tree instead. Those paths mirror MEGA's public web client, and the code sits unminified and readable. A typosquat or a repackaged build would not ship MEGA's directory layout, and its calls would resolve to a domain MEGA does not own. The 897 informational results describe no such domain, and the pack contains no tool-poisoning or dependency finding either.

What would close the gap

A manifest read that returns the real permission list, plus the resolved hostnames behind mega/js/utils/api.js. Should that file reach only MEGA's own service, the picture stays as it is. A request for cookies, or traffic to login or banking origins, would flip the reading. Nothing in this scan points that way, and the one call site outside the transfer logic, mega/html/js/embeddrop.js, handles drag-and-drop uploads.

Key Reasons

• All 101 network findings sit in MEGA's own client files (mega/js/utils/api.js, mega/js/utils/network.js, mega/js/ui/transfer/core.js) as ordinary fetch and XMLHttpRequest call sites
• Obfuscation findings land on mega/pdf.worker.js, the PDF.js renderer worker, where unicode tables, hex literals and String.fromCharCode decoding are expected
• Zero malware-signature, malware, credential, secret, IoC or tool-poisoning matches across 1002 results
• 897 of the findings are informational, so the total is dominated by low-signal volume rather than behaviour
• Publisher field and manifest permissions came back empty, which limits identification to the readable, unminified source tree

False Positive Considerations

• PDF.js worker heuristics (unicode_heavy, hex_string_heavy, fromcharcode_bulk) on a bundled open-source renderer
• Network call sites in the extension's own API client counted as findings
• 897 informational results inflating the total
• Manifest scrape returned empty permissions, showing extraction gaps rather than behaviour

Reviewed 2026-10-18; recommended action: suppress false positive; model confidence 85%.