CVE-2026-82640 in web-ui
Summary
by MITRE • 08/30/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/30/2026
The vulnerability identified in browser-use web-ui versions 2.0.0 through 3.0.0 represents a critical failure in credential management and data protection mechanisms within the application's configuration handling logic. The core technical flaw lies in how the software persists Large Language Model API keys to local storage. Instead of utilizing secure, encrypted vaults or operating system-level protected key stores such as Windows Credential Manager, macOS Keychain, or Linux Secret Service API, the application writes these sensitive secrets directly into plain text JSON files within a temporary settings directory. This design choice ignores fundamental security principles regarding the protection of high-value cryptographic material and authentication tokens that grant access to external AI services.
From an operational perspective, this implementation creates a significant attack surface for local privilege escalation or data exfiltration scenarios. Any user account on the host system, including unprivileged users or processes running under compromised service accounts, can read these configuration files if they possess standard file read permissions within that directory structure. The predictability of the JSON filenames further simplifies reconnaissance efforts for an attacker who has gained any level of access to the machine. Once accessed, the recovered API keys allow malicious actors to impersonate the legitimate user against the LLM provider, potentially leading to unauthorized usage charges, abuse of service quotas, or exploitation of downstream applications that rely on these credentials for authentication and authorization decisions.
This vulnerability aligns with CWE-312 Cleartext Storage of Sensitive Information, as it involves storing sensitive data in a format that is readable without decryption keys or additional access controls. It also relates to CWE-798 Use of Hard-coded Credentials if the default configuration includes such values, though primarily it reflects poor key management practices categorized under CWE-321 Use of a Key Past its Expiration Date when considering the lifecycle and rotation implications, but more accurately fits within broader categories of insecure data storage. In terms of adversary tactics, this flaw facilitates lateral movement or persistence if an attacker compromises one user account to harvest credentials for other systems that may share similar authentication patterns, mapping closely to ATT&CK technique T1552 Unsecured Credentials where the focus is on acquiring private keys and passwords from local system sources.
Mitigation strategies must prioritize immediate remediation of the storage mechanism. Developers should refactor the configuration handling logic to utilize secure operating-system provided key stores that enforce strict access control lists and encryption at rest. If persistent file-based storage is required for portability, the application must implement strong symmetric encryption using a user-derived passphrase or hardware-backed keys before writing any sensitive data to disk. Additionally, implementing proper file permission restrictions such as setting restrictive umask values during file creation can provide a layer of defense-in-depth by ensuring that only the owning process and user can read the configuration files. Users affected by this vulnerability should immediately rotate all exposed API keys through their respective provider dashboards to invalidate any potentially harvested credentials and upgrade to patched versions where these storage practices have been corrected.