Gitify EUVD-2026-103512

Exploitation requires a Gitify user to have an in-flight GitHub OAuth login pending AND to open an attacker-supplied gitify://oauth?code=<attacker_authorization_code> deep link during that window, which Gitify accepts because performGitHubWebOAuth() omits any OAuth state check. Limiting factors: it is a timing-dependent race against a pending login (reflected as AT:P), it needs the victim to act on the attacker's link (UI:P passive interaction), and impact is bounded to low integrity - the victim's client is bound to the attacker's account and shows attacker-controlled notifications, with no read access to the victim's data or account takeover. No non-default configuration is needed; vulnerable behavior is present in default builds before v7.10.0.

This is a genuinely low-priority issue, and the signals are consistent rather than conflicting. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N) scores only 2.3, and the metrics explain why: although the attacker is unauthenticated (PR:N) and the vector is network-reachable (AV:N), successful exploitation carries an attack requirement (AT:P) and requires passive victim interaction (UI:P) - specifically, the attacker must land a malicious callback during a victim's already-pending login. Impact is confined to low integrity (VI:L) with no confidentiality or availability consequence: the attacker binds the victim's client to the attacker's GitHub account, so the victim sees the attacker's notifications rather than losing their own data. No EPSS score, KEV listing, or public POC was provided in the input, so there is no evidence of active exploitation or mass-scanning interest; this is a classic low-CVSS, low-real-risk client-side CSRF rather than an urgent threat. The only firm risk-reducing fact is that a patch (v7.10.0) is confirmed available.

While a Gitify user has a GitHub OAuth login in progress, an attacker lures them into opening a gitify://oauth?code= deep link carrying the attacker's own authorization code. Because performGitHubWebOAuth() never validates an OAuth state parameter, Gitify accepts the attacker's code and binds the client to the attacker's GitHub account, causing the victim's Gitify to display attacker-controlled notifications as if they were the victim's own. No public exploit was identified at time of analysis.