Via a Crafted HTML Page: How Attackers Build Browser Exploits

When Google patched CVE-2026-5281, a use-after-free in Chrome's Dawn WebGPU component, the NVD description noted that a remote attacker who had compromised the renderer process could execute arbitrary code via a crafted HTML page. That final clause — "via a crafted HTML page" — appears in dozens of Chrome CVE descriptions every year. It is easy to skim past. It should not be. The browser is the most broadly deployed piece of software on the planet, and the HTML page is its primary attack surface. Understanding what a crafted HTML page actually is, and what goes into building one, is essential context for anyone tracking browser-layer threats.

This article covers the anatomy of a malicious HTML page: how attackers structure exploit code, how they stabilize memory layout, how they deliver their pages to targets, and how individual techniques chain together into full compromise paths. Every section includes concrete examples tied to real techniques observed across Chrome, Chromium-based browsers, and adjacent targets.

What "Crafted" Actually Means

A crafted HTML page is not simply a page with bad intent. It is a page that has been engineered to trigger a specific, often very precise behavior inside the browser's rendering engine, JavaScript engine, or graphics pipeline. The attacker is not just writing HTML — they are writing code that interacts with the internal memory allocator of a complex multi-process application, controlling how objects are created, used, and freed in order to produce an exploitable memory state.

The crafting part is the hard part. A vulnerability like a use-after-free does not exploit itself. The browser has to be driven into the exact sequence of operations that creates a dangling pointer, and then the attacker has to ensure that something useful — their shellcode, a vtable pointer, an object with attacker-controlled fields — sits at the memory address the dangling pointer now references. Building that sequence reliably, across operating systems, browser versions, and user machines with different heap states, requires significant engineering work.

Consider a simplified example. Imagine a browser component maintains a list of font-feature mappings. When a JavaScript loop adds many entries to that map and then deletes some while an iterator is still active, the map's internal storage may be reallocated. A raw pointer held by the iterator now points to freed memory. That is the vulnerability. But the attacker also needs to ensure that by the time the freed memory is accessed, it has been filled with controlled data. That is what the crafted page does — it allocates the right objects, in the right sizes, at the right time, to replace the freed memory before the dangling pointer is used.

Memory Corruption Primitives: The Building Blocks

Most browser exploits begin with one of a small set of memory corruption primitives. Understanding these is the prerequisite for understanding why crafted pages are structured the way they are.

Use-After-Free

A use-after-free (UAF) occurs when code continues to reference memory after it has been freed by the allocator. In a browser context, this typically happens when a JavaScript object causes a native C++ object to be freed, but another reference to that object's memory address remains valid and is later read or written. The attacker's goal is to allocate a new object of the same size at the freed address before the dangling pointer is used — a technique called heap feng shui or heap grooming.

CVE-2026-5281, the Dawn UAF at the center of the recent Chrome patch, follows this pattern. Dawn is Chrome's implementation of the WebGPU API — a modern low-level graphics interface that allows JavaScript to issue commands directly to the GPU pipeline. UAFs in GPU API implementations are particularly attractive to attackers because the affected objects often control rendering pipelines, shader execution, or memory-mapped GPU resources, providing strong primitives for memory reads and writes.

Earlier in 2026, CVE-2026-2441 demonstrated a closely related UAF in Chrome's Blink CSS engine. A FontFeatureValuesMapIterationSource object held a raw pointer to an internal FontFeatureAliases hash map. When JavaScript mutated the map during iteration — by calling set() or delete() — the hash map would rehash, allocating new storage and freeing the old. The raw pointer became a dangling reference. Each call to FetchNextItem() then read from freed memory. The crafted page that triggers this chains three independent JavaScript patterns — manual iteration with concurrent deletion, force-reallocation loops, and requestAnimationFrame-based triggering — together with heap grooming that allocates 50 same-sized @font-face rules to make the heap layout predictable.

Type Confusion

Type confusion vulnerabilities occur when a component treats an object of one type as if it were a different type. In V8, Chrome's JavaScript and WebAssembly engine, type confusion flaws have recurred across multiple CVEs. CVE-2025-6554 involved leaking Chrome's internal "TheHole" value — a sentinel used by V8 to represent uninitialized array slots — out of the engine's controlled context. Once the attacker can observe and manipulate TheHole, it opens a path to memory corruption because V8's assumptions about object types and array layouts break down.

