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.
Objetivo: Summarise the vulnerability chain, its real-world impact, and produce a concise proof-of-concept suitable for a bug bounty report.
Contexto: You now have enough information to assess severity and communicate the finding responsibly to the vendor.
Revela solo las que necesites. Claude lleva la cuenta de cuántas usaste para calibrar la retroalimentación.
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.
Chatea con un tutor anti-spoiler para este paso. Usa solo la especificación de este lab y empieza por la pista más pequeña que sirva.
Cuéntale qué probaste, dónde te atoraste, o pega la respuesta/error que estás viendo.
¿Te gusta Hintru? Buy me a coffee ☕ ☕