Browser-extension PUBLISHER credential phishing — impersonates Chrome Web Store / Firefox Add-ons (AMO) / Edge Add-ons / Opera Add-ons with a developer-account-security / Manifest-V3-migration / extension-listing-suspended / mandatory-publisher-verification narrative + credential-harvesting link on a non-store host. Targets extension PUBLISHERS (distinct from iter-889 `browser-extension-install-lure` which targets consumers). Compromise = attacker pushes signed malicious update to every installed user of every extension the publisher maintains, auto-deployed without user action. Cyberhaven Dec 26 2024 breach is canonical precedent: attacker phished a CWS developer, pushed malicious update that harvested Facebook Business manager credentials from every install. Evidence: Cyberhaven disclosure; OrcaSecurity + Socket + Secureannex Jan 2026 supply-chain-extension report; Google Chrome Web Store 2025 transparency report on developer-compromise-driven malicious updates

Phishing that targets browser-extension PUBLISHERS with a credential-harvesting link disguised as an extension-store developer-security notification. Attack surface covers the four major extension stores: Chrome Web Store (chrome.google.com, chromewebstore.google.com), Firefox Add-ons (AMO, addons.mozilla.org), Microsoft Edge Add-ons (microsoftedge.microsoft.com), and Opera Add-ons (addons.opera.com). The narrative fires on four hooks: (a) policy-violation / listing-suspension framing ("your extension has been flagged for policy violation, respond within 48 hours or listing will be suspended"), (b) mandatory publisher / developer verification ("all publishers must complete mandatory publisher verification under the new developer program policy"), (c) Manifest V3 migration urgency ("your extension requires Manifest V3 migration, re-verify your developer account to complete"), (d) extension-review-pending workflow impersonation ("your extension review is pending, sign in to the developer dashboard to respond"). The credential-harvesting link points at a typosquat host that captures the publisher's developer-console credentials. Once compromised, the attacker can push a SIGNED malicious update to every installed user — browser extensions have elevated permissions (read/modify all browsing activity, access cookies + localStorage, inject scripts into any page) so the downstream impact is severe. Canonical precedent: the Cyberhaven compromise on December 26 2024. Attackers phished a Chrome Web Store developer at Cyberhaven with a "your extension violates policy" email, harvested the developer's Google credentials, and within hours pushed a malicious update to the legitimate Cyberhaven extension (installed on hundreds of thousands of corporate browsers). The malicious update harvested Facebook Business manager credentials from every install — OrcaSecurity later identified at least 35 other Chrome extensions compromised in the same campaign wave. Google's Chrome Web Store 2025 transparency report confirmed developer-account compromise as the dominant malicious-update vector. Reuters + Bleeping Computer + Ars Technica covered the fallout through January 2026. Distinct from `browser-extension-install-lure` which targets CONSUMERS (install-this-typosquat shape) — this signal targets the much smaller but much higher-impact population of PUBLISHERS. Legitimate extension-store emails link exclusively to the store's own domain: `chromewebstore.google.com`, `chrome-developers.google.com`, `addons.mozilla.org`, `microsoftedge.microsoft.com`, `addons.opera.com`. Any publisher-security email whose sign-in link is hosted elsewhere is, by construction, a phish. If you publish browser extensions: enable hardware-backed 2FA (FIDO2 security key) on every store developer account, never re-authenticate via an email link, and go directly to the developer console via a bookmarked URL.