CVE-2025-12443: Chrome WebXR Flaw Hits 4 Billion Devices

Aisle Research discovers a memory disclosure vulnerability in Chromium's WebXR implementation, affecting over 4 billion devices across Chrome, Edge, Brave, and the entire Chromium ecosystem.

Google Chrome runs on over 3 billion devices worldwide. Virtually every Windows laptop, Android phone, Chromebook, and countless smart displays, kiosks, and embedded systems. But Chrome is just one branch of a much larger tree. When a vulnerability affects Chromium, the open-source browser engine underlying Chrome, Microsoft Edge, Brave, Opera, Vivaldi, and the emerging wave of AI-native browsers like Arc, Atlas, and Comet, the blast radius is staggering: over 4 billion devices across virtually every major browser except Safari and Firefox.

In October 2025, AISLE's autonomous analyzer discovered a memory disclosure vulnerability in Chromium's WebXR implementation, the API that powers virtual and augmented reality experiences in the browser. The flaw, now tracked as CVE-2025-12443, allowed malicious web content to leak sensitive heap memory through a seemingly innocuous edge case in matrix handling. It had been present in the codebase for seven months.

WebXR represents exactly the kind of attack surface that keeps security teams up at night: a rapidly evolving API, under active development, interfacing with complex 3D graphics pipelines and new hardware capabilities. Google employs some of the world's best security engineers and runs one of the most mature vulnerability reward programs in existence. They have fuzzing infrastructure, static analysis, mandatory code review, and a dedicated security team. And yet, this bug slipped through.

This is the reality of modern software security. The attack surface is expanding faster than any human team can cover. New APIs, new protocols, new integration points. Each addition multiplies the interaction space exponentially. AISLE exists because autonomous security analysis is no longer optional. It is the only way to keep pace.

The Vulnerability: Where VR Meets Memory Safety

WebXR brings the complexity of 3D graphics into the browser. Applications manipulate positions, rotations, and transformations using interfaces like XRRigidTransform, which represents a position and orientation in 3D space. Internally, Chromium stores these transformations as 4x4 matrices: 16 floating-point values packed into DOMFloat32Array buffers.

The vulnerable code path emerged at the intersection of two features: WebXR's matrix caching and JavaScript's ArrayBuffer transfer semantics. A page can "detach" (or "neuter") a typed array by transferring its underlying buffer to another context, like a Web Worker. This is a legitimate API, commonly used for zero-copy data transfer in performance-sensitive applications.

The Chromium code attempted to handle this edge case gracefully. But the fallback logic introduced a critical flaw.

The Root Cause

When XRRigidTransform::matrix() detected that its cached array had been detached, it returned a freshly created zero-length array:

C
1// third_party/blink/renderer/modules/xr/xr_rigid_transform.cc (VULNERABLE)
2if (!matrix_array_ || matrix_array_->IsDetached()) {
3    // A page may take the matrix_array_ value and detach it so matrix_array_ is
4    // a detached array buffer. This breaks the inspector, so return an empty
5    // array instead.
6    return NotShared<DOMFloat32Array>(DOMFloat32Array::Create(0));
7}
Copy

This zero-length array then flowed to XRRay's constructor, which passed it directly to a transform conversion function:

C
1// third_party/blink/renderer/modules/xr/xr_ray.cc
2XRRay::XRRay(XRRigidTransform* transform, ExceptionState& exception_state) {
3    NotShared<DOMFloat32Array> m = transform->matrix();
4    Set(DOMFloat32ArrayToTransform(m), exception_state);
5}
Copy

The conversion function contained only a debug assertion, which is stripped in release builds:

C
1// third_party/blink/renderer/modules/xr/xr_utils.cc (VULNERABLE)
2gfx::Transform DOMFloat32ArrayToTransform(NotShared<DOMFloat32Array> m) {
3    DCHECK_EQ(m->length(), 16u);  // Only checked in debug builds!
4    return gfx::Transform::ColMajorF(m->Data());
5}
Copy

Finally, ColMajorF blindly accessed 16 array indices, reading 64 bytes past the end of the zero-length buffer:

