ConvertX EUVD-2026-97762

Exploitable only against ConvertX versions prior to 0.18.0, where /delete/{id} accepts state-changing HTTP GET with no CSRF token. Preconditions: (1) the victim must have an active authenticated ConvertX session in the same browser; (2) the victim must load attacker-controlled content (UI:R) - though because it is a GET, this can be a passively auto-loaded resource such as an <img>/<iframe> src, requiring no click; (3) the attacker must reference a valid job id (ids are enumerable/guessable integers, so this is a weak limit). Limiting factors: requires an authenticated victim session and user navigation to attacker content; impact is confined to deleting the victim's own conversion jobs. Patched in 0.18.0 by switching to POST with form-based submission.

Signals conflict on severity. The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H) yields 8.1 (High), but the rated I:H/A:H appears inflated for the described behavior: this CWE-352 CSRF only lets an attacker trigger deletion of individual conversion jobs (one /delete/{id} per forged request), not total compromise of the ConvertX instance, so I independently assess integrity/availability impact as Low. There is NO KEV listing and NO public exploit identified in the provided data, and no EPSS score was supplied, so there is no evidence of active or probable exploitation - this is a defensively-patched CSRF, not a priority mass-exploitation threat. The genuine real-world risk is further bounded by UI:R (the authenticated victim must visit attacker-controlled content) and by the limited, reversible-only-by-re-conversion nature of the damage (loss of job history). Net: a legitimate, cleanly-confirmed CSRF bug worth patching, but closer to Medium real-world risk than the 8.1 headline suggests, especially given the product's small deployment footprint.

An attacker crafts a web page (or email with a remote image/iframe) pointing at a victim ConvertX instance's /delete/{id} URL. When a logged-in ConvertX user visits that content, their browser auto-sends the session cookie with the GET request and the server silently deletes the targeted conversion job. No public proof-of-concept was identified in the provided data, but exploitation is trivial because the state-changing action is a plain GET with no CSRF token.