Type confusion vulnerabilities in V8 are particularly powerful because V8 optimizes frequently executed JavaScript functions using a just-in-time (JIT) compiler. The JIT compiler makes type assumptions for performance. A type confusion flaw can cause the JIT to generate native machine code that treats a JavaScript float array as an object array, giving the attacker a read/write primitive into the process's address space. The crafted page exploiting this typically contains JavaScript that runs in a hot loop — executing many thousands of times to trigger JIT compilation — followed by code that introduces the confused type at the critical moment.

Out-of-Bounds Read and Write

Out-of-bounds (OOB) memory access occurs when an array index or pointer arithmetic goes beyond the allocated buffer's boundaries. In Chrome's graphics stack, CVE-2025-5419 involved out-of-bounds read and write conditions in V8 that allowed remote attackers to trigger heap corruption via crafted HTML pages. CVE-2025-14174, discovered in late 2025, was an OOB memory access in ANGLE (Almost Native Graphics Layer Engine) — Chrome's translation layer between WebGL/WebGPU calls and native graphics APIs. The crafted page loads specially structured WebGL content: texture data engineered to exceed buffer boundaries, overwriting adjacent heap structures including vtable pointers of C++ objects, redirecting control flow to an attacker-controlled ROP chain.

Heap Spraying and Heap Grooming

Memory corruption vulnerabilities rarely produce deterministic, reliable exploits on their own. The heap — the region of memory where objects are dynamically allocated and freed — is not a predictable structure. Its state at the moment the vulnerability is triggered depends on how many allocations and frees have occurred during the browser session, in what order, and at what sizes. An attacker who triggers a UAF on a clean heap may find the freed memory has been reallocated by the browser's own internal operations before the exploit code can use it. Heap spraying and heap grooming are the techniques used to impose order on this chaos.

Heap Spraying

Heap spraying works by flooding the heap with attacker-controlled data. A JavaScript loop allocates a large number of identically sized objects, each containing the attacker's shellcode or a controlled data pattern. The goal is to ensure that when a memory corruption flaw is triggered and execution is redirected to an arbitrary heap address, there is a high probability of landing on one of the sprayed objects.

In browser exploits, the spray is typically implemented in JavaScript by concatenating strings or creating typed arrays. The technique was first widely used against Internet Explorer in 2005 and has evolved continuously since. Modern heap sprays often target specific size classes to maximize density, use NOP sleds (sequences of harmless instructions or data values that precede the actual shellcode), and align payloads to predictable addresses based on the allocator's behavior. For example, on x86 architectures, the byte 0x0c maps to both a valid heap address and a NOP-like instruction, which is why 0x0c0c0c0c appears so often in older exploit sprays.

// Simplified heap spray concept in JavaScript
// Attacker creates many large typed arrays, each holding controlled data
// Actual exploits use precise sizing based on the target allocator

const SPRAY_COUNT = 1000;
const CHUNK_SIZE  = 0x10000; // 64 KB — matches a common allocator size class
const spray       = [];

for (let i = 0; i < SPRAY_COUNT; i++) {
    const buf = new ArrayBuffer(CHUNK_SIZE);
    const view = new Uint32Array(buf);
    // Fill with shellcode address or NOP pattern
    view.fill(0x0c0c0c0c);
    spray.push(buf);
}

// Trigger the memory corruption vulnerability here.
// With the heap saturated, freed memory is likely occupied by
// one of the spray chunks, and execution will land on controlled data.

Modern browser allocators have hardened significantly against naive heap sprays. PartitionAlloc, Chrome's allocator, separates objects of different types into distinct memory partitions, making it harder for an attacker to replace a freed C++ object with a JavaScript-controlled buffer. This is why modern exploits have moved toward heap grooming, which is more surgical.

Heap Grooming

Heap grooming — also called heap feng shui — is a more precise approach. Rather than flooding the heap, the attacker carefully controls the sequence and sizes of allocations and frees to produce a specific heap layout before triggering the vulnerability. The goal is to ensure that when a target object is freed, the freed slot is immediately adjacent to — or coincident with — an allocation the attacker controls.

In the CVE-2026-2441 proof-of-concept code, the page allocates 50 same-sized @font-feature-values rules before triggering the UAF. This is grooming: filling the allocator's free list with objects of the correct size class so that when the vulnerable object is freed, the attacker's replacement allocation is selected from that same free list.

/* Simplified grooming pattern — not live exploit code
   Attacker allocates objects of target size to fill allocator free list */

