JULY 31, 2026
Chrome V8 Out-of-Bounds Access Fixed in CVE-2026-0902
Chrome V8 out-of-bounds access in CVE-2026-0902 let a remote attacker read memory via a crafted HTML page, fixed in 144.0.7559.59.
By Entalogics Team · Cybersecurity
Chrome V8 Out-of-Bounds Access in CVE-2026-0902
Chrome fixed a V8 out-of-bounds access bug tied to Chromium issue 469143679. The issue title says it plainly: "JSON.parse(): Out-of-bounds access on DescriptorArray". That is the kind of bug that starts small in one parser path and ends with memory safety risk in a browser engine.
The issue was marked P1 and S2, then assigned CVE-2026-0902. Google’s Chrome Releases bulletin says the bug was reported on 2025-12-16, and it carries a [$4000] reward.
CVE-2026-0902 was fixed before most users saw the bulletin, but the bug class matters: a parser edge case became an out-of-bounds memory read.
What Chromium Fixed
The Chromium issue page lists the bug as Fixed. The linked V8 change is commit [2ebb924f4a51ec8022c1413775fc2e41736cc1a6](https://chromium.googlesource.com/v8/v8/+ /2ebb924f4a51ec8022c1413775fc2e41736cc1a6), and it points back to [Fixed: 469143679](https://chromium.googlesource.com/v8/v8/+ /2ebb924f4a51ec8022c1413775fc2e41736cc1a6).
The commit message gives the core bug pattern: [GC could shrink the descriptor array; prevent reading beyond the limit](https://chromium.googlesource.com/v8/v8/+ /2ebb924f4a51ec8022c1413775fc2e41736cc1a6). In plain terms, the loop handling the array needed to stop early on every path. If it did not, V8 could keep reading after the array had become smaller.
That kind of bug is dangerous because it does not need a large exploit chain. It only needs a crafted input that reaches the wrong edge case in runtime code.
[The fix](https://chromium.googlesource.com/v8/v8/+ /2ebb924f4a51ec8022c1413775fc2e41736cc1a6) was about one thing: stop the loop before it reads beyond the limit.
The review record for the V8 change is 7361936, which shows the patch moved through the normal Chromium review flow before landing.
CVE-2026-0902 and the Affected Chrome Version
OSV says CVE-2026-0902 was published 2026-01-20. It also says the bug allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page.
That matters for defenders because the attack surface is not a local developer tool or a niche extension path. It is browser content handling. A user only needs to load a malicious page.
OSV also says the issue was fixed in 144.0.7559.59. Google’s release note says Chrome 144.0.7559.59/60 includes the fix. If you run Chrome in managed fleets, that version line is the one to verify.
Ship faster with senior engineers
Direct collaboration, AI-augmented delivery, and no agency markup.
Get in touchHow the V8 Bug Became a Memory Read
This is a browser engine bug, but the mechanics are understandable.
JSON.parse() processes structured data. In this case, the vulnerable path touched a DescriptorArray, a V8 internal structure that tracks object properties. The commit message says a [GC](https://chromium.googlesource.com/v8/v8/+ /2ebb924f4a51ec8022c1413775fc2e41736cc1a6) could shrink the descriptor array during execution.
That creates a race with the loop that is walking the array. If the loop keeps using the old boundary, it can read past the end. That is the classic out-of-bounds pattern: state changes under your feet, but the code keeps trusting the old size.
For browser teams, the lesson is not just “fix this one bug.” It is to treat internal object lifetime, garbage collection, and bounds checks as one security surface. When those assumptions drift apart, memory safety falls apart fast.
Why This Matters for Browser and AppSec Teams
A browser bug like this affects more than the browser process itself. It changes how teams should think about client-side risk, especially when users open untrusted content all day.
If your org builds browser extensions, web apps that lean on complex client logic, or internal tools that process arbitrary JSON and HTML, this is a reminder to test the edges. A parsing path that looks harmless in code review can still reach engine internals you do not control.
For teams looking at the broader pattern of AI-assisted and browser-based development risk, our guide on AI coding tools and AppSec risk is a useful companion. It covers what to audit when generated code starts touching parser-heavy paths.
If you are asking whether your own release process catches browser-engine and client-side runtime issues fast enough, that is the point where a AI Code Security Audit becomes practical: not as a pitch, but as a way to check whether your code review and dependency triage would spot this class of bug before users do.
What to Do Next
Start with the basics.
Patch Chrome to 144.0.7559.59/60. Confirm your fleet policy enforces that line, not just “latest available.” Watch for any products that embed Chromium and may lag behind the browser release channel.
Then review any code that parses untrusted JSON or HTML, especially code that passes data into embedded runtime components. Look for assumptions about size, lifetime, and mutation during iteration. Those assumptions are where out-of-bounds reads begin.
If you ship browser-facing software, add a check for engine updates to your patch window, not your quarterly cleanup list. And if your team handles high-risk client-side code, test how fast you can identify a Chromium issue, map it to your environment, and roll the fix.
The takeaway is simple: treat browser engine updates as security work, not product maintenance. When V8 ships a bounds fix, your job is to verify exposure, patch fast, and re-check the code paths that rely on those same assumptions.