← Security research
Web2Cross-Site Request Forgery (CSRF)

One Link to Unlink: CSRF in OpenAI's Discord Verification Service

A CSRF vulnerability in OpenAI's Discord verification service allowed the account-unlinking operation to be triggered through a state-changing GET request without adequate anti-CSRF protection. The issue was reported through Bugcrowd and marked P3, resolved and fixed, in the published research.

OpenAI Discord Verificationintroductory10 October 20268 min read
Written byManish Singh

Overview

During independent bug bounty research, a Cross-Site Request Forgery (CSRF) vulnerability was identified in OpenAI's Discord verification service.

The service linked a user's OpenAI account with their Discord account to verify eligibility for OpenAI's official Discord community. The unlink functionality was implemented through a state-changing GET request that did not require an anti-CSRF token.

This allowed the unlink action to be triggered through a crafted cross-site request when a victim's browser made the request in an authenticated context and the applicable browser cookie policies permitted it.

The finding was submitted through OpenAI's Bugcrowd program and marked P3, Resolved and fixed, according to the published research evidence.

  • Research Classification: Bug Bounty Research
  • Target: OpenAI Discord Verification Service
  • Affected Host: discord.verify.openai.com
  • Affected Endpoint: GET /unlink
  • Vulnerability Class: Cross-Site Request Forgery (CSRF)
  • Priority: P3, Medium
  • Status: Resolved and fixed
  • Researcher: M1S0

1. Technical Background

Cross-Site Request Forgery (CSRF) occurs when a web application accepts an authenticated state-changing request without adequately verifying that the request was intentionally initiated by the user.

Browsers may automatically attach eligible session cookies to requests. If an application relies on those cookies for authentication but does not adequately validate the request's origin or intent, a malicious website may be able to trigger an action in the context of a user's existing session.

CSRF is particularly relevant to operations that modify account settings, change linked identities, or revoke access to connected services.

A robust implementation uses appropriate CSRF protections and ensures that state-changing operations cannot be triggered simply by loading a URL.

2. Vulnerability Details

OpenAI's Discord verification service supported linking an OpenAI account to a Discord account as part of the community verification process.

The service also provided an unlink operation to disconnect the associated accounts.

During testing, the unlink functionality was found to be triggered through a GET request to the /unlink endpoint. The observed request did not contain an anti-CSRF token or another demonstrated request-specific mechanism for validating user intent.

Because the operation changed account-linking state, exposing it through a request that could be initiated cross-site created a CSRF risk.

An attacker could potentially induce a victim to visit a crafted URL or page that caused the browser to issue the unlink request. If the victim's authenticated session was applicable to that request, the service could perform the operation without the victim intentionally initiating it through the legitimate interface.

Core weakness: A state-changing operation was exposed through a GET request without adequate CSRF protection.

3. HTTP Request Evidence

The original research documented the unlink request as a plain HTTP GET request to the verification service.

The following is a sanitized representation of the observed request structure:

GET /unlink HTTP/2
Host: discord.verify.openai.com

1

The documented request did not show an anti-CSRF token.

This is a structural representation of the request, not a complete verbatim capture. Refer to the original Burp Suite evidence for the full request headers and any session-related details.

Security Observation

The application used a request method commonly associated with retrieving resources to trigger a state-changing account operation.

The request did not demonstrate an anti-CSRF token or an equivalent mechanism that established that the operation was intentionally initiated through the legitimate application interface.

The combination of a state-changing GET endpoint and insufficient CSRF protection made the unlink operation susceptible to cross-site request forgery under applicable browser and session conditions.

4. Proof of Concept

The behavior was investigated using Burp Suite to inspect the unlink request and generate a proof-of-concept page.

The validation process was as follows:

  1. Access the Discord verification service and establish the account-linking state using the authorized test account.
  2. Inspect the unlink functionality and capture the corresponding HTTP request.
  3. Observe that the operation was triggered through a GET request to /unlink.
  4. Examine the request for anti-CSRF protections and identify the absence of a demonstrated anti-CSRF token.
  5. Generate a controlled CSRF proof of concept that triggered the unlink operation through a browser request.
  6. Open the proof-of-concept page in the relevant authenticated test context.
  7. Verify the resulting account-linking state using the service's confirmation page.

The original research documented that loading the proof-of-concept page triggered the unlink action and that the service displayed a confirmation indicating that the Discord account had been disconnected.

The issue demonstrated that a sensitive account-linking operation could be initiated without the user intentionally performing the operation through the legitimate interface.