function groomHeap(targetSizeClass, count) {
    const objects = [];
    for (let i = 0; i < count; i++) {
        // Create CSS objects or JS objects matching target size
        const rule = new CSSStyleSheet();
        rule.insertRule(`@font-face { font-family: "g${i}"; src: local("a"); }`);
        objects.push(rule);
    }
    return objects;
}

// Step 1: Groom the heap
const groom = groomHeap(TARGET_SIZE, 50);

// Step 2: Trigger the vulnerability to free the target object
triggerVulnerability();

// Step 3: Immediately allocate a replacement object of the same size
// The allocator is likely to return the just-freed slot
const replacement = allocateControlledObject(TARGET_SIZE);

Delivering the Page: How Victims Reach the Exploit

Building the exploit is only half the problem. The attacker also has to get the victim's browser to load the crafted page. There are several established delivery mechanisms, each with different targeting precision and operational requirements.

Drive-By Downloads and Malvertising

A drive-by download is the simplest model: the victim visits a page, the page triggers the exploit, and code executes without any further user action. The attacker needs only a URL and a way to direct traffic to it. Malvertising achieves this at scale by injecting the exploit page into the ad ecosystem. Because ad networks serve JavaScript from third-party origins across millions of sites, a malicious ad creative can redirect visitors to an exploit landing page hosted elsewhere. The victim sees a legitimate publisher's site, but their browser is loading attacker-controlled JavaScript in a background iframe or through a redirect chain.

This delivery path is particularly effective because it requires no compromise of any site the victim trusts. The legitimate site is only a vehicle. The malicious content is served from the attacker's infrastructure, often through redirect chains that pass through multiple domains to frustrate URL reputation systems.

Watering Hole Attacks

Watering hole attacks are more targeted. The attacker identifies websites that a specific organization or community visits regularly — an industry portal, a government contractor's intranet-facing site, a conference registration system — and injects malicious code into the legitimate site. When members of the targeted group visit, their browsers execute the attacker's content. The trust relationship with the familiar site prevents suspicion.

APT groups have used watering hole attacks extensively. The 2012 infection of the American Council on Foreign Relations website used an Internet Explorer zero-day that was selectively triggered only for visitors using IE with specific language settings — a targeting mechanism built into the crafted page's fingerprinting logic. In 2015, the Forbes "Thought of the Day" feature served zero-day exploits for Internet Explorer and Adobe Flash to selected visitors. The exploit page checks browser version, operating system, plugins, and sometimes IP address before deciding whether to deliver the payload, reducing noise and avoiding burning the zero-day on unintended targets.

Spear Phishing with Crafted Links

Targeted delivery via a spear-phishing email or message is the most surgical approach. The attacker sends a crafted link directly to a specific individual. The link may point to the exploit page directly, or it may redirect through a series of URLs before landing on it. Because the attacker controls exactly who receives the link, this delivery method is often paired with the most sensitive zero-day exploits — the kind commercial surveillance vendors develop for highly targeted operations against journalists, dissidents, or government officials.

Understanding how commercial surveillance vendors build and weaponize exploit chains helps explain why this delivery mechanism is so common in high-end targeted operations. The crafted HTML page is rarely a standalone artifact in these campaigns — it is one component in a multi-stage infection chain that begins with a link sent to a specific phone number or email address and ends with full device compromise.

If you want broader context on who builds and sells these capabilities, the NoHacky analysis of commercial surveillance vendors (CSVs) covers the ecosystem in detail.

HTML Smuggling: Evading Perimeter Controls

HTML smuggling is a distinct but related technique that exploits legitimate browser features to assemble malicious payloads inside the victim's machine rather than delivering them over the network as recognizable file attachments. The technique abuses the HTML5 download attribute and JavaScript's Blob API to construct a file from encoded data embedded in the page itself.

The mechanism works as follows. The attacker encodes a malicious payload — an executable, a ZIP archive, an LNK shortcut — as a base64 string inside the HTML page. When the browser renders the page, JavaScript decodes the base64 string, creates a Blob object containing the binary data, generates an object URL pointing to that Blob, and assigns it to an anchor element with the download attribute. The browser then downloads the file directly from memory to the user's Downloads folder, bypassing the network entirely. From the perspective of a web proxy or email gateway, the traffic looks like a page load — not a file download.

