CVE-2026-82640: browser-use web-ui: stores LLM API keys in cleartext

MEDIUM
Published August 30, 2026
CISO Take

browser-use web-ui, an operator UI for browser-automation AI agents, writes configured LLM provider API keys (OpenAI, Anthropic, and others) to disk as plaintext JSON in a predictably-named file inside a temporary settings directory, with no encryption or access restrictions applied. Any local user or process that can read that directory recovers the keys outright — a realistic exposure on shared devboxes, CI runners, or multi-tenant containers where agent tooling like this commonly runs. There is no public exploit code, no Nuclei scanner template, no EPSS score, and it is not in CISA KEV, so this is not an active-exploitation emergency, but the CVSS 5.5 (AV:L/AC:L/PR:L/UI:N, C:H) reflects that once local access exists, exploitation is a one-step file read requiring no AI/ML expertise. Rotate any LLM API keys ever configured in versions 2.0.0–3.0.0, upgrade once a patched release lands (tracked in GitHub issue #736), and in the meantime lock down or encrypt the settings directory and avoid running the tool on shared hosts. Watch LLM provider billing/usage dashboards for anomalous activity as a compensating detection control since the keys themselves grant no in-app audit trail once exfiltrated.

Sources: NVD GitHub Advisory ATLAS vulncheck.com

What is the risk?

Medium severity (CVSS 5.5) driven entirely by confidentiality impact — integrity and availability are untouched. The attack requires local access and low privileges, but complexity is low and no user interaction is needed, making exploitation trivial for anyone who already has a foothold (compromised low-priv account, malicious co-tenant on a shared host, or another local process). No public exploit, scanner template, EPSS score, or CISA KEV listing exists, so there's no evidence of active or automated exploitation in the wild. The real risk driver is downstream: stolen LLM API keys can be reused off-host for financial abuse (usage billed to the victim), data exfiltration through the provider account, or impersonation of the agent — impact that isn't captured by the CVSS score itself. Risk is elevated on shared/multi-tenant infrastructure (CI runners, shared devboxes, containers with multiple local users) and low on single-user, single-tenant workstations.

How does the attack unfold?

Local Foothold
Attacker already holds a low-privileged local account or process on a host (shared devbox, CI runner, multi-tenant container) running browser-use web-ui.
AML.T0084
Configuration Discovery
Attacker enumerates the predictably-named JSON settings file inside the tool's temporary settings directory.
AML.T0037
Credential Theft
Attacker reads the file and recovers the cleartext LLM provider API key(s) stored without encryption or access controls.
AML.T0055
Impact via Stolen Credentials
Attacker reuses the stolen API key against the LLM provider directly, incurring unauthorized billing, exfiltrating provider-account data, or impersonating the victim's agent.
AML.T0048.000

How severe is it?

CVSS 3.1
5.5 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AV AC PR UI S C I A
AV Local
AC Low
PR Low
UI None
S Unchanged
C High
I None
A None

What should I do?

1 step
  1. 1) Rotate every LLM provider API key that has ever been configured in an affected browser-use web-ui instance (2.0.0–3.0.0), regardless of whether compromise is confirmed. 2) Upgrade to a patched release as soon as one is published (tracked at github.com/browser-use/web-ui/issues/736); until then, treat the temp settings directory as sensitive. 3) Restrict filesystem permissions on the settings directory to the single OS user running the tool (chmod 700 / owner-only ACLs) and avoid running the tool as a shared or root account. 4) Do not run this tool on shared multi-tenant hosts, shared CI runners, or containers with untrusted co-tenants without additional isolation. 5) Where possible, supply API keys via environment variables or a secrets manager injected at runtime rather than through the persistent UI config, if the tool supports it. 6) Detection: monitor LLM provider usage/billing dashboards for API calls from unexpected IPs or unexpected volume spikes as a compensating control, since a stolen key leaves no trace inside browser-use itself.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, Robustness and Cybersecurity
