CVE-2026-112050 in Gitify
Summary
by MITRE • 10/18/2026
Gitify before 7.10.0 contains a login cross-site request forgery vulnerability that allows remote attackers to bind a victim's client to their account because performGitHubWebOAuth() omits OAuth state validation. Attackers can get a gitify://oauth?code= link with their own authorization code opened during a victim's pending login, causing Gitify to display attacker-controlled notifications as the victim's own.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in versions of Gitify prior to 7.10.0 represents a critical failure in the implementation of OAuth authentication flows, specifically within the performGitHubWebOAuth function. This flaw is classified under CWE-352, which denotes Cross-Site Request Forgery (CSRF), although it manifests through an Open Redirect and state parameter omission rather than traditional form-based submission attacks. The core technical issue lies in the application's handling of the OAuth callback process when authenticating with GitHub. During a standard OAuth 2.0 authorization code grant flow, the client must generate a unique, cryptographically secure random value known as a state parameter before redirecting the user to the authorization server. This state parameter is then sent along with the redirection and must be validated upon return from the provider to ensure that the response corresponds to the specific authentication request initiated by the legitimate user. Gitify failed to implement this validation step, leaving the login mechanism vulnerable to manipulation.
The operational impact of this vulnerability allows a remote attacker to hijack an active or pending authentication session for any victim using the affected version of Gitify. By exploiting the lack of state validation, an attacker can construct a malicious link containing their own GitHub authorization code in the format gitify://oauth?code=ATTACKER_CODE. If this link is opened while the victim has initiated a login process but not yet completed it, or if the application processes incoming deep links without verifying they match the current session context, Gitify will accept the attacker's credentials as valid for the victim's account. This effectively binds the victim's client instance to the attacker's GitHub identity rather than their own. Consequently, the attacker gains unauthorized access to view and interact with the victim's repositories, issues, pull requests, and notifications within the application interface.
Beyond simple authentication bypass, this vulnerability enables a more insidious form of social engineering and data manipulation. Once the client is bound to the attacker's account, any notifications or updates generated by the attacker will appear as if they originated from legitimate sources associated with the victim's profile context. This can lead to confusion, misinformation, and potential reputational damage for the user. Furthermore, it compromises the integrity of collaborative workflows where trust in notification authenticity is paramount. The attack vector relies on the ability to trick a user into opening a specially crafted URI scheme link, which may be delivered via phishing emails, malicious websites, or other social engineering tactics that exploit the deep linking capabilities of desktop applications like Gitify.
From an industry standard perspective, this flaw aligns with MITRE ATT&CK technique T1078, specifically Valid Accounts, as it allows attackers to obtain legitimate credentials without knowing them by hijacking the session establishment process. It also relates to CWE-613, which covers Insufficient Session Expiration, although the primary failure is the lack of request-response binding via state parameters. The absence of CSRF protection in OAuth flows is a well-documented risk that violates best practices outlined in RFC 6749 and OWASP guidelines for secure authentication implementations.
To mitigate this vulnerability, users must upgrade to Gitify version 7.10.0 or later, where the performGitHubWebOAuth function has been patched to correctly validate OAuth state parameters. For developers maintaining custom builds or similar applications, it is imperative to implement strict validation of the state parameter during the callback phase. This involves generating a random string before initiating the authorization request, storing it securely in the session storage, and comparing it against the value returned by the identity provider. If the values do not match exactly, the authentication response must be rejected immediately. Additionally, implementing CSRF tokens for any internal API calls triggered post-authentication can provide an additional layer of defense against related forgery attacks. Regular security audits focusing on OAuth implementation details are recommended to prevent similar oversights in future updates.