Browser extensions are becoming a stealthy API key theft channel

At a glance

What this is: This is a technical analysis of a malicious Chrome extension that stole OpenAI API keys and used extension access to exfiltrate them unnoticed.

Why it matters: It matters because browser extensions now sit inside the enterprise attack surface, so IAM and NHI teams need controls for credential entry, extension governance, and delegated access.

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.

Context

Browser extensions are effectively privileged client-side software that can observe user input, store data locally, and call external services on the user's behalf. In this case, a Chrome extension posed as a ChatGPT helper, asked for an OpenAI API key, and then turned that credential into an exfiltration target rather than a capability to manage.

The identity-security problem is not limited to one malicious add-on. When an extension can impersonate a legitimate tool, request broad browser or cloud permissions, and hide malicious behavior behind normal-looking UX, the trust boundary moves from the application to the browser. That creates a governance gap for NHI credentials that are entered by humans but used by non-human services.

This pattern is typical of a broader extension-risk problem: the compromise is not the browser alone, but the combination of user trust, third-party code, and API-driven workflows that are rarely governed as a single access path.

Key questions

Q: What breaks when users enter API keys into browser extensions?

A: The trust boundary breaks at the point of secret entry. A browser extension can look functional, store the key locally, and later transmit it outside the approved path. That means the organisation loses control over where the secret is used, whether it is retained, and which external services can receive it.

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. If the extension can store, reuse, or forward the key, the credential becomes vulnerable to delayed exfiltration, misuse, and untracked access. The risk is highest when users treat the extension as a trusted productivity tool.

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. Extensions that impersonate legitimate tools or obscure where data is sent are especially suspect because the user cannot reliably validate the destination.

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.

Technical breakdown

How the extension captured API keys without obvious abuse

The extension used a familiar front-end pattern: prompt the user for an OpenAI API key, validate it against the real service, and then store it locally under a benign-looking variable. That makes the workflow look legitimate while quietly turning credential capture into a normal setup step. The theft did not happen at install time, which reduced immediate suspicion. It triggered later, after the key was already entered and the extension had established a trusted routine. This is a classic client-side deception pattern, where a credential is acquired through user interaction rather than direct compromise of the target platform.

Practical implication: treat any browser-side request for API keys as a credential ingestion point that needs explicit approval and inventory.

Why local storage and delayed exfiltration matter

The extension stored the key in local storage as SECRET_KEY and delayed exfiltration until a later side-panel open. That design matters because it separates credential collection from credential theft, making behaviour harder to spot in a single session or one-time review. It also shows that local browser storage is not a trust boundary for secrets. Once a secret is present in extension state, any subsequent logic can transmit it to an external endpoint without user visibility. The delayed trigger makes detection dependent on behavioural monitoring rather than install-time inspection alone.

Practical implication: inspect extensions for local secret handling and event-triggered transmission, not just for obvious malware signatures.

How permission scope expanded the blast radius

Beyond key theft, the extension requested Google Drive access and created a backup folder, even though it retained access to all files and folders in Drive. This is where the problem becomes broader than one stolen secret. Browser extensions often accumulate permission scope that exceeds the narrow feature users think they are installing. When those permissions intersect with API keys, the extension can pivot from one credential to broader data exposure and workflow abuse. The architectural issue is delegated access without tight purpose limitation, which is especially dangerous in browser-mediated identity flows.

Practical implication: review extension permissions as delegated access, and revoke anything that can reach both secrets and cloud storage.

Threat narrative

Attacker objective: The attacker aimed to steal usable API keys for downstream misuse, cost abuse, and potential access to data or workflows tied to those keys.

1. Entry occurred when the user installed a Chrome extension that impersonated ChatGPT and asked for an OpenAI API key during normal use.
2. Credential access occurred when the key was validated, stored locally as SECRET_KEY, and later captured from extension state.
3. Exfiltration occurred when the extension sent the secret to a hard-coded Telegram bot and suppressed repeat sending with a local flag.
4. Impact included unauthorized use of the stolen API keys and broader exposure risk from the extension's Google Drive permissions.

Breaches seen in the wild

• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Prompt poaching is a browser identity problem before it is a malware problem. The article shows that impersonation, disclosure mismatch, and external transmission can all happen while the extension appears functional. That means the governance failure is not only malicious code, but a broken assumption that the user can distinguish legitimate AI tooling from credential-harvesting lookalikes. The implication is that browser-based AI workflows need explicit inventory and policy controls, not just endpoint detection.

Ephemeral browser trust is not a substitute for credential governance. The extension used a normal-looking setup flow to obtain a long-lived API key, then transformed that key into a later exfiltration target. This is a classic example of credential entry without destination assurance: the user supplied a secret without any durable control over where it could be stored or transmitted. Practitioners should assume that any browser surface capable of accepting secrets can also launder them out of policy.

Browser extension permissions can collapse into hidden third-party NHI exposure. The Google Drive access example shows how quickly one extension can move from a single API key to broader cloud reach. That matters because browser permissions are usually reviewed as app permissions, while the real issue is delegated identity scope. The next governance step is to treat extension permissions, storage behaviour, and outbound destinations as one access chain.

Extension discovery has to be part of shadow AI and shadow NHI management. The article's catalog of malicious and suspicious extensions shows that the risk is category-level, not one-off. Once users can install AI-themed tools that proxy prompts or harvest secrets, the enterprise loses visibility into what identities are interacting with external services. The practical conclusion is to combine extension inventory with NHI visibility so that unapproved browser tooling is not left outside governance.

From our research library:

• 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.
• Read next: API Key Management Guide

What this signals

Credential entry inside a browser extension is now an access-governance problem. Security teams should assume that any extension asking for an API key is participating in the identity chain, even when the user believes they are simply enabling a feature. The control question is not whether the add-on works, but whether the secret can be stored, replayed, or exfiltrated outside policy.

Extension permissions and secret handling need to be reviewed together. A browser add-on that can reach Google Drive, local storage, and an external bot endpoint has enough scope to turn a small trust mistake into wider data exposure. That combination should trigger the same review discipline used for third-party access and NHI lifecycle control.

For practitioners

• 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.
• Review delegated cloud permissions from extensions Audit browser extension access to Google Drive and other cloud services, because broad file permissions can turn a secret theft into wider data exposure.

Key takeaways

• Browser extensions can turn API key entry into a hidden exfiltration path when their storage and outbound traffic are not governed.
• The incident combined impersonation, delayed theft, and broad cloud permissions, which made a single browser add-on an identity-security risk.
• The control gap is not just malicious code detection. It is governance over where secrets are entered, stored, and allowed to leave.

Key terms

• Browser Extension Runtime Trust: The level of confidence an organisation places in a browser extension after it has been installed and is operating inside a user session. For security teams, this trust must be based on observed behaviour over time, not just marketplace approval or permissions at the point of install.
• Prompt Poaching: Prompt poaching is the covert capture and forwarding of user prompts, conversations, or related context to an unapproved external system. In browser and AI tooling, it often hides behind a legitimate-looking interface, turning user trust into an unwitting data transfer path.
• Secret Exfiltration Gap: The secret exfiltration gap is the difference between discovering that a credential is public and preventing it from being stolen in the first place. It appears when leaks move through logs, workflows, developer tools, or attacker-controlled endpoints that are outside the monitoring boundary.
• Delegated Browser Access: Delegated browser access is the permission a user grants to software running inside the browser to act on their behalf or read their session context. It is a practical NHI concern because the delegated actor can observe sensitive content without needing separate credentials.

Deepen your knowledge

NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.