When a trusted extension changes owners: QuickLens, ShotBird, and supply-chain risk

Researchers and analysts described a pattern where legitimate-looking Chrome extensions later received updates from a new publisher and began behaving like malware. Coverage focused on two add-ons originally tied to a developer account associated with BuildMelon (akshayanuonline@gmail.com): QuickLens (Google Lens–style search) and ShotBird (screenshots / image tooling). Install bases were on the order of thousands of users for QuickLens and hundreds for ShotBird at the time of reporting.

The broader lesson is not the brand names—it is that the Chrome Web Store listing can stay familiar while the code path behind it changes.

What investigators reported

Ownership and timing
Reporting traced listing changes and marketplace activity: for example, QuickLens was said to have been offered for sale shortly after launch, with a store owner change noted around February 1, 2026. ShotBird was described as receiving a “Featured” flag before a handoff to another developer account (loraprice198865@gmail.com). Exact timelines differ by source; treat dates as indicators to verify, not guarantees for every reader’s environment.

QuickLens (malicious update characterization)
Analysis attributed to Annex Security described an update that kept user-visible functionality but added behavior such as stripping or weakening HTTP security headers (for example X-Frame-Options) on responses, which can soften defenses like Content Security Policy (CSP) in practice when combined with other page tricks. The same line of research described periodic polling of a remote server, JavaScript stored in extension storage, and execution tied to DOM tricks (for example a small hidden image whose onload runs attacker-controlled script). A key point from that write-up: payloads may not sit in the static extension package—they can appear only at runtime after fetch, which complicates pure static review.

ShotBird (different second stage)
monxresearch-sec was cited for a parallel analysis: remote JavaScript delivered in another way, fake Chrome update prompts, and a ClickFix-style flow that steers the user toward running system commands (for example via PowerShell), with a binary such as googleupdate.exe described on Windows. From there, reporting described form field hooking and browser data access—credentials, history, and similar.

Attribution
Coverage suggested a shared command-and-control style and parallel operation, leading assessors to treat the two extensions as likely related activity. That is an analyst judgment, not something end users need to memorize—what matters operationally is removal and audit.

Why this pattern hurts

• Trust carries forward. Users who installed a “good” version may auto-update into a bad one without revisiting the store page.
• Featured or popular is not a permanent seal. Store placement can reflect past quality.
• Browser-only abuse can bridge to the OS when a second stage tricks the user into running downloaded code.

What to do

1. Remove extensions you do not recognize or no longer need.
2. Check the publisher on the Chrome Web Store today—not only at install time.
3. Prefer fewer extensions with clear scope; treat broad host access as higher stakes.
4. On managed machines, align with IT policy; report suspicious add-ons.

Practical next step

Open Chrome’s Extensions page and sort by recent updates mentally: anything you did not expect, or whose publisher name no longer matches what you remember, deserves a second look. eSafe can help you see permissions and risk signals in one place.

Go deeper

Analyze an extension before you install → — permissions, publisher signals, and update history.

Report: The Hacker News.