ISO 42001
A.6.2 - Data for AI systems
NIST AI RMF
MEASURE 2.7 - AI system security and resilience evaluated and documented
OWASP LLM Top 10
LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-82640?

browser-use web-ui, an operator UI for browser-automation AI agents, writes configured LLM provider API keys (OpenAI, Anthropic, and others) to disk as plaintext JSON in a predictably-named file inside a temporary settings directory, with no encryption or access restrictions applied. Any local user or process that can read that directory recovers the keys outright — a realistic exposure on shared devboxes, CI runners, or multi-tenant containers where agent tooling like this commonly runs. There is no public exploit code, no Nuclei scanner template, no EPSS score, and it is not in CISA KEV, so this is not an active-exploitation emergency, but the CVSS 5.5 (AV:L/AC:L/PR:L/UI:N, C:H) reflects that once local access exists, exploitation is a one-step file read requiring no AI/ML expertise. Rotate any LLM API keys ever configured in versions 2.0.0–3.0.0, upgrade once a patched release lands (tracked in GitHub issue #736), and in the meantime lock down or encrypt the settings directory and avoid running the tool on shared hosts. Watch LLM provider billing/usage dashboards for anomalous activity as a compensating detection control since the keys themselves grant no in-app audit trail once exfiltrated.

Is CVE-2026-82640 actively exploited?

No confirmed active exploitation of CVE-2026-82640 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-82640?

1) Rotate every LLM provider API key that has ever been configured in an affected browser-use web-ui instance (2.0.0–3.0.0), regardless of whether compromise is confirmed. 2) Upgrade to a patched release as soon as one is published (tracked at github.com/browser-use/web-ui/issues/736); until then, treat the temp settings directory as sensitive. 3) Restrict filesystem permissions on the settings directory to the single OS user running the tool (chmod 700 / owner-only ACLs) and avoid running the tool as a shared or root account. 4) Do not run this tool on shared multi-tenant hosts, shared CI runners, or containers with untrusted co-tenants without additional isolation. 5) Where possible, supply API keys via environment variables or a secrets manager injected at runtime rather than through the persistent UI config, if the tool supports it. 6) Detection: monitor LLM provider usage/billing dashboards for API calls from unexpected IPs or unexpected volume spikes as a compensating control, since a stolen key leaves no trace inside browser-use itself.

What systems are affected by CVE-2026-82640?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, browser automation / computer-use agents, local development environments.

What is the CVSS score for CVE-2026-82640?

CVE-2026-82640 has a CVSS v3.1 base score of 5.5 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

agent frameworksbrowser automation / computer-use agentslocal development environments

MITRE ATLAS Techniques

AML.T0037 Data from Local System
AML.T0055 Unsecured Credentials
AML.T0083 Credentials from AI Agent Configuration
AML.T0084 Discover AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2
NIST AI RMF: MEASURE 2.7
OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

browser-use web-ui versions 2.0.0 through 3.0.0 write configured LLM API keys to disk in cleartext without encryption or access restrictions. Attackers with read access to the temporary settings directory can recover provider API keys from predictably-named JSON files.

Exploitation Scenario

A developer runs browser-use web-ui on a shared CI runner or multi-tenant devbox to automate browser-based tasks with an LLM backend, configuring their OpenAI or Anthropic API key through the UI. A second, lower-privileged local account or process on the same host — belonging to another team, a compromised build job, or a malicious co-tenant — enumerates the predictable temp settings path, opens the JSON file, and reads the plaintext API key. The attacker then uses the stolen key directly against the LLM provider's API from their own infrastructure: running up usage costs on the victim's billing account, extracting any data reachable through that provider account, or impersonating the victim's agent in ways that are indistinguishable from legitimate traffic to the provider.

Weaknesses (CWE)

CWE-312 — Cleartext Storage of Sensitive Information: The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

  • [Implementation, System Configuration, Operation] When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]
  • [Implementation, System Configuration, Operation] In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Timeline

Published
August 30, 2026
Last Modified
August 30, 2026
First Seen
August 30, 2026

Related Vulnerabilities