Bug bounty programs can be an important extension of an organization’s cybersecurity program. They give independent security researchers an opportunity to examine applications in ways that internal teams and automated tools may not. More importantly, they can uncover vulnerabilities before someone with malicious intent finds them.
As a cybersecurity practitioner, I find public bug bounty reports especially valuable. They provide real-world examples that can help security teams, business leaders, and clients better understand how vulnerabilities are discovered, how seemingly minor weaknesses can create meaningful risk, and what organizations can learn from the disclosure process.
This article may become the first in a series examining noteworthy bug bounty reports: what the researcher found, how the vulnerability worked, how the organization responded, and what lessons others can take from it.
For this first breakdown, I reviewed a HackerOne report submitted by security researcher z3phyrus involving the Firefox Accounts API. The vulnerability itself was interesting, but the interaction between the researcher and Mozilla was equally worth examining.
API Security Is Still a Difficult Conversation
Helping organizations understand API security can sometimes be a difficult sell. Many teams rely heavily on commercial scanning tools, static application security testing, or other automated solutions and assume those controls provide sufficient coverage.
Those tools are valuable, but they are not infallible. Authorization vulnerabilities often depend on application logic, user relationships, session behavior, and how different authentication methods interact. Those conditions can be difficult for automated tools to recognize.
This report is a strong example of why organizations still need human testing, thoughtful threat modeling, and careful validation of sensitive API functions.
The Vulnerability
Z3phyrus discovered an insecure direct object reference, commonly called an IDOR, affecting a Firefox Accounts API endpoint used to delete accounts.
An IDOR occurs when an application allows someone to access or manipulate an object simply by changing a value such as an account number, email address, document identifier, or user ID. The application may confirm that the requester is authenticated but fail to verify that the requester is authorized to act on that specific object.
IDOR vulnerabilities generally fall within the broader category of broken access control.
In this case, the issue reportedly allowed an attacker to delete another person’s Firefox account by submitting the victim’s email address through the account-deletion API. The attack was especially relevant when the victim had created the account through single sign-on, or SSO, and had not established a traditional password.
The attacker did not need to know the victim’s password. The attacker did not need access to the victim’s Google, Apple, Microsoft, or other SSO account. The attacker only needed a valid session associated with the attacker’s own account and the email address connected to the victim’s account.
How the Attack Worked
The researcher began by creating an account through an SSO provider. The researcher then captured the API request used to delete that account.
Instead of submitting the request with the email address belonging to the authenticated session, the researcher replaced it with the email address of another SSO-based account.
The API reportedly accepted the request and deleted the other account.
The core problem was not that the attacker had bypassed authentication entirely. The attacker was authenticated—but only as themselves. The API failed to sufficiently confirm that the account identified in the deletion request belonged to the authenticated user.
That distinction is important. Authentication answers the question, “Who are you?” Authorization answers, “Are you allowed to perform this action on this account?” An application can correctly authenticate a user while still making a serious authorization mistake.
Sensitive and destructive actions such as account deletion should be tied directly to the authenticated session. Applications should also consider requiring reauthentication, an additional verification step, or confirmation through a trusted communication channel before permanently deleting an account.
From Informative to High Severity
Mozilla initially downgraded the report to an informative rating. The response appeared to be based on the understanding that an attacker would need information associated with the victim’s credentials to complete the attack.
After reviewing the report again, Mozilla reopened it without being prompted. Z3phyrus then provided additional clarification and evidence showing that the attack could succeed without control of the victim’s credentials or SSO account.
Once the misunderstanding was resolved and the behavior was validated, the report was upgraded to high severity. The researcher was ultimately awarded a $6,000 bounty.
That progression is one of the most valuable parts of this story. Security reports are not always understood correctly on the first review. Researchers may leave out a critical detail, triage teams may interpret an attack path differently than intended, or the true impact may not become apparent until a proof of concept is demonstrated.
A report being downgraded does not always mean the underlying finding lacks value. Sometimes it means the attack scenario needs to be explained more clearly.
Understanding the Business Impact
The technical vulnerability is only one part of the risk. Business leaders will naturally ask what exploitation would mean for their organization.
The answer depends on the application, the number of affected users, and how important account access is to the organization’s operations.
An attacker could potentially automate this type of vulnerability by using a script and a list of known email addresses. Previous data breaches, credential dumps, marketing databases, and publicly available employee information could provide attackers with large numbers of potential targets.
The potential impact would be greater for an organization where a significant percentage of customers create accounts through SSO. It would also increase when those accounts provide access to critical services, financial information, stored payment methods, sensitive records, or revenue-generating transactions.
For an e-commerce company, widespread account deletion could interrupt purchases, increase customer-support costs, damage customer confidence, and create immediate revenue loss. For a website where accounts are used primarily to manage newsletters or preferences, the financial impact may be lower, although the reputational and operational consequences could still matter.
Organizations should therefore consider several questions:
How many users rely exclusively on SSO?
Can sensitive account actions be completed without reauthentication?
Does the application confirm that the requested account belongs to the authenticated session?
How quickly could deleted accounts be restored?
What would happen if a large group of customers suddenly lost access?
A business impact analysis or targeted risk assessment can help place the vulnerability into the organization’s actual operating context. Cyber insurance may help transfer portions of the remaining financial risk, but insurance should complement—not replace—strong authorization controls, testing, incident response planning, and recovery capabilities.
Lessons for Security Researchers
One of the strongest lessons from this report was how z3phyrus responded after the initial downgrade.
Bug bounty research can require hours or even days of work. When a report is rejected or classified as informative, it is understandable that a researcher may feel frustrated. Unfortunately, some exchanges become confrontational, which can make collaboration more difficult and distract from the technical facts.
That did not happen here.
Z3phyrus reviewed the response, identified the apparent misunderstanding, and clarified the attack scenario without becoming hostile or argumentative. The researcher focused on the evidence: the attacker’s own authenticated session could be used with the victim’s email address, and no access to the victim’s SSO credentials was required.
That professional approach helped move the discussion forward. Persistence mattered, but so did the way that persistence was communicated.
Lessons for Vulnerability Disclosure Programs
Mozilla also deserves credit for its response.
The team reopened the report without waiting for the researcher to challenge the decision. Its responses provided reasoning, acknowledged the possibility of a similar historical issue, and escalated the finding for additional review.
Not every disclosure program operates that way. Researchers sometimes wait weeks for meaningful updates, receive responses that do not address the evidence, or struggle to determine whether anyone has reproduced the vulnerability.
A good vulnerability disclosure program should make researchers feel that their work is being evaluated fairly, even when the organization initially disagrees with the reported severity. That does not mean every submission should receive a bounty. It means the organization should provide timely communication, explain its reasoning, remain open to additional evidence, and correct its decision when the facts warrant it.
Mozilla’s willingness to reconsider the report is exactly what a mature disclosure process should encourage.
What Could Have Been Clearer?
Although the report was ultimately successful, the original summary may not have made the authentication issue completely clear.
The most important fact was that the attacker did not need the victim’s credentials. The attacker’s own valid session, combined with the victim’s email address, was reportedly sufficient to submit the deletion request.
Placing that fact near the beginning of the report could have prevented the initial misunderstanding. A concise statement such as the following may have helped:
“An authenticated attacker can use the attacker’s own session token to delete an unrelated SSO-only account by replacing the email address in the account-deletion request. No access to the victim’s password, session, email account, or SSO provider is required.”
Report writing is often more of an art than a science. Researchers understand their findings because they have spent hours testing them, but the person reviewing the report is seeing the issue for the first time. Clearly separating prerequisites, attack steps, expected behavior, actual behavior, and business impact can make a significant difference.
Final Thoughts
This vulnerability demonstrates how a small authorization oversight in an API can lead to a serious outcome. It also shows why organizations cannot depend solely on automated tools to identify every meaningful weakness.
Just as importantly, this report is an example of responsible disclosure working as intended. A researcher identified a vulnerability, the vendor initially misunderstood part of the attack, both sides continued communicating professionally, and the report was ultimately reevaluated and resolved.
Credit goes to z3phyrus for demonstrating patience, persistence, and strong bug bounty etiquette. Mozilla also deserves recognition for reconsidering its initial assessment and maintaining a constructive dialogue throughout the process.
We have come a long way in responsible vulnerability disclosure. Reports like this show what is possible when researchers and organizations approach the process as collaborators rather than adversaries.