<!-- Simplified HTML smuggling structure
     Actual attacks obfuscate the base64 payload and auto-trigger the download -->

<script>
  // Payload is encoded as base64 within the page
  const encoded = "TVqQAAMAAAAE..."; // truncated base64 of actual payload

  function smuggle() {
    const binary = atob(encoded);
    const bytes  = new Uint8Array(binary.length);
    for (let i = 0; i < binary.length; i++) {
      bytes[i] = binary.charCodeAt(i);
    }
    const blob   = new Blob([bytes], { type: "application/octet-stream" });
    const url    = URL.createObjectURL(blob);
    const link   = document.createElement("a");
    link.href     = url;
    link.download = "invoice.pdf.exe"; // double extension disguise
    link.click();
    URL.revokeObjectURL(url);
  }

  window.addEventListener("load", smuggle);
</script>

Microsoft documented a significant surge in HTML smuggling use across banking malware campaigns attributed to DEV-0238 (Mekotio) and DEV-0253 (Ousaban), targeting Brazil, Mexico, Spain, Peru, and Portugal. The same technique was used by NOBELIUM in targeted spear-phishing operations before being picked up more broadly by threat actors delivering AsyncRAT and NjRAT. Tools like AutoSmuggle automate the process of embedding executables or archives inside SVG and HTML files, lowering the barrier to entry considerably.

More recent campaigns have layered CAPTCHA prompts on top of the smuggling page — not for user verification, but to prevent automated URL scanners from reaching the payload delivery code, since scanners typically do not solve CAPTCHAs. The downloaded file is often a Windows LNK shortcut disguised as a PDF, which triggers a PowerShell download chain when executed.

SVG, Canvas, and the Expanding Attack Surface

SVG files are a distinct delivery vector that receives less attention than HTML but has grown significantly as a phishing and exploit container. Unlike JPEG or PNG files, SVG is an XML-based vector format that natively supports embedded JavaScript via <script> elements and HTML content via the <foreignObject> element. An attacker can embed a fully functional phishing form — visually mimicking a Microsoft or Google login page — directly inside an SVG file. When a victim opens the file from an email attachment in a browser, the JavaScript runs and the form accepts credentials.

The <foreignObject> element also allows attackers to embed encoded URLs that automatically redirect the browser when the file is opened. Because SVG attachments were not historically associated with active content by many email filters, this technique has seen elevated adoption among phishing campaigns distributing Agent Tesla and XWorm.

The HTML5 Canvas element and WebGL are increasingly present in browser exploit pages as components that interact with GPU memory in ways that create interesting memory corruption opportunities. The shift toward WebGPU — which provides far lower-level access to the GPU pipeline than WebGL — expands this attack surface considerably. Dawn, the component affected in CVE-2026-5281, is Chrome's WebGPU implementation. As WebGPU becomes more widely supported and deployed, vulnerabilities in Dawn and equivalent components in other browsers are likely to increase in operational value.

Browser Fingerprinting and Exploit Gating

A sophisticated crafted HTML page does not blindly deliver its payload to every visitor. It fingerprints the visitor first. This serves two purposes: targeting precision and operational security. Delivering a zero-day to a security researcher's sandbox wastes the exploit and may result in discovery and patching. Fingerprinting allows the page to serve benign content to anyone who does not match the target profile.

A typical fingerprinting block in a crafted page checks the browser version against a list of vulnerable versions, verifies the operating system matches the expected target platform, checks for the presence or absence of certain browser plugins or extensions, and may inspect the screen resolution or GPU renderer string to distinguish real hardware from a virtual machine. Some advanced campaigns use timing attacks to detect sandbox environments — real user machines have measurable latency patterns from user interactions, whereas automated sandboxes process pages at non-human speeds.

// Simplified fingerprint gate — attacker only delivers payload if conditions match
function shouldExploit() {
    const ua = navigator.userAgent;

    // Check for target browser and version range
    const chromeMatch = ua.match(/Chrome\/(\d+)\./);
    if (!chromeMatch) return false;
    const version = parseInt(chromeMatch[1]);
    if (version < 130 || version > 145) return false;

    // Check OS
    if (!ua.includes("Windows NT 10.0") && !ua.includes("Macintosh")) return false;

    // Check for sandbox indicators
    if (navigator.webdriver) return false;          // Selenium / headless Chrome
    if (screen.width < 800) return false;          // typical sandbox resolution
    if (navigator.plugins.length === 0) return false; // headless has no plugins

    return true;
}

