For most security teams, this CVE warrants a patch-when-convenience timeline rather than emergency response. The EPSS score of 0.00222 reflects near-zero observed exploitation, and Chromium's own 'Low' severity designation carries weight — their team understands the full mitigation stack (sandboxing, site isolation, process isolation) in ways the generic CVSS 5.3 cannot capture. The practical barrier to exploitation is formidable: an attacker needs to control rendered content, achieve precise timing measurements, and extract meaningful signal through noise while Chrome's sandbox restricts what they can do at each step. Unless you're running Chrome in an environment where an attacker already has local code execution or a compromised network path, this finding doesn't meaningfully change your threat model.
What should concern you is the pattern this CVE represents. Research attention is migrating down the trust stack — Spectre hit JavaScript engines, and now graphics libraries like Skia are entering the literature. The absence of current exploitation doesn't establish a ceiling. Skia runs in every Chrome tab across billions of users; it's a high-connectivity node where any timing oracle, even theoretical, matters for long-term threat modeling. The question isn't whether to panic-patch today, but whether your vulnerability management process has a mechanism to flag Skia for re-evaluation when the research landscape shifts — because when the first follow-up papers appear, the classification will need updating.
For triage: patch on your normal cycle, document the rationale for deprioritization, and add a calendar reminder to revisit this finding in six months when the research trajectory becomes clearer. If you consume Chromium via Electron or embedded browsers, verify your vendor's patch timeline — the fix ships in Chrome, but downstream projects often lag by months.