GHSA-phg3-3g28-wq9v: CSRF
Summary
Hatchet version v0.86.26 and below is vulnerable to OAuth state CSRF (login CSRF / account fixation).
The vulnerable code clears the session oauthstate<integration> value to the empty string "" after a successful OAuth callback rather than removing the key, and the subsequent state-equality check then accepts an empty ?state= parameter on any later callback request — allowing an unauthenticated attacker to bind an already-authenticated victim's session cookie to an attacker-controlled OAuth identity (account takeover via login-CSRF).
Impact
Affected configurations: any deployment that has enabled at least one of auth.google.enabled, auth.github.enabled, or the Slack integration, and where the victim has completed at least one OAuth flow on that integration in the current session. Bug present on main HEAD and in every tagged release up to and including v0.86.26 (commit 243f41d9e1161e70d47dfc0a6509f1c4ddfc9c23).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/hatchetto a version that resolves this vulnerability.Fixed in 0.91.1 - Upgrade
Upgrade
Hatchetto a version that resolves this vulnerability.Fixed in v0.86.26 - Operational
Rotate any session cookies/tokens for users who may have completed Google/GitHub/Slack OAuth flows during a vulnerable session (v0.86.26 and below), since OAuth state CSRF/account fixation could allow binding of an already-authenticated victim session to an attacker-controlled identity.
Event History
Frequently Asked Questions
Which deployments and users are exposed?
Deployments are affected only if Google authentication, GitHub authentication, or the Slack integration is enabled. A victim must also have completed an OAuth flow for the affected integration during their current session.
What must an attacker do to exploit the issue?
The attacker does not need to be authenticated. They need to cause a victim with an already-authenticated session, and a prior OAuth flow for the integration in that session, to make a later OAuth callback request with an empty state parameter; this can bind the victim session to an attacker-controlled OAuth identity.
How can I determine whether my deployment is vulnerable?
All tagged Hatchet releases through v0.86.26 are affected, and the issue was also present on the main branch HEAD described in the advisory. Check whether your deployed revision predates commit f90464189ad642251e09412d0f99fde353036428 and whether any affected OAuth integration is enabled.