C
1// ui/gfx/geometry/transform.cc
2Transform Transform::ColMajorF(base::span<const float, 16> a) {
3    if (AllTrue(Float4{a[1], a[2], a[3], a[4]} == Float4{0, 0, 0, 0} &
4                Float4{a[6], a[7], a[8], a[9]} == Float4{0, 0, 0, 0} &
5                Float4{a[10], a[11], a[14], a[15]} == Float4{1, 0, 0, 1})) {
6        return Transform(a[0], a[5], a[12], a[13]);
7    }
8    return Transform(a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7], 
9                     a[8], a[9], a[10], a[11], a[12], a[13], a[14], a[15]);
10}
Copy

The result: 64 bytes of adjacent heap memory leaked back to the page through XRRay's origin and direction properties.

Impact and Severity

CVE-2025-12443 received a CVSS 4.3 (Medium) rating. The vulnerability enables:

• Information disclosure: Heap contents leak to attacker-controlled JavaScript
• Potential ASLR bypass: Leaked pointers could help defeat address space layout randomization
• Cross-origin data leakage: Memory from other tabs or browser components might be exposed

The Scale Is Hard to Overstate

This vulnerability affected every platform where Chromium-based browsers run:

Chromium-based browsers collectively command over 70% of the global browser market, including:

• Google Chrome (~3 billion users)
• Microsoft Edge (~200 million daily active users)
• Brave (~60+ million monthly users)
• Opera (~300+ million users)
• Vivaldi, Arc, Comet, Atlas, and dozens of other browsers
• Embedded browsers in Electron apps, mobile apps, and IoT devices

To put that in perspective: if you're reading this on a device connected to the internet, there's a better than two-in-three chance you're using a browser that was vulnerable to this bug before the patch.

The WebXR angle adds another dimension. VR and AR applications are increasingly used for sensitive scenarios: virtual banking interfaces, healthcare training, remote collaboration with screen sharing, industrial control system visualization. A memory leak in this context could expose data far more sensitive than typical browsing activity.

Affected Versions

Timeline: From Discovery to Fix in 13 Days

The vulnerability existed in the Chromium codebase for approximately seven months before Aisle's autonomous analyzer identified it:

The turnaround from initial report to stable release was just 13 days, a testament to the Chromium team's responsive security process. We commend Alexander Cooper and the WebXR team for their swift and thorough remediation.

The Fix: Recalculate, Don't Truncate

The Chromium team's fix addresses the root cause by recalculating the matrix from authoritative internal state whenever the cached array is missing or detached:

C
1// third_party/blink/renderer/modules/xr/xr_rigid_transform.cc (FIXED)
2NotShared<DOMFloat32Array> XRRigidTransform::matrix() {
3    EnsureMatrix();
4    if (!matrix_array_ || matrix_array_->IsDetached()) {
5        matrix_array_ = transformationMatrixToDOMFloat32Array(*matrix_);
6    }
7    return matrix_array_;
8}
Copy

This approach aligns with the WebXR specification, which mandates recomputing detached matrices rather than returning empty or stale data. The fix also upgrades the DCHECK to a CHECK, ensuring the length invariant is enforced in production builds:

C
1// third_party/blink/renderer/modules/xr/xr_utils.cc (FIXED)
2gfx::Transform DOMFloat32ArrayToTransform(NotShared<DOMFloat32Array> m) {
3    CHECK_EQ(m->length(), 16u);  // Now enforced in release builds
4    return gfx::Transform::ColMajorF(m->AsSpan().first<16>());
5}
Copy

Additionally, the Chromium team removed an unused helper function (WTFFloatVectorToTransform) that exhibited the same vulnerable pattern, preventing future misuse.

Aisle's Analysis Guided a More Comprehensive Fix

Aisle's original vulnerability report didn't stop at the immediate bug. The "Similar Findings" section of our disclosure proactively identified two additional code locations exhibiting the same unsafe pattern:

1. XRView::projectionMatrix(): Returned a zero-length array when detached, mirroring the XRRigidTransform::matrix() behavior. Located at third_party/blink/renderer/modules/xr/xr_view.cc lines 79-85.
2. WTFFloatVectorToTransform(): An unused helper at third_party/blink/renderer/modules/xr/xr_utils.cc that forwarded vectors to ColMajorF with only a DCHECK on size, creating a latent vulnerability waiting to be triggered.

The Chromium team's fix addressed all three issues in the same patch, following our report's analysis. XRView::projectionMatrix() was updated to recalculate the matrix when detached (just like the primary fix), and WTFFloatVectorToTransform() was removed entirely to prevent future misuse.

