CVE-2026-87530 in Chrome
Summary
by MITRE • 09/09/2026
Uncontrolled search path element in CredentialProvider in Google Chrome on on Windows prior to 153.0.8010.36 allowed a local attacker to execute arbitrary code outside the sandbox via a local program. (Chromium security severity: Medium)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified as an uncontrolled search path element within the CredentialProvider component of Google Chrome on Windows represents a significant class of operating system level misconfiguration that undermines application isolation mechanisms. This flaw, classified under CWE-427 which denotes Uncontrolled Search Path Element, occurs when software constructs a file path using user-influenced input without sufficiently verifying that the resulting location is valid and intended by the developer. In this specific instance, the CredentialProvider, which handles authentication logic for Chrome on Windows platforms prior to version 153.0.8010.36, failed to strictly define or validate the directory paths it searches when loading dynamic link libraries or related configuration files. This lack of strict path validation creates a window where an attacker can manipulate the environment variables or system search order to redirect the application toward maliciously crafted resources rather than legitimate ones provided by Google.
From a technical perspective, this vulnerability allows for local privilege escalation and sandbox escape through DLL hijacking or similar file injection techniques. When Chrome attempts to load necessary components via its credential provider, it relies on the Windows dynamic linker to resolve library names. If the search path is not strictly controlled, an attacker with local access can place a malicious Dynamic Link Library in one of the directories that precedes the legitimate installation directory in the system's search order. Upon execution or authentication attempts by Chrome, the operating system loads the attacker-controlled DLL instead of the authentic Google component. Because this loading occurs within the context of the browser process, which may have elevated privileges depending on the specific operation being performed, the malicious code executes with those same permissions. This effectively bypasses the Chromium sandbox, a critical security feature designed to limit the damage that can be done if an attacker successfully exploits another vulnerability or tricks a user into downloading malware.
The operational impact of this flaw is severe for any system running affected versions of Chrome on Windows. A local attacker who gains access to the machine, even with limited user privileges, can exploit this path traversal issue to execute arbitrary code outside the sandbox boundaries. This capability transforms a low-impact local access scenario into a high-severity compromise where the attacker achieves full control over the browser process and potentially escalates further to system-level access depending on how the injected DLL interacts with other components. The ability to bypass the sandbox negates one of Chrome's primary defense-in-depth strategies, exposing sensitive user data such as saved passwords, cookies, and session tokens to theft or manipulation. Furthermore, this could serve as a foothold for more complex attack chains involving lateral movement within a network if the compromised machine is part of an enterprise environment.
Mitigation requires immediate patching to version 153.0.8010.36 or later where these path validation checks have been hardened. Developers must ensure that all file loading operations explicitly specify absolute paths rather than relying on relative search orders, thereby eliminating ambiguity in library resolution. Security monitoring should focus on detecting unusual DLL load events within Chrome processes and verifying the integrity of files in common hijacking directories such as system32 or user profile folders. Additionally, implementing strict application whitelisting policies can prevent unauthorized executables from running even if they are successfully injected into a process context. This vulnerability aligns with MITRE ATT&CK technique T1574.007, DLL Search Hijacking, highlighting the importance of maintaining rigorous file system security controls and keeping software up to date to close gaps in execution flow that attackers routinely exploit for initial access or privilege escalation.