A phishing/spam email promotes a 'free partnership tool' at start.avail.zone. The invite URL passes a domain through a query parameter — what does the server actually do with it? Investigate the request flow and find an abuse path that could turn this 'invite' into something nastier.
Objective: Summarise the vulnerability chain, its real-world impact, and produce a concise proof-of-concept suitable for a bug bounty report.
Context: You now have enough information to assess severity and communicate the finding responsibly to the vendor.
Only reveal the ones you need. Claude tracks how many you used to calibrate the feedback.
Think about who is harmed: the end users who receive these emails, the businesses whose domains are spoofed, and the platform itself. Map each attack scenario to a concrete impact.
Structure your report around: Vulnerability Type → Root Cause → Attack Scenario → PoC Steps → Impact → Remediation. For CVSS scoring, consider the network vector, no authentication required, and potential confidentiality impact.
PoC one-liner for Open Redirect:
https://start.avail.zone/build-connections?website=https://attacker.com
Remediation suggestions:
1. Whitelist only bare domain names (no scheme/path) in the `website` parameter.
2. Never use the `website` value as a redirect target or in server-side HTTP requests without strict validation.
3. If server-side fetching is needed, use an allowlist and disable redirects in the HTTP client.