Mastercard DNS error went unnoticed for years
A long‑standing DNS typo at Mastercard allegedly left a key Azure gateway subdomain effectively controlled by a third party, raising the risk of TLS certificate issuance and interception of sensitive traffic. Commenters criticize Mastercard’s public claim that there was “no risk,” and are equally scathing about bug‑bounty intermediaries like Bugcrowd and HackerOne, which they say enable companies to downplay or bury valid security findings. The incident is used to highlight broader problems with dangling DNS and cloud resources, weak incentives for large firms to fix issues promptly, and the increasingly thankless, risky nature of responsible vulnerability disclosure.
Bug bounty platforms and disclosure dynamics
- Many commenters criticize Bugcrowd and HackerOne as serving corporate PR more than security, enabling delay, gaslighting, and silencing of researchers.
- Concern that “platform behavior standards” are being used to police activity off-platform and intimidate researchers.
- Some say they’ve largely given up on “responsible disclosure” programs due to low/no rewards, reclassification as “not a bug,” and heavy process overhead.
- A minority note that some vendor-run programs (e.g., large tech firms) work relatively well and keep researchers in the loop.
Mastercard incident: severity and response
- Strong disagreement with Mastercard’s claim that there was “no risk.”
- Technical arguments that DNS control of the typo domain could have enabled TLS certificate issuance, traffic interception, phishing, and API/gateway impersonation.
- A few point out the company’s statement is likely heavily lawyered and may hinge on narrow definitions of “our systems.”
- Several see the public disclosure, after private attempts, as appropriate and possibly the only way to prompt a fix.
DNS, subdomain takeover, and cloud misconfigurations
- Discussion broadens to dangling DNS and cloud resource problems: domains or subdomains pointing to cloud resources (S3, Azure, Vercel, Heroku, email providers) that have been released and can be re-claimed by attackers.
- Researchers report this class of issue is widespread in large organizations and often dismissed as “out of scope” in bug bounty rules, despite clear exploitability.
- Some argue DNSSEC and better tooling/alerting (e.g., detecting unregistered or lame name servers) would have mitigated or surfaced the error, though DNSSEC adoption is described as low.
Incentives, liability, and legal questions
- Repeated theme: companies prioritize reputation and short-term market perception over honest security communication.
- Suggestions include heavy regulatory fines, third‑party validation authorities, or legal frameworks entitling researchers to compensation, but feasibility and optics (extortion vs. reward) are debated.
- Several note the legal risk to researchers in some jurisdictions pushes them either to silence or to immediate public disclosure, bypassing bug bounty NDAs.
Broader anecdotes and attitudes
- Multiple stories of other banks, postal services, card issuers, and big tech firms ignoring or mishandling reports.
- Frustration that companies may be harsher toward good‑faith researchers than toward their own internal failures.
- Some optimism that individual, competent researchers can still prevent large-scale harm when they act at the right time.