I need advice from experienced bug bounty hunters about a report that was closed as Informative despite my attempts to explain the attack scenario and demonstrate the security impact.
For privacy and responsible disclosure reasons, I am withholding the affected company's name, target domain, exact endpoints, confirmation tokens, report ID, and other identifying details.
- The vulnerability I reported
I discovered unexpected behavior in an application's email-change confirmation flow.
When a user changes their account email address, the application sends a confirmation link. I found that modifying the URL path while keeping the original query parameters could trigger different behavior.
Under the conditions I tested, the modified URL appeared to complete the email change and establish an authenticated session for the affected account without requiring the account password.
I tested this with the account owner's permission.
My concern is that users may believe this is an ordinary email-verification link, not a link that could potentially grant someone access to their account.
- The triage team's initial response
HackerOne Triage:
«Your report has passed the preliminary review. Please note that this does not confirm validation. The next step is to validate and reproduce the issue and evaluate its accuracy and security impact.»
At this point, I believed the issue would be investigated further.
- The report was closed as Informative
After reviewing the report, the triage analyst responded with the following reasoning, paraphrased to remove identifying details:
Triage Analyst:
«The issue does not appear to have significant security impact. An attacker would need access to the victim's account to initiate an email change. If the attacker can initiate an email change to an address they control, they already have sufficient access to compromise the account through standard means, such as changing the password.
The modified confirmation link does not provide additional access beyond what is already available to someone who controls the account session. Without a realistic attack scenario in which the attacker lacks initial account access, this is a design concern rather than an exploitable vulnerability with meaningful impact.
Therefore, the report is being closed as Informative.»
- My first response to the triage team
Me:
«I think there has been a misunderstanding. I never claimed that an attacker could independently change the victim's email address.
My concern is that if a user initiates an email change and the confirmation link falls into an attacker's hands, the attacker may be able to exploit it.
A user may voluntarily share the confirmation link because they believe it is harmless and only confirms an email change. They may not realize that someone receiving the link could potentially gain full access to their account without knowing the password.
I would appreciate it if you could reconsider the report.»
- The triage team's response about mailbox access
Triage Analyst:
«The attack assumes that the victim either shares the unused confirmation link with the attacker or that the attacker obtains it somehow. However, the confirmation link is delivered to the victim's inbox specifically to confirm the email change.
An attacker would therefore need direct access to that mailbox to retrieve it. At that point, the victim's email account has already been compromised, which is a broader security issue in itself.»
- My explanation of the social-engineering scenario
Me:
«I understand your argument about mailbox access, but I believe voluntary link sharing is a separate attack scenario.
For example, an attacker could persuade a user to share an email-change confirmation link by claiming that it is only a routine verification link. The user might refuse to share a password-reset link because they understand its significance, yet share this confirmation link because they do not recognize the potential risk.
If the recipient can modify the URL path and use the link to gain access to the account, the attack does not necessarily require direct access to the victim's mailbox.
I also provided a reference to a previously published security report involving a similar general class of issue. I asked the triage team to reconsider the threat model.»
- My final attempt to clarify the issue
Me:
«The user may trust the link and voluntarily share it during an ordinary conversation. If they believe it is just an email-verification link, they may not understand that it could be used to access their account.
The attacker can then modify the URL path and potentially obtain account access without knowing the password.
My concern is that the security implications of the link are not obvious to the user. I would appreciate a review of this specific scenario rather than an assessment based solely on whether the attacker already has mailbox access.»
After these exchanges, I was unable to obtain a meaningful reassessment through the available process. The report remains closed as Informative.
- Why I disagree with the conclusion
I understand that a confirmation link must be obtained somehow, and that possession of such a link is an important prerequisite for this attack.
However, I believe there is a distinction between:
- An attacker independently compromising a victim's mailbox.
- An attacker persuading a victim to share a link because the victim misunderstands its security significance.
- An application treating an email-change confirmation link as a mechanism that can establish an authenticated account session.
These scenarios have different threat models.
I am not claiming that every user will share such a link, or that the vulnerability is automatically eligible for a bounty. My concern is whether the application should allow a confirmation link to grant account access in a way that the user would not reasonably expect.
Questions for other bug bounty hunters
Is the described behavior a valid account-takeover vulnerability, or is it reasonably classified as Informative because the attacker must first obtain the confirmation link?
How would you demonstrate that the modified endpoint grants additional privileges rather than merely completing the intended email-change process?
Is voluntary sharing through social engineering a sufficiently realistic attack scenario for a report like this?
What options remain when a triage analyst rejects the threat model and the available mediation process does not resolve the disagreement?
If you have encountered a similar situation, how did you handle it professionally?
I have experienced a similar difficulty with a previous report, so this has left me unsure how to proceed.
I am sharing this discussion to seek technical feedback, not to attack the company or encourage anyone to target the service. I am intentionally withholding all information that could identify the affected application or enable exploitation.
I welcome honest criticism if my reasoning is flawed. I would particularly appreciate feedback from researchers who have handled authentication vulnerabilities and disputed triage decisions.
What would you do in my position?
