May 30, 2024

Vulnerability reporting is dysfunctional

By Kevin Lee, Ben Kaiser, Jonathan Mayer, and Arvind Narayanan

In January, we released a study showing the ease of SIM swaps at five U.S. prepaid carriers.  These attacks—in which an adversary tricks telecoms into moving the victim’s phone number to a new SIM card under the attacker’s control—divert calls and SMS text messages away from the victim. This allows attackers to receive private information such as SMS-based authentication codes, which are often used in multi-factor login and password recovery procedures. 

We also uncovered 17 websites that use SMS-based multi-factor authentication (MFA) and SMS-based password recovery simultaneously, leaving accounts open to takeover from a SIM swap alone; an attacker can simply reset a victim’s account password and answer the security challenge when logging in. We responsibly disclosed the vulnerabilities to those websites in early January, urging them to make changes to disallow this configuration. Throughout the process, we encountered two wider issues: (1) lack of security reporting mechanisms, and (2) a general misunderstanding of authentication policies. As a result, 9 of these 17 websites, listed below, remain vulnerable by default.

Disclosure Process. On each website, we first looked for email addresses dedicated to vulnerability reporting; if none existed, we looked for the companies on bug bounty platforms such as HackerOne. If we were unable to reach a company through a dedicated security email or through bug bounty programs, as a last resort, we reached out through customer support channels. Sixty days after our reports, we re-tested the configurations at the companies, except for those that reported that they had fixed the vulnerabilities.

Outcomes. Three companies—Adobe, Snapchat, and eBay—acknowledged and promptly fixed the vulnerabilities we reported. In one additional case, the vulnerability was fixed, but only after we exhausted the three contact options and reached out to company personnel via a direct message on Twitter. In three cases—Blizzard, Microsoft, and Taxact—our vulnerability report did not produce the intended effect (Microsoft and Taxact did not understand the issue, Blizzard provided a generic acknowledgment email), but in our 60-day re-test, we found that the vulnerabilities had been fixed (without the companies notifying us). As such, we do not know whether the fixes were implemented in light of our research.

Among the responses we received, there were several failure modes, which were not mutually exclusive. 

  • In five cases, personnel did not understand our vulnerability report, despite our attempts to make it as clear as possible (see Appendix B of our paper). Three of them—Microsoft, Paypal, and Yahoo—demonstrated knowledge of SIM swap attacks, but did not realize that their SMS authentication policies were allowing for vulnerable accounts. Paypal, for instance, closed our report as out-of-scope, claiming that “the vulnerability is not in Paypal, as you mentioned this is an issue with the carriers and they need to fix it on their side.While phone number hijackings are the result of poor customer authentication procedures at the carriers, account hijackings resulting from SMS passcode interception are the result of poor authentication policies at websites. The remaining two websites—Taxact and Gaijin Entertainment—misinterpreted our disclosure as a feature request and feedback, respectively.
  • Three of the four reports we submitted to third-party bug bounty programs were disregarded due to the absence of a bug (our findings are not software errors, but rather, logically inconsistent customer authentication policies). Reports are screened by employees of the program, who are independent of the website, and passed on to the website’s security teams if determined to be in scope. These third-party platforms appear to be overly strict with their triage criteria, preventing qualified researchers from communicating with the companies. This issue is not unique to our study, either. A few weeks ago, security researchers also reported difficulties with submitting vulnerability reports to Paypal, which uses HackerOne as its sole security reporting mechanism. HackerOne employs mechanisms that restrict users from submitting future reports after too many closed reports, which could disincentivize users from reporting legitimate vulnerabilities.
  • In five cases, we received no response. 
  • All four attempts to report security vulnerabilities through customer support channels were fruitless: either we received no response or personnel did not understand the issue.   

We have listed all 17 responses in the table below. Unfortunately, nine of these websites use SMS-based MFA and SMS-based password recovery by default and remain so as of this writing. Among them are payment services PayPal and Venmo. The vulnerable websites cumulatively have billions of users. 


We recommend that companies make the following changes to their vulnerability response:

  1. Companies need to realize that policy-related vulnerabilities are very real, and should use threat modeling to detect these. There seems to be a general lack of knowledge about vulnerabilities arising from weak authentication policies.
  2. Companies should provide direct contact methods for security reporting procedures. A bug bounty program is not a substitute for a robust security reporting mechanism, yet some companies are using it as such. Furthermore, customer support channels—whose personnel are unlikely to be trained to respond to security vulnerability disclosures—add a level of indirection and can lead to vulnerability reports being forwarded to inappropriate teams.  

Our paper, along with our dataset, is located at

Thanks to Malte Möser for providing comments on a draft.


  1. Anonymous says

    The deeper issue here is one of corporate greed and end user stupidity and laziness, both of which should be acknowledged and fought against within every company. Companies are (rightfully) hesitant to disallow SMS authentication because they know most users are too dumb and lazy to use authenticator apps and or USB security keys, and they worry they will lose out to competitors who allow for less secure forms of authentication. Consider for a moment that Gmail’s default MFA method is SMS, but that internally, Google mandates the use USB security keys – do what I say not what I do. I don’t work at any of the companies that were the focus of the study, but the study authors should also consider (if they haven’t already) that in most cases, they are preaching to the choir in that there are likely many people within those companies who believe SMS MFA should be disallowed, but who are overruled by executives fearful of losing customers.

  2. caseyjohnellis says

    Casey from Bugcrowd here.The process for reporting in the case we’re involved with here looks like this:

    1. Send report to security@ inbox.
    2. Inbox routes to our platform which creates a claim ticket to allow proper handling and consistent communications around the issue.
    3. Ticket is claimed, and vulnerability intake, triage, and coordination of fix is handled from there.
    4. Note that while public bug bounty programs add a cash incentive/reward to this process, that is by and large the only difference in the process between a VDP and a public BBP. Private BBP and crowdsourced security is different, but is out of scope for the program we’re talking about here.

    On looking at the submission, the initial response to the ticket was sent and likely received, but the ticket itself wasn’t claimed and the communication didn’t proceed further from that point.

    …I thought it important to clear that up for the sake of accuracy.

    wrt Policy Related Vulnerabilities: I completely agree. It’s easy to forget that this is a conversation between potentially the entire Internet (and all of the opinions, skill levels, and input it contains) and security and engineering teams that have wildly different maturity levels across different organizations and verticals.

    To attempt to address this and allow for baselined communications, Bugcrowd started an open-source Vulnerability Rating Taxonomy back in 2014. I would encourage this team to submit a PR for a new class of vulnerability that reflects the umbrella that this issue exists under – and again, I agree both that these issues are common, and the defender-side awareness of them is not ubiquitous.