Phishing

Reports in this bucket describe exploiting user trust and brand recognition rather than a software defect - a subdomain or misconfigured DNS record that could host convincing phishing content under the target's own domain, an observed phishing campaign impersonating the target's brand, or a UI element that makes a scam page look legitimate. The common thread is that the vulnerability lives in human perception and trust, not in application logic.

These reports depend on deceiving a human, not on any technically probable application behavior - there's no request/response pattern that distinguishes "content a real user could be tricked by" from ordinary content.

Brand-protection monitoring, DNS/subdomain hygiene audits (checking for dangling or unclaimed records an attacker could take over and host convincing phishing content on), and security-awareness training for the humans who are the actual target.

Tip: These are typically found through active brand and domain monitoring, supply-chain integrity checks (dependency and build-artifact verification), or a researcher stumbling on an impersonating page or trojaned package — not through testing the target application itself, since the application's own code is often not where the problem lives.

Real-World Impact

Phishing, malware distribution, and embedded malicious code all target the human or supply-chain layer rather than a technical flaw in the application itself. A convincing phishing page hosted on or impersonating a legitimate brand harvests credentials directly from victims who have no reason to suspect anything is wrong. Malware distributed through a compromised or trojaned download, and malicious code embedded in a dependency or build artifact, both convert trust in a legitimate distribution channel into a direct compromise of anyone who uses it.

The severity of a successful attack in this category is often disproportionate to how it was achieved — a single convincing phishing campaign or a poisoned dependency can compromise a large number of victims simultaneously, since it exploits trust rather than a specific technical vulnerability.

These findings are frequently reported to bug bounty programs not because the program's own application has a flaw, but because the program's brand, domain reputation, or supply chain is being actively abused by a third party — which still matters directly to the organization even though the "vulnerability" isn't in code they wrote.

Prevention and Secure Design

Preventing Phishing takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Monitor for brand and domain impersonation actively. Typosquatted domains, lookalike login pages, and impersonating social accounts are found faster by active monitoring than by waiting for a report.

Deploy anti-phishing email authentication. SPF, DKIM, and DMARC configured correctly meaningfully reduce how easily an attacker can spoof legitimate-looking email from your own domain.

Verify the integrity of the software supply chain. Pin dependency versions, verify package signatures where available, and monitor for unexpected changes in dependencies between releases — this is where embedded malicious code most often enters.

Have a clear, fast takedown process for abuse reports. A phishing page impersonating your brand causes ongoing harm for every hour it stays live — a documented, fast process for reporting and getting it taken down matters as much as detection.

Train users and staff on the specific patterns seen in your sector. Generic phishing awareness helps less than training built around the actual lures attackers use against your specific user base.