# Bypass of the SSRF protection in Event Subscriptions parameter.

Slack Event Subscriptions URL validation was bypassed with an IPv6 [::] redirect, letting the server SSRF internal ports and read service banners.

- Payout: hidden
- Severity: medium
- Program: Slack
- Found by: elber
- Disclosed: 2019-02-22
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/386292
- Library page: https://bugbountylibrary.com/r/h1%3A386292
- Tags: area:web domain:web impact:internal-access kind:bounty platform:hackerone sev:medium technique:chained vuln:open-redirect vuln:ssrf

**Target:** Event Subscriptions request URL validator (api.slack.com/apps)
**Root cause:** The SSRF protection validated the submitted URL but did not account for an attacker-controlled redirect to an IPv6 loopback address [::], which the fetcher then followed.
**Steps:**
1. Host `x.php` that issues `header("location: ".$_GET['u'])`.
2. Set Event Subscriptions URL to `http://hacker.site/x.php/?u=http://[::]:22/`.
3. Slack fetches the URL, follows the redirect to `[::]:22`, and returns the SSH banner in the challenge response body.
4. Repeat with `?u=http://[::]:25/` to reach SMTP and read the Postfix banner.
**How found:** Noticed the URL validator returned a 500 error for non-standard URLs, then tested SSRF bypass techniques and found the IPv6 `[::]` vector worked via an open redirect.
**Exploitation:** Attacker points the Event Subscriptions URL at their own redirector, which 302s to `http://[::]:<port>/`; Slack's server follows it and reflects the internal service response (SSH/SMTP banners) back in the challenge body, enabling internal port scanning and service version disclosure.
**Insight:** When a URL validator blocks private IPv4 ranges, try IPv6 loopback `[::]` and attacker-controlled redirects that resolve after validation; banner-grab internal ports via the reflected challenge response.