ChatGPT token theft via browser extensions expands identity risk

At a glance

What this is: LayerX Security found 16 browser extensions posing as ChatGPT tools that stole session tokens and enabled account takeover.

Why it matters: This matters because AI browser extensions now sit inside the identity perimeter, so IAM, NHI, and endpoint teams must treat them as privileged software, not harmless add-ons.

By the numbers:

• The campaign consists of at least 16 distinct extensions developed by the same threat actor.
• Currently, approximately 900 downloads are associated with this campaign.
• Of the 16 identified extensions in this campaign, 15 were distributed through the Chrome Web Store, while one extension was published via the Microsoft Edge Add-ons marketplace.

👉 Read LayerX Security's analysis of the ChatGPT extension token theft campaign

Context

AI-powered browser extensions have become part of the working environment for users who rely on generative tools, but that convenience also expands the identity attack surface. When an extension can observe authenticated web traffic, it stops being a simple productivity add-on and becomes a software identity control point.

In this campaign, the problem is not a vulnerability in ChatGPT itself. The issue is that third-party code running in the browser can intercept session tokens, impersonate the user, and reach conversation history and connected services, which is a browser-layer identity governance failure rather than a platform defect.

Key questions

Q: How should security teams handle browser extensions that access authenticated AI services?

A: Security teams should treat browser extensions that can read authenticated AI sessions as privileged software. Allow them only after permission review, code inspection, and endpoint policy checks. The key control is not whether the extension looks useful, but whether it can observe tokens, session state, or data inside the same runtime as the protected application.

Q: Why do browser-based AI extensions create identity risk for enterprise users?

A: They create identity risk because they can sit inside the authenticated session and see the same bearer tokens the user relies on. That means an apparently harmless productivity add-on can become a credential interception path, especially when it has access to web application runtime state and connected services.

Q: What breaks when session tokens are exposed through browser extensions?

A: When session tokens are exposed, account possession becomes enough for impersonation. The attacker does not need the password or a new login flow. They can reuse the active token to access conversations, metadata, and any connected service reachable from that session, which turns one browser compromise into broader identity exposure.

Q: How can organisations reduce the risk from malicious AI browser extensions?

A: Organisations should combine extension allowlisting, browser telemetry, and SaaS session monitoring so risky add-ons are detected before they become routine access paths. They should also remove extensions that require deep access to authenticated pages unless the business need is explicit and the runtime behaviour is verified.

Technical breakdown

Session token interception in the browser runtime

The core technique is browser-side session hijacking. The malicious extensions injected content scripts into the page's MAIN JavaScript world, where they could hook native functions such as window.fetch and inspect outbound requests before the browser finished sending them. When an authorization header appeared, the token was extracted and forwarded to attacker infrastructure. That matters because session tokens function as bearer credentials: whoever holds them can act as the user until the session expires or is revoked. This is not password theft. It is runtime credential interception inside an authenticated session.

Practical implication: monitor authenticated browser sessions for token exfiltration patterns and treat extensions with page-level access as privileged software.

Why MAIN-world execution changes the trust model

Chrome extensions normally run in an isolated context, but MAIN-world execution places extension code inside the same runtime as the web application. That lets the code observe in-memory objects, wrap native APIs, and access data that never needs to hit the DOM or network in visible form. In an AI application, that means prompts, headers, session artifacts, and workflow state can all be exposed at runtime. The security boundary is no longer just the SaaS platform. It now includes every extension allowed to share the page context.

Practical implication: restrict MAIN-world-capable extensions on authenticated AI services and review browser policy for runtime script access.

Coordinated extension campaigns as an identity abuse pattern

This campaign was not a single rogue add-on. Shared code, synchronized updates, similar branding, and a common backend indicate a distributed identity theft operation designed for scale. Once the stolen session token is paired with extension metadata and backend-issued tokens, the attacker can maintain access, correlate activity across sessions, and widen the blast radius into connected services. For IAM teams, that creates a governance problem that sits between endpoint control, SaaS access, and non-human credential management.

Practical implication: detect clustered extension behaviour across stores and correlate browser telemetry with identity events in connected SaaS platforms.

Threat narrative

Attacker objective: The attacker wants persistent account-level access to ChatGPT identities and the data reachable through those authenticated sessions.

1. Entry occurs when a user installs a ChatGPT-themed browser extension that is marketed as a productivity or enhancement tool.
2. Credential access occurs when the extension hooks page runtime functions, extracts the ChatGPT session token, and forwards it to attacker-controlled infrastructure.
3. Impact occurs when the attacker reuses the stolen token to impersonate the user, access chat history, and reach connected data sources and metadata.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser extensions have become identity intermediaries, not just productivity tools. When an extension can read authenticated traffic inside the page runtime, it can capture the same session artefacts a user session depends on for trust. That collapses the distinction between interface tooling and credential-bearing software. Practitioners should treat AI-integrated extensions as privileged access paths, not optional browser decoration.

