Summary
Hatchet contains an OAuth session-binding vulnerability in which a previously cleared OAuth state value can later be accepted as valid. An unauthenticated attacker may use this behavior to associate a victim's Hatchet session with an attacker-controlled OAuth identity when the victim has recently completed an OAuth flow and a supported integration is enabled.
Affected context
The issue can occur in Hatchet deployments that enable Google or GitHub authentication, or the Slack integration, and use the affected OAuth callback handling. Exploitation depends on a victim having completed an OAuth flow in the current session, after which the session's OAuth state is cleared but remains eligible for comparison as an empty value.
Exploit preconditions
- Attack surface: OAuth callback and session-authentication endpoints
- Required access: No authenticated attacker access; the attacker needs an OAuth identity they control and must influence the victim's OAuth callback flow
- Trigger point: Validation of the OAuth state parameter after a prior successful callback in the same session
- Deployment condition: Google authentication, GitHub authentication, or the Slack integration must be enabled
- Why exploitation is possible: The server clears the stored OAuth state to an empty string but later treats an empty submitted state as a valid match, weakening the binding between the browser session and the original authorization request
Why this happens
The underlying bug is a session-state lifecycle error that maps to CWE-384: Session Fixation. After a successful OAuth callback, the application replaces the stored state with an empty value instead of invalidating or removing it, and its later comparison logic accepts that empty value. This creates an ambiguous authentication state and allows an OAuth response controlled by another party to become associated with the victim's existing session. The behavior also relates to insufficient authentication validation and inadequate protection of OAuth request integrity.
Potential impact
- An attacker-controlled OAuth identity may become bound to a victim's Hatchet session
- The attacker could gain access to workflows, tasks, or account functions exposed through that session
- User or organizational data may be disclosed or modified
- Administrative actions could be performed under a misbound identity, depending on assigned privileges
- The affected session could undermine trust relationships between Hatchet and connected OAuth providers
General mitigation guidance
Mitigation generally focuses on making OAuth state single-use, unambiguous, and
strongly bound to the initiating browser session.
Common defensive patterns include:
- Remove or invalidate the stored OAuth state after successful use rather than replacing it with a valid-looking empty value
- Reject missing, empty, malformed, expired, or previously consumed state values
- Generate high-entropy, unpredictable state values and compare them using exact, constant-time logic where appropriate
- Bind state to the intended session and, where suitable, use server-side state records with explicit expiration and consumption status
- Preserve secure, appropriately scoped session-cookie settings and avoid accepting OAuth callbacks outside the expected flow
- Apply least privilege to identities and sessions so a misbinding has limited consequences
- Maintain supported vendor security fixes through the organization's normal patch-management process
How teams detect issues like this
Detection can combine application telemetry, code review, and automated analysis.
- Monitor OAuth callbacks for missing, empty, repeated, expired, or previously consumed state values
- Alert on successful identity changes or account associations immediately following anomalous callback patterns
- Review code for state values that are cleared by assignment to an empty string and later compared without a non-empty check
- Use static analysis and code-search rules for OAuth handlers that do not enforce single-use state semantics
- Verify that callback handlers bind state to the initiating session and reject callbacks without a corresponding server-side record
- Enforce secure OAuth implementation policies in CI and peer review, with automated review tools used as a supplementary control
