OpenJDK CVE-2026-10037

Exploitation requires all of: an Ubuntu system with the vulnerable OpenJDK package installed and its .jar mailcap MIME handler registered, the mailcap package present (this is the precise 'when installed' trigger that makes handlers execute executable-flagged files), xdg-desktop-portal-gtk running to expose the OpenURI portal, and an already-compromised or malicious sandboxed application that has portal access and can write to a host-reachable filesystem location and set the executable bit. Limiting factors: the attacker must already hold code execution inside a sandbox (PR:L, not unauthenticated), access is local (AV:L, not remotely reachable over the network), and no exploitation is possible on systems lacking mailcap or the desktop portal stack - servers and minimal installs without xdg-desktop-portal-gtk are not exposed. No end-user interaction is required (UI:N).

The supplied CVSS 3.1 vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H (8.8) is internally consistent with the description: the attacker is a local, already-running but low-privileged sandboxed process (AV:L, PR:L), needs no victim interaction (UI:N), and the sandbox-to-host break is precisely the scope change (S:C) that drives the high score, with full host C/I/A loss. No EPSS score, KEV listing, or SSVC decision data was provided, and no public exploit is identified - so the real-world signal is 'high technical severity, unproven exploitation.' The practical risk is gated by a specific desktop stack (OpenJDK .jar handlers + mailcap installed + xdg-desktop-portal-gtk + a sandboxed app the attacker already controls), which narrows exposure well below a remote-network flaw of the same score. This is a genuine privilege/boundary escalation worth prioritizing on affected Ubuntu desktops, but the absence of EPSS/KEV/POC data means it is not evidence of active mass exploitation; treat it as a serious defense-in-depth gap rather than a fire-drill.

An attacker compromises a Flatpak/Snap-confined application on an Ubuntu desktop (for example via a malicious document or a supply-chain-tainted app) and, from inside the sandbox, uses the OpenURI portal exposed by xdg-desktop-portal-gtk to write a crafted .jar to a host-accessible path, mark it executable, and request that it be opened. The OpenJDK mailcap handler then runs the jar outside the sandbox, giving the attacker arbitrary code execution with the desktop user's full host privileges. No public exploit is identified at time of analysis, so this reflects the described mechanism rather than an observed campaign.