The 'outside the sandbox' framing in CVE-2026-76017 needs scrutiny before you escalate this to critical priority. Chromoting runs as a separate host process with its own isolation boundary — it is not inside the Chromium content sandbox that renders web pages, but it also isn't equivalent to a kernel-level compromise. The key constraint is the trigger: 'crafted network traffic.' This typically means you need a man-in-the-middle position on the Chromoting stream or local access to send packets to the localhost listener. That substantially limits the attack surface compared to a renderer bug that triggers simply by visiting a webpage.
The EPSS score of 0.00358 reflects this — exploitation requires positional advantage, not passive web browsing. If you're already in a position to send crafted traffic to Chromoting, you likely have deeper access already. However, don't undersell the blast radius: once code execution lands in the Chromoting host, it has full access to clipboard content, screen capture buffers, input injection, and session state. An attacker doesn't need to pivot — they've already reached the most sensitive operational data on the endpoint.
More concerning than the CVSS 8.8 versus 'Critical' discrepancy is the pattern. Historical Chromoting UAFs cluster around object lifetime mismatches during session teardown and reconnection sequences. This appears to be a recurring failure mode in how the protocol handles state transitions, not an isolated incident. The component's maturity — it's been stable for years — likely means reduced fuzzing and security review attention on these code paths. Treat this as one instance of a structural condition: the same underlying pattern likely produced prior CVEs and will produce more until the memory management in session state handling receives architectural attention, not just point patches.