Simpsons Bart Nirvana Live Wallpaper

AI Security Review

Evidence context: threat category none; evidence quality moderate.

The Simpsons Bart Nirvana Live Wallpaper extension (version 1.2, around 1,000 users, published by [email protected]) declares no permissions and no host permissions. Every finding recorded against it is a network call: NET-FETCH-js/background.js-63, NET-FETCH-js/background.js-82, NET-FETCH-js/background.js-96, NET-FETCH-js/popup.js-39, NET-FETCH-js/sidePanel.js-362 and NET-FETCH-js/weather.js-49. All six are rated medium. There are no IoC matches, no malware signatures, no obfuscated files, no dependency findings, no exposed secrets and no manifest-analysis problems.

The file layout explains the calls. js/background.js is the service worker that keeps a live wallpaper running. js/popup.js drives the toolbar popup. js/sidePanel.js powers the side panel. js/weather.js makes a call at line 49 that matches its own filename. A wallpaper that streams video and shows a weather widget has ordinary reasons to reach the network, and this extension asks for none of the permissions that would let it touch cookies, tabs, history or passwords.

Three absences matter here. No finding points at a credential-harvesting pattern, a login domain or a cookie read. No file shows obfuscation, so the fetch calls sit in readable code. And no destination is recorded for any of the six calls, so there is no suspicious host to weigh.

That last point is also the strongest argument against calling this clean. A background script making three network calls that the manifest does not declare access for is the kind of thing that deserves a second look. Someone could reasonably ask whether js/background.js is contacting a server it has no business contacting. Two details push back. First, the finding locations line up with the extension's stated function: a service worker, a popup, a side panel and a weather module, each with its own reason to fetch. Second, harm needs a mechanism, and none is present. No host permission, no cookie access, no credential API, no encoded payload. Chrome also permits fetches to an extension's own packaged resources and to origins a page has already granted, which produces findings of this shape without any outside contact.

What would settle the question is a short runtime capture in a browser, which would show the host behind each call. Until that exists, the evidence on hand describes a wallpaper extension doing wallpaper work, with a scanner logging the calls and not their targets.

Key Reasons

• All six findings are medium-severity fetch calls in js/background.js, js/popup.js, js/sidePanel.js and js/weather.js, with no malware signatures, IoCs or obfuscation anywhere in the scan.
• The manifest declares no permissions and no host permissions, leaving no cookie, tab, history or credential API surface to abuse.
• Each finding location matches the extension's stated function: a service worker, a popup, a side panel and a weather widget.
• No destination is recorded for any of the six calls, so there is no suspicious host or exfiltration endpoint to evaluate.

False Positive Considerations

• Bare fetch() calls recorded without destination URLs
• No IoCs, malware signatures, obfuscation or dependency findings to corroborate a threat
• Empty permission and host-permission lists leave no privileged API access
• Network activity consistent with a wallpaper pulling media and weather data

Reviewed 2026-10-15; recommended action: monitor; model confidence 70%.