An Email Address Was Enough: Two Account Deletion Findings Worth $850

Testing what happens when customer support becomes part of the authorization process

Account deletion testing usually starts with an endpoint.

Can I change the account ID? Does the application check ownership? Can a request from another session delete my account?

But there is another route worth examining: customer support.

Across two bug bounty programs, I found that support workflows allowed someone to request deletion of an account without proving ownership. Both findings involved accounts I controlled, and they earned me a combined $850.

The companies, domains, email addresses, and staff identities in this story have been redacted.

Finding One: A Deletion Request From a Different Email Address

For the first test, I created two accounts and completed their registration procedures.

I then sent a message to customer support from the email address associated with Account A, asking them to delete Account B.

The request was straightforward:

Hello, I would like to close my account registered under account-b@example.com.

The important detail was the mismatch: the sender's address was different from the address of the account being deleted.

Support replied to the requesting address. After further processing, the deletion procedure began, and Account B was eventually deleted.

The missing check was ownership verification. Before acting, support had not required confirmation through Account B's registered email address or an authenticated session belonging to that account.

I repeated the test using another account I controlled and supplied screenshots and a recording with the report.

The program acknowledged the issue and said it was reviewing its account deletion process. It assessed the finding as medium severity, with a CVSS score of 4.5.

Finding Two: Separate Contact and Account Email Fields

The second finding involved a support form with separate fields for:

• The email address where support should contact the requester.
• Confirmation of that contact address.
• The email address associated with the account, if different.

That separation can serve legitimate purposes. The security question is what happens before support carries out a destructive action.

I entered an email address I controlled as the contact address and the address of a second test account as the account to be deleted.

Support sent its correspondence to the contact address I supplied. I continued the conversation from that address, and support ultimately deleted the second account.

A notification reached the deleted account's registered address afterward.

A notification after deletion does not provide authorization before deletion.

The workflow established where to contact the requester, but it did not adequately establish that the requester controlled the account being deleted.

The Shared Root Cause

Both findings crossed the same trust boundary:

Knowing an account's email address was treated as sufficient authority to request its deletion.

An email address identifies an account. It does not prove ownership.

Authorization checks need to cover every route to a sensitive action, including actions performed manually by support staff. A protected account deletion endpoint cannot compensate for a support process that performs the same action without equivalent verification.

How I Would Test This Again

Only test within a program's rules and use accounts you own. Account deletion is destructive, so keep disposable test accounts separate from anything you need.

A useful starting point is to create Account A and Account B with the same display name and similar email addresses. This can help reveal whether support relies on superficial similarities when deciding who owns an account.

However, similar addresses can also introduce confusion. Repeat the test with clearly different addresses to establish whether the underlying problem is missing ownership verification.

Then:

1. Complete registration for both accounts.
2. Contact support from Account A and request deletion of Account B.
3. Record where support sends its replies and any confirmation requests.
4. Check whether Account B must authorize the deletion before it happens.
5. Verify the final account state and preserve a minimal evidence trail.

Be precise about the result. A support acknowledgment, a scheduled deletion, and a completed deletion are different outcomes.

Keep the initial request simple and truthful. You do not need an elaborate impersonation story to demonstrate a missing authorization check.

Also check the program's policy before contacting support: some programs restrict social engineering or support interactions.

What a Strong Report Should Show

The clearest evidence is the relationship between three things:

• The address that submitted the request.
• The address registered to the account being deleted.
• The verification performed before deletion.

Include the relevant correspondence and evidence of the final account state. Redact unrelated personal information.

Keep impact claims tied to what you demonstrated. In my tests, I showed that I could cause deletion of another account I controlled without confirming the request through that account.

That established an account availability and data integrity risk. It did not demonstrate access to the account's confidential information.

Fixing the Workflow

Before deleting an account, support should require confirmation through a trusted channel already associated with that account, such as its registered email address or an authenticated session.

If the requester cannot access that channel, the request should go through a defined account recovery process. Requests from authorized representatives also need an appropriate verification process.

A requester-supplied contact address should not become proof of account ownership.

What These Findings Changed About My Testing

These two reports earned me a combined $850, but the broader lesson changed where I look for authorization flaws.

I now ask: who else can perform the same sensitive action, and how do they verify that the requester is allowed to ask for it?

Sometimes the missing authorization check is in a support workflow.