This campaign shows a browser-layer non-human identity problem, not a ChatGPT platform problem. The stolen token behaves like any other bearer secret: possession equals access. That places the control challenge squarely in NHI governance, because the extension ecosystem now behaves like an unmanaged credential surface with runtime reach into authenticated services. The implication is that browser governance and identity governance can no longer be separated cleanly.

Session-token theft creates identity blast radius through connected services. Once the attacker obtains the token plus extension telemetry and backend-issued access data, the compromise can extend beyond one account into linked productivity systems and correlated activity patterns. That makes the failure mode broader than account takeover. It is access persistence across an identity chain. Practitioners should map which browser extensions can reach which authenticated services and why.

Dynamic browser trust is the named governance gap this campaign exploits. The assumption that an extension is safe because it appears in a store or uses a legitimate UI story is no longer adequate. That assumption fails when the extension executes in the same runtime as the protected application and can harvest session material mid-flight. The implication is that trust decisions must be based on runtime behaviour, not marketplace packaging.

AI-assisted browser ecosystems are expanding faster than conventional control frameworks can classify them. The market is producing tools that look like convenience software but operate with identity significance once they handle authenticated sessions. That requires identity teams, endpoint teams, and browser governance owners to share a common model for access risk. Practitioners should reclassify browser extensions that touch AI sessions as part of the enterprise identity perimeter.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• That same study found only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which helps explain why browser-extension identity risk often hides in plain sight.
• For a deeper governance view, see NHI Lifecycle Management Guide for lifecycle controls that apply when third-party software touches authenticated access.

What this signals

Dynamic browser trust: the control problem here is not just malware detection, but deciding which runtime code is allowed to observe authenticated sessions in the first place. When AI extensions can read bearer tokens, extension governance becomes part of identity governance.

The practical shift for enterprise programmes is toward treating browser add-ons as access-bearing software. That means extension allowlisting, runtime inspection, and SaaS session correlation should sit alongside secrets governance and access reviews, not in a separate endpoint silo.

As The 52 NHI breaches Report shows across real incidents, the weak point is often the credential boundary rather than the application itself. AI extensions intensify that pattern because they operate directly inside the session boundary.

For practitioners

• Classify AI-integrated extensions as privileged software Put any extension that interacts with authenticated AI services into a high-risk software category and require explicit approval before installation on managed endpoints. Use browser policy to restrict extension permissions, extension stores, and MAIN-world script access on systems that handle sensitive work.
• Correlate browser telemetry with identity events Link extension activity to SaaS authentication logs, token issuance events, and unusual session reuse so token theft can be spotted as identity abuse rather than just suspicious network traffic. Pay special attention to repeated access from different IPs or sessions that share extension fingerprints.
• Block deceptive extension patterns at the browser layer Create detection for branding reuse, synchronized update behaviour, shared backend domains, and near-identical extension code across multiple listings. Those signals are often stronger than download counts when malicious extension campaigns are still small.
• Review browser access to connected AI workspaces Inventory which extensions can reach ChatGPT, connected drives, code repositories, and collaboration tools from the same browser session. Then remove any extension that can observe authentication headers or session tokens from managed user profiles.

Key takeaways

• Malicious AI browser extensions can steal session tokens without breaking into the underlying application, which makes the browser runtime part of the identity attack surface.
• The scale is still modest at roughly 900 downloads, but the campaign's shared code, coordinated updates, and store distribution show how quickly a small extension set can become an identity problem.
• Enterprises should govern extensions that touch authenticated AI services as privileged software and monitor them with the same seriousness applied to other bearer-credential risks.

Key terms

• Browser Session Hijacking: Browser session hijacking is the theft or reuse of an active authenticated session so an attacker can act as the user without needing the password again. In AI workflows, it often targets bearer tokens, cookies, or in-memory session artefacts exposed inside the browser runtime.
• Bearer Token: A bearer token is a secret that grants access to a service to whoever possesses it. Unlike a password, it is usually presented automatically by the client during a live session, which makes interception especially dangerous when browser extensions can observe requests in memory.
• MAIN World Execution: MAIN world execution means browser extension code runs inside the same JavaScript context as the web page itself. That gives the extension deeper access than a normal isolated script, including the ability to observe or wrap runtime functions and inspect in-memory state.
• Browser Attack Surface: The browser attack surface is the collection of ways web content, extensions, scripts, and session material can be abused on the client side. For AI services, it includes authenticated pages, extension permissions, and any code that can observe or modify runtime behaviour.

Deepen your knowledge

AI browser extension governance is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with authenticated AI services in the browser, this is a practical starting point.

This post draws on content published by LayerX Security: How We Discovered a Campaign of 16 Malicious Extensions Built to Steal ChatGPT Accounts. Read the original.