CSRF Account Deletion: How I Turned an “Excluded” Bug Into $87 USD Bounty

My name is Jivan, and in this case study, I will present a detailed analysis of a Cross-Site Request Forgery (CSRF) account deletion vulnerability I discovered. Although the issue was initially classified as excluded under the company’s bug bounty policy, I submitted a comprehensive report outlining the technical details, reproduction steps, and the potential impact on real-world scenarios. This thorough explanation ultimately led the company to address the vulnerability and award a bounty despite its out-of-scope classification.

Now, before diving into the testing part, let me briefly explain the target company’s service model. Due to security and privacy reasons, I cannot disclose the company name here, so let’s refer to it as [Redacted Dot Com]. This company provides Network Access Control (NAC) solutions designed to manage and secure both IoT devices and traditional endpoints over wired and wireless networks. Their platform offers capabilities such as device discovery, access policy enforcement, and real-time monitoring to ensure only authorized devices can connect to the network.

Now, let’s focus on the testing part. For [Redacted Dot Com], I have already reported multiple vulnerabilities, all of which earned good bounties. However, in this write-up, I will focus only on the CSRF vulnerability.

While spending more time on [Redacted Dot Com], I came across an account deletion endpoint. In this endpoint, when a user chooses to delete their account, they must enter their account password. If the password is not provided or is incorrect, the account deletion process does not proceed.

However, a vulnerability exists here that allows an attacker to delete a victim’s account. There is one important condition: the victim’s password is required for the attacker to perform this action.

According to [Redacted Dot Com]’s bug bounty policy, any vulnerability that requires victim user interaction or credentials is excluded from the bounty program. This means the company would not normally accept this finding, as it requires the victim’s password to carry out the attack.

After reading the bug bounty policy, I started finding any way to get the victim credentials or guess the credentials, but it failed — there was no direct way to access or get the victim credentials. At this moment, I thought it was not possible to get victim credentials to make this CSRF exploit work based on the current bug bounty policy.

Then I remembered one thing about the application logic: if the user uses 2FA, every time the user logs in using their own credentials, they also need to verify the 2FA. If the user has enabled 2FA, they must provide the username, password, and 2FA to get access to the account.

Here, I found a potential security issue via 2FA. Now, let me explain — the 2FA itself is already secure and cannot be abused to bypass authentication, but I discovered a new attack scenario that directly turned my finding into a valid one, even though it required the victim’s password.

Now, I had already confirmed that [Redacted Dot Com] was vulnerable to CSRF, which allowed an attacker to delete any user account by only requiring the victim’s password. This is because the target application verifies the password before deleting the account.

I also confirmed that if a user has enabled 2FA, they must verify 2FA to gain access to the application. Here is the key point I mentioned in my report that made my finding valid even though it required the victim’s password:

If an attacker obtains the victim’s password using social engineering or any other method — it doesn’t matter how the credentials are obtained — you might think the attacker could simply log in to the victim’s account. But if the victim has enabled 2FA, the attacker cannot log in without the 2FA code, even if they have a valid username and password.

Here’s the main point: if the victim has 2FA enabled but the attacker has the valid password, the attacker can capture their own account deletion request, replace their own password in the request with the victim’s password, and deliver the CSRF exploit to the victim. When the victim opens or interacts with the malicious link, it will delete the victim’s account without any confirmation.

I explained this entire scenario in my report. Please see the attached screenshot.

Now, let’s understand the steps to reproduce

Now, I logged in to my account (acting as the attacker user) and enabled 2FA. I also ensured that 2FA was enabled for the victim account. Next, in the attacker account, I navigated to the account deletion option and started an intercepting proxy tool to capture the network traffic. Then, I entered my password and selected the delete account option.

Now, here is one more important key point I mentioned in my report: when any regular user chooses to delete their account, after entering the valid password and selecting the delete option, the application displays a confirmation prompt for account deletion.

Now, if you see the above screenshot, once the user chooses the confirm option, the account is permanently deleted and there is no way to recover it. I also mentioned in my report that, when the CSRF attack is carried out, this confirmation prompt on the client side is also bypassed. This made my report valid for bounty once again.

The account is permanently deleted after this step. I then generated the CSRF exploit from the vulnerable endpoint.

Now, I generated the CSRF PoC, replaced the attacker’s password with the victim’s password, and delivered the PoC to the victim user.

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://[Redacted Dot Com]/wp-admin/admin-ajax.php" method="POST">
      <input type="hidden" name="action" value="gn_delete_my_account_process" />
      <input type="hidden" name="userpassword" value="VictimUserPassword" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

After the exploit was triggered on the victim’s side, no confirmation prompt was shown to the victim user. As a result, the victim’s account was deleted without any confirmation, even though 2FA was enabled on the account. This made my report a valid finding, and I provided a professional analysis of the impact and a clear explanation, which ultimately led the company to reward a bounty.

After completing all findings and the impact analysis, I submitted a detailed report with a proper explanation of the impact of this CSRF vulnerability. As a result, the company initially classified this report as excluded from bounty because it required the victim’s password, and there was no evidence or proof of a password leak. Therefore, the triage team set the status as excluded from bounty.

However, due to my professional communication and the clear way I explained the impact, they still decided to reward a bounty of $87 USD.

This was entirely because of a solid understanding of the issue’s real-world consequences, even though it was technically out of scope. The company also accepted the report, deployed a fix for the vulnerability, and rewarded the bounty.

🙏 Thanks for reading this case study.

This write-up is meant to share practical insights on approaching and validating security issues that may initially seem out of scope. It highlights why it’s important to:

• Understand the full business logic of the application before discarding a finding.
• Think beyond the initial limitations, such as requirements for user credentials or extra authentication steps.
• Provide clear, professional explanations of potential impact to help security teams reassess severity.
• Respect ethical boundaries and never attempt credential theft or unauthorized access methods.

The goal is to promote a responsible and informed mindset when performing security research. I hope this encourages others to approach even rejected or excluded vulnerabilities with a deeper level of analysis and impact assessment.

Stay curious. Stay responsible. Keep learning.