CVE-2026-13282: Chrome Android Payments Use-After-Free Vulnerability

Technical summary

The vulnerability is a use-after-free condition (CWE-416) in the Payments subsystem of Google Chrome on Android. Use-after-free flaws occur when code attempts to access memory after it has already been freed, potentially allowing an attacker to corrupt heap structures or redirect program execution. The Payments feature processes financial transactions and related data; the presence of a use-after-free in this attack surface is notable because Payments handles sensitive user information. The flaw is triggered via physical access to the device, meaning an attacker must have direct manipulation capability.

Business impact

Organizations deploying Android devices with Chrome—particularly those managing corporate mobile fleets—should assess this as a targeted insider threat or theft risk rather than a remote attack vector. If a device is lost or seized, an attacker with physical access could exploit this flaw to compromise sensitive payment data, authentication credentials, or other information stored in Chrome's memory. For most enterprises, the business impact depends on whether devices are unattended in untrusted environments and whether sensitive payment or financial operations are performed via Chrome on those devices. Consumer users face similar risk if their devices are physically stolen or accessed by household members.

Affected systems

Google Chrome on Android prior to version 149.0.7827.201 is vulnerable. Verify exact version numbers against your installed base; this includes all stable, beta, and development releases below the patched version. The Android OS itself is listed as an affected product due to Chrome's tight integration with the platform, though the flaw resides in Chrome's code, not Android's kernel or core services.

Exploitability

Exploitability is constrained by the requirement for physical access to the device. This is not a remotely exploitable vulnerability and cannot be weaponized in automated, large-scale attacks across the internet. An attacker must have the device in hand, unlock it, navigate to the Payments feature, and trigger the specific code path. The lack of user interaction required (UI:N in the CVSS vector) means once an attacker has physical possession, they do not need to trick the user further. However, exploiting heap corruption reliably often requires additional information about memory layout, making ad-hoc exploitation non-trivial. This vulnerability is not included in the CISA Known Exploited Vulnerabilities (KEV) catalog, indicating no confirmed public exploitation has been observed.

Remediation

Update Google Chrome on Android to version 149.0.7827.201 or later. Google automatically pushes Chrome updates on most Android devices, but users should verify their version in Chrome Settings > About Chrome and manually trigger updates if needed. For organization-managed Android devices, leverage Mobile Device Management (MDM) policies to enforce Chrome version compliance and block outdated versions from use. No workarounds are available; patching is the only remediation.

Patch guidance

Verify availability of Chrome 149.0.7827.201 or later through Google Play Store. Most users on recent Android versions will receive the update automatically within days of release. Organizations using MDM should confirm patch deployment targets are set to this version or later and that compliance monitoring is active. If internal Chrome instances or custom builds are in use, ensure your build pipeline applies the fix before distribution. Test the patch in a limited pilot on a representative device sample before full rollout to confirm no compatibility issues with your business applications.

Detection guidance

On the network level, this vulnerability does not enable remote code execution, so signature-based network detection is not applicable. Endpoint detection should focus on identifying Chrome versions below 149.0.7827.201 through inventory and MDM reporting tools. On individual devices, check Chrome settings to confirm the installed version. For organizations, implement automated reporting from MDM solutions to flag non-compliant Chrome versions. If you suspect a device may have been exploited (evidence of unauthorized access, unexpected behavior, or known theft), perform forensic analysis on the device's memory and Chrome sandbox to detect use-after-free exploitation artifacts, though this is resource-intensive and practical only for high-value incident response.

Why prioritize this

Prioritize this vulnerability for patching based on device usage context rather than raw severity scores. High-risk scenarios include devices used by finance teams, mobile payment processors, or those frequently accessed in untrusted locations. Lower-risk scenarios include corporate devices kept in secure offices with minimal payment functionality. The lack of remote exploitability and absence from the KEV catalog mean this should not trigger emergency response protocols, but it should be included in the standard patch cycle. Organizations should target completion within 30 days of patch availability.

Risk score, explained

The CVSS 3.1 score of 6.8 (MEDIUM) reflects the confluence of high impact (confidentiality, integrity, and availability all marked 'High' if the flaw is exploited) against a low attack vector (Physical access only). The vector CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H penalizes remote exploitability but acknowledges that successful exploitation would severely compromise the device. The Chromium security team's 'High' severity rating emphasizes the memory corruption danger; the CVSS downgrade to MEDIUM is appropriate because physical access remains a meaningful barrier for most threat actors.

Frequently asked questions