This is a pattern we see repeatedly: Aisle's analyzer doesn't just find individual bugs, it identifies vulnerability classes and their repeated occurrences in a codebase. By building a stack model of how data flows through the codebase, we can trace unsafe patterns across multiple call sites and flag them all at once. The result is a more comprehensive fix that hardens the entire attack surface rather than patching one hole while leaving others open.

Mitigation for Users

Update your browser immediately. This vulnerability affects all Chromium-based browsers:

• Chrome: Update to version 142.0.7444.59 or later
• Edge: Ensure you're running the latest version (check in Settings → About)
• Brave, Opera, Vivaldi, Arc, and other Chromium-based browsers: Update to versions incorporating the Chromium fix from October 16, 2025

To check your version, navigate to your browser's Settings or About page. Most browsers auto-update, but manual checks ensure you're protected.

For users unable to update immediately:

• WebXR content requires explicit user permission to enter immersive sessions
• The vulnerability requires active JavaScript execution from a malicious page
• Standard browser isolation (site isolation, sandbox) limits the severity of any leaked data

Why Emerging Tech Is a Security Minefield

WebXR was first drafted as a W3C specification in 2018. The Chromium implementation has been under active development ever since, with the codebase changing rapidly as the spec evolves and new hardware capabilities emerge. This is the nature of emerging technology: it's a moving target.

Consider what WebXR has to handle:

• Complex 3D transformation mathematics
• Real-time sensor data from headsets and controllers
• Low-latency rendering pipelines
• New JavaScript APIs for spatial computing
• Integration with platform-specific VR/AR runtimes

Each of these represents a fresh attack surface. Each interaction between components creates potential for invariant violations. The code that caused CVE-2025-12443 was written in March 2025, barely seven months before we found it. In that time, the WebXR module received dozens of additional commits, each potentially introducing new bugs or new paths to existing ones.

Google has more security resources than almost any organization on Earth. They invented the browser sandbox. They pioneered bug bounty programs. They run ClusterFuzz, one of the most sophisticated continuous fuzzing operations in existence. Their Chromium security team includes world-renowned researchers.

And yet, this bug shipped to over 4 billion devices across the entire Chromium ecosystem.

This isn't a criticism of Google's security team, which includes some of the best in the industry. It's a statement about the fundamental economics of software security. Human review doesn't scale to the rate at which code is being written. New features mean new attack surface. Emerging technology means immature code paths that haven't been battle-tested. The asymmetry between attackers (who need to find one bug) and defenders (who need to find all of them) grows worse every year.

The Case for Autonomous Security

CVE-2025-12443 illustrates patterns that are particularly hard for human reviewers to catch:

1. DCHECK is not a security boundary. Assertions that only fire in debug builds cannot protect against malicious input in production. This is well-known, yet the pattern persists because it's easy to forget during review.
2. Cache invalidation creates security gaps. When cached data can be externally invalidated (detached buffers, freed memory, expired tokens), every fallback path must maintain every safety invariant. Humans struggle to trace these cross-cutting concerns.
3. Multi-step exploitation paths are invisible to spot checks. The specific sequence required to trigger this bug (create, cache, detach, reuse) involves multiple API calls and timing. It's the kind of thing a fuzzer might find eventually, but targeted, intelligent analysis finds orders of magnitude faster.

Aisle's analyzer builds a stack model of the codebase: understanding not just what functions do, but how data flows between them, what invariants are assumed, and where those assumptions might be violated. This enables exploration of complex interaction patterns that are easy for human reviewers to overlook.

Aisle's mission is to secure the world's critical software infrastructure. This discovery in Chromium, following our recent work on OpenSSL and Samba vulnerabilities, demonstrates that autonomous security analysis isn't a nice-to-have. For protecting software that billions of people depend on daily, it's becoming essential.

Responsible Disclosure

Aisle Research coordinated disclosure with the Chromium security team throughout this process. We received a bounty through Google's Vulnerability Rewards Program, reflecting the bug's classification as a renderer-based information disclosure issue. We are grateful for the Chromium team's professionalism and rapid response.

Learn More

Interested in Aisle's autonomous security platform? Visit us at aisle.com or reach out to [email protected].

Technical References:

• CVE-2025-12443 on NVD
• Chromium Issue 452071845
• Fix CL: chromium-review.googlesource.com/7046576
• Chrome 142 Release Notes

Report credit: Igor Morgenstern, Aisle Research