if (shouldExploit()) {
    loadExploitStage();
} else {
    // Serve a decoy page
    window.location.href = "https://legitimate-looking-site.example.com/";
}

More advanced targeting uses IP geolocation checks to ensure the exploit is only delivered to visitors from specific countries, organizations, or network ranges. In the 2012 Council on Foreign Relations attack, the exploit was gated on browser language settings — only certain locale configurations triggered the payload.

From Renderer to System: Chaining Sandbox Escapes

This is where CVE-2026-5281 requires its prerequisite. Chrome's multi-process architecture isolates the renderer — the process that handles JavaScript execution, HTML parsing, and CSS layout — inside a sandbox. Code executing in the renderer cannot directly read or write the file system, make network connections, or interact with the operating system. A renderer-level RCE vulnerability, on its own, gives the attacker control of a sandboxed process. That is significant but not sufficient for a full system compromise.

CVE-2026-5281 is described as requiring a compromised renderer process. It does not create that compromise itself — it extends it. The attack chain begins with a prior exploit that achieves renderer RCE. CVE-2026-5281 then provides a path to further exploitation from that sandboxed position, via the Dawn WebGPU implementation. A similar chain dynamic appeared in CVE-2026-2441, where the chain documented in the proof-of-concept code runs: renderer RCE via the CSS UAF, followed by a Mojo IPC exploit targeting the browser process, followed by a kernel exploit for full system compromise, leading to malware or spyware installation, file system access, and lateral movement.

Mojo is Chrome's inter-process communication framework. The browser process — which is not sandboxed — communicates with renderer processes through Mojo IPC channels. If the attacker controls the renderer, they can send IPC messages to the browser process. A logic bug in how the browser process validates those messages can allow the renderer to trigger actions it should not be permitted to trigger, such as writing to the file system or launching an external executable. CVE-2025-2783, discovered by Kaspersky in March 2025, was exactly this class of bug: an incorrect handle in Mojo on Windows allowed a compromised renderer to perform a sandbox escape. The full attack chain documented in related research mirrors the pattern exactly.

Obfuscation and Evasion Inside the Page

A crafted exploit page is almost never written in readable JavaScript. It is obfuscated aggressively, both to hinder analysis and to evade signature-based detection systems. Common obfuscation techniques found in browser exploit pages include string encoding (base64, hexadecimal, Unicode escape sequences), variable name randomization, control flow flattening (replacing if/else chains with dispatch tables and state machines), dead code insertion, and eval-based string reassembly that constructs function calls from fragments at runtime.

Some campaigns have introduced polymorphic page generation, where the exploit infrastructure generates a unique obfuscation pattern for each visitor. This means static signatures are essentially useless against these pages — each delivery is syntactically unique even if the underlying exploit logic is identical. IBM's 2025 threat report noted that the average time to identify a breach enabled by this kind of AI-generated polymorphic malware had grown to 276 days, reflecting the effectiveness of these evasion techniques against conventional detection.

// Example of a simple obfuscation pattern — string splitting and eval
// Real exploit code uses far more complex techniques including
// control flow flattening and per-visitor randomization

(function() {
    // Function name and string contents are reassembled at runtime
    var _0x1a2b = ["log", "console", "Hello"];
    var _fn     = _0x1a2b[1];
    var _meth   = _0x1a2b[0];
    var _msg    = _0x1a2b[2];

    // Equivalent to: console.log("Hello")
    window[_fn][_meth](_msg);
})();

// In a real exploit, the string array contains function names,
// API calls, and encoded shellcode fragments that are only
// assembled into executable form at runtime

Beyond JavaScript obfuscation, exploit delivery infrastructure uses HTTPS consistently to prevent network-level inspection of the page's contents. In some campaigns documented in late 2024, the exploit page payload was retrieved in encrypted form from a blockchain smart contract, making the infrastructure highly resilient to takedowns. The page itself requests the payload from a blockchain query; because blockchain transactions are public and immutable, the payload delivery mechanism cannot be blocked by domain takedowns.

ClickFix and Social Engineering Layers

Not all crafted HTML pages deliver technical exploits. Some rely on social engineering to achieve execution. The ClickFix technique, which became widespread in 2024 and continued through 2025, uses a crafted landing page that presents a fake error message — typically impersonating a browser update notification, a CAPTCHA, or a document preview failure — and instructs the victim to paste a command into the Windows Run dialog or macOS Terminal to "fix" the issue.

