Topic starter
08/02/2026 8:23 pm
TL;DR: A malicious Chrome extension impersonating ChatGPT stole 459 unique OpenAI API keys from about 10,000 installations, according to Obsidian Security, while also exfiltrating them through a Telegram bot and requesting broad Google Drive access. Browser extensions can become a stealthy NHI theft channel when users are asked to trust credential entry inside an app layer they do not govern.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “Small Tools, Big Risk: When Browser Extensions Start Stealing API Keys”.
By the numbers:
- Obsidian Security extracted 459 unique API keys from about 10,000 installations of the malicious extension.
- The extension was last updated June 25th, 2025, before the theft logic changed to trigger on the second open of the side panel.
- In total, Obsidian Security found 25 extensions engaging in malicious or suspicious behavior.
Key questions
Q: What breaks when users enter API keys into browser extensions?
A: The trust boundary breaks at the point of secret entry.
Q: Why are browser extensions risky for API key governance?
A: They create a human-mediated secret intake path that sits outside standard IAM controls.
Q: What are the signs that a browser extension is handling secrets unsafely?
A: Look for secret prompts, local storage of credentials, delayed network calls after user interaction, and permission requests that exceed the stated feature.
Practitioner guidance
- Inventory browser extensions that can accept secrets Identify extensions that prompt for API keys, tokens, or account credentials, then classify them as part of your NHI intake surface rather than ordinary browser customisation.
- Block or approve-list AI-themed extensions Create a controlled allow-list for browser extensions that interact with AI services, and remove anything that impersonates a known tool or routes data to unapproved endpoints.
- Revoke keys entered into suspicious extensions Rotate any OpenAI API keys or similar secrets that were entered into the malicious extension, then inspect downstream logs for use after exposure.
Bottom line: Browser extensions can turn API key entry into a hidden exfiltration path when their storage and outbound traffic are not governed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
10/10/2026 6:46 pm
Browser extensions have become an NHI credential collection layer, not just a productivity layer. The core mistake is treating a browser add-on as a harmless client enhancement when it can solicit, store, and forward API keys. That creates a delegated access path outside normal IAM review, and the trust decision happens in the browser rather than in an access control plane. Practitioners should treat extension-mediated credential entry as governed NHI intake, not casual user behaviour.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should organisations treat browser extensions as part of identity governance?
A: Yes. Extensions operate with delegated access to browser sessions, which makes them a form of shadow identity inside the user environment. If they can reach authentication state or manipulate web content, they belong in the same governance conversation as privileged access and non-human identity controls.
👉 Read our full editorial: Browser extensions are becoming a stealthy API key theft channel