5. Observed Behavior

The unlink request caused the service to disconnect the associated Discord account from the OpenAI account.

The service subsequently displayed a confirmation that the account had been de-linked.

The security concern was that the action could be initiated through a cross-site request, subject to the browser's handling of authentication cookies and the target's request-processing behavior.

The affected functionality did not require the user to intentionally initiate the unlink operation through the legitimate interface when the vulnerable request was triggered successfully.

6. Security Impact

The vulnerability could allow an attacker to disrupt a user's access to the OpenAI Discord community by causing the account-linking relationship to be removed.

Potential consequences included:

Unintended account unlinking: A victim could lose the association between their OpenAI and Discord accounts without intentionally initiating the action.

Community access disruption: If the account link was required for community verification, unlinking could interfere with the victim's ability to satisfy the server's verification requirements.

Targeted disruption: Users with important community responsibilities could be targeted, potentially disrupting their participation.

Lack of informed user intent: The operation could occur without a clear confirmation step demonstrating that the user intended to disconnect the accounts.

The documented impact concerned the account-linking relationship and associated community verification. It should not be interpreted as evidence of OpenAI account takeover or compromise of the user's OpenAI credentials.

The original Bugcrowd submission was marked P3. The severity should be understood in the context of the original program's assessment and the demonstrated impact.

7. Root Cause Analysis

The underlying weakness was inadequate protection of a state-changing endpoint against cross-site request forgery.

Two design decisions contributed to the issue:

7.1 State Change Through GET

The unlink operation used a GET request to modify account-linking state. Browsers can issue GET requests through navigation, redirects, and embedded resources, making such endpoints particularly easy to trigger unintentionally.

7.2 Insufficient Request-Intent Validation

The observed request did not contain an anti-CSRF token or demonstrate an equivalent mechanism for verifying that the operation was intentionally initiated through the application.

Where authentication depends on browser-managed cookies, the application must account for the possibility that a browser can issue authenticated requests in response to cross-site navigation or other attacker-influenced actions.

8. Remediation Recommendations

8.1 Implement Anti-CSRF Token Validation

Require a cryptographically unpredictable, session-bound anti-CSRF token for sensitive state-changing operations. Validate the token on the server and reject requests with missing or invalid tokens.

8.2 Replace State-Changing GET Requests

Use an appropriate state-changing method, such as POST, for the unlink operation. Ensure that the endpoint still requires CSRF protection; changing the HTTP method alone does not prevent CSRF.

8.3 Configure SameSite Cookies

Use appropriate SameSite cookie settings, such as Lax or Strict where compatible with the application's authentication and navigation requirements. Treat these settings as a defense-in-depth measure rather than a replacement for CSRF token validation.

8.4 Validate Request Origin Where Appropriate

For sensitive operations, validate Origin and, where suitable, Referer headers as additional defenses. Reject requests that do not meet the application's expected origin policy.

8.5 Add Regression Tests

Add security tests that verify the unlink endpoint rejects requests without valid CSRF protection and does not modify account-linking state when requests are initiated from an unauthorized cross-site context.

9. Key Takeaways

This finding demonstrates how an apparently simple account-management operation can become a security issue when state-changing requests are not adequately protected.

CSRF protection should cover the full lifecycle of sensitive account operations, including both linking and unlinking identities.

Developers should avoid state changes through GET requests, implement robust server-side CSRF validation, and use browser cookie protections as an additional security layer.

Security assessments should evaluate the reverse operation of important workflows. An application may protect account linking appropriately while overlooking the corresponding unlink functionality.

10. Disclosure Context

This vulnerability was identified through independent bug bounty research and submitted through OpenAI's Bugcrowd program.

The original public research documents the submission as P3 and marked resolved and fixed.

This article is published as independent security research for educational and defensive purposes. It is not a finding from a Pickel OffSec client engagement, and it does not imply authorization to test OpenAI or any associated service.

The publication focuses on the reported CSRF weakness, its practical impact on account linking, and the defensive measures applicable to similar web applications.

References

  1. OWASP — Cross-Site Request Forgery Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
  2. OWASP — Cross-Site Request Forgery: https://owasp.org/www-community/attacks/csrf

Pickel OffSec Offensive Security Research

Independent research. Reproducible findings. Actionable remediation.

Want this standard applied to your product?

A 30 minute scoping call, then a fixed price. No discovery questionnaire, no pressure to buy.

Contact

No form, no sales desk. The person who answers is the person who would run your engagement.

Profiles
XLinkedIn
Book a scoping call