The command is pre-populated in the clipboard by JavaScript on the page. When the victim pastes and executes it, they run a PowerShell or bash script that downloads and executes the actual payload. The page itself contains no exploit code — it exploits the user rather than the browser. This approach is effective because it bypasses all browser sandboxing, requires no zero-day vulnerability, and leverages the victim's trust in the error message's framing. The ClearFake campaign used this technique at scale, deploying it through compromised WordPress sites and, in an evolution documented in 2025, embedding the landing page delivery mechanism in Ethereum smart contracts to resist takedowns.

Defensive Posture: What Actually Helps

Defending against crafted HTML page exploits requires layered controls across multiple points in the delivery and execution chain. No single control is sufficient.

Browser updates are the most important single control. Google patched eight actively exploited Chrome zero-days in 2025, all of which were added to CISA's Known Exploited Vulnerabilities catalog. Federal agencies face a 21-day remediation deadline for KEV entries; private organizations should treat these with similar urgency. Users who have opted into Chrome's auto-update will receive patches passively, but must restart the browser to apply them — a step that many defer for days or weeks.

Disabling WebGL and WebGPU via Group Policy in enterprise environments reduces the attack surface for the growing class of graphics-pipeline vulnerabilities. This may break some web applications, so it requires testing, but for high-security environments where the threat model includes nation-state or commercial-surveillance-vendor attacks, it is a meaningful reduction in exposure.

Browser isolation technologies — which render web content in a remote, containerized environment and stream only a visual representation to the user's endpoint — address the entire class of renderer RCE and sandbox escape vulnerabilities by ensuring that no browser code executes on the endpoint at all. This is operationally expensive but represents the strongest technical control against crafted-page exploits.

Content Security Policy (CSP) headers, when properly configured, restrict what JavaScript can execute on a page and what origins it can load resources from. While CSP is a server-side control that only protects pages you operate, not pages you visit, it is relevant to the watering hole attack scenario: a site operator with strong CSP makes it harder for an attacker who has compromised the site to inject arbitrary scripts. CSP headers with script-src 'nonce-{random}' or strict-dynamic prevent inline script injection without a server-generated nonce.

Endpoint detection and response tools that monitor for anomalous renderer behavior — unexpected child process spawning, memory pages marked executable in unusual regions, IPC patterns inconsistent with normal browser operation — can flag active exploitation attempts that have already passed the perimeter. Signature-based approaches are inadequate against polymorphic and per-visitor-unique exploit pages.

Key Takeaways

1. A crafted HTML page is precision-engineered: It controls allocator behavior, browser fingerprinting, exploit delivery, and often payload staging through a sequence of carefully structured JavaScript operations. The word "crafted" reflects significant engineering effort, not casual modification.
2. Memory corruption exploits require stabilization: Use-after-free, type confusion, and out-of-bounds vulnerabilities do not self-exploit. Heap spraying and heap grooming are the techniques attackers use to make exploitation reliable across different machines and browser states.
3. Delivery is as important as the exploit itself: Watering holes, malvertising, and targeted spear-phishing links each offer different targeting precision. The most sensitive zero-days are deployed through the most targeted delivery, not broadcast at scale.
4. HTML smuggling bypasses perimeter controls entirely: By assembling payloads inside the browser using legitimate APIs, smuggling pages produce no recognizable attachment at the network layer. Endpoint-level behavioral detection is the appropriate response.
5. Sandbox escapes are required for full compromise: Renderer RCE alone does not escape Chrome's sandbox. Full system compromise requires chaining a second vulnerability — typically a Mojo IPC logic bug or a kernel exploit — after the initial renderer exploit.
6. Patching browser updates promptly remains the highest-leverage single control: The eight Chrome zero-days patched in 2025 all had known exploits in the wild at the time of patching. Users running unpatched versions remained exposed for weeks or months in many cases.

The phrase "via a crafted HTML page" appears so often in Chrome CVE advisories because the browser's attack surface is genuinely vast: a JavaScript engine, a graphics stack serving GPU APIs, an IPC framework bridging sandboxed and unsandboxed processes, and a rendering engine parsing the full complexity of HTML and CSS — all exposed to untrusted content from every site on the web. Each of those components has a history of vulnerabilities, and each can be triggered through a page a victim is socially engineered or technically directed to visit. Building defenses against this requires understanding the mechanics of how those pages work.