HexBrain

HackerOne · Report #3287208

DOS via Mutation Aliasing in GraphQL Account Recovery Phone Number Verification API

Validstatus
185upvotes
16 Apr 2026disclosed

Summary

Important Guideline Update Regarding DoS Vulnerabilities

This report was submitted and resolved in accordance with our previous program guidelines. As of October 2025, HackerOne has updated its policy regarding Denial-of-Service (DoS) vulnerabilities to reflect more stringent safety and testing requirements.

We appreciate the researcher’s thorough documentation of the GraphQL mutation aliasing issue and awarded a bounty consistent with the guidelines in effect at the time of submission. Under our current guidelines, similar DoS reports will be handled in accordance with the updated guidelines, which can be reviewed here: [link].

Key Updates

  • DoS testing is now subject to stricter safeguards, including defined testing windows
  • Single-request, single-user, single-IP testing constraints are more rigorously enforced
  • The reward framework for DoS findings has been refined to align with these requirements

Researchers are encouraged to review the updated guidelines before conducting any DoS-related testing and to focus on vulnerability classes that align with current program priorities.

This disclosure recognizes the researcher’s contribution under our prior guidelines while transparently communicating our updated approach to DoS vulnerability assessment.

How it was found

Summary: The GraphQL API’s verifyAccountRecoveryPhoneNumber mutation can be aliased multiple times in a single request, causing the server to process each mutation sequentially. Each additional alias adds approximately 8 seconds to the server’s response time, enabling (DoS) attack by exhausting server resources and increasing latency.

Description: The verifyAccountRecoveryPhoneNumber mutation is designed to verify user phone numbers during account recovery phone change. However, the API does not limit the number of mutation aliases in a single GraphQL request. When the same mutation is repeated with different aliases, the server executes each one separately, performing expensive backend operations multiple times. This leads to a linear increase in response time based on the number of aliases included. The result is a resource exhaustion vulnerability that can degrade or deny service availability to legitimate users.

Steps To Reproduce

  1. Prepare a GraphQL mutation request with multiple aliases for verifyAccountRecoveryPhoneNumber, In this case, the response time will exceed 20 seconds because each alias (verify1, verify2, verify3) adds approximately 8 seconds of processing time.
mutation VerifyAccountRecoveryPhoneNumberMutations($verification_code: String!, $otp_code: String) {
    verify1: verifyAccountRecoveryPhoneNumber(input: { verification_code: $verification_code, otp_code: $otp_code }) {
        __typename
        me {
            
        }
    }
    verify2: verifyAccountRecoveryPhoneNumber(input: { verification_code: $verification_code, otp_code: $otp_code }) {
        __typename
    }
    verify3: verifyAccountRecoveryPhoneNumber(input: { verification_code: $verification_code, otp_code: $otp_code }) {
        __typename
    }
}
}
  1. Send the request to the GraphQL endpoint with valid or dummy verification_code and otp_code variables.

  2. Observe the response time increases by 8 seconds for each additional mutation alias included.

Impact

An attacker can exploit this vulnerability to cause a Denial of Service (DoS) by sending a single GraphQL request with multiple aliases of the expensive mutation. This forces the server to perform repeated, resource-intensive operations sequentially, significantly increasing response times and consuming server resources. As a result, legitimate users may experience severe delays or be completely unable to access the affected service, leading to degraded availability and potential service disruption. This DoS attack can be triggered without high network traffic, making it easier to exploit stealthily.

This report was disclosed publicly on HackerOne and belongs to its author and the program. See the original