# Bypass of the SSRF protection (Slack commands, Phabricator integration)

Slack's SSRF blacklist for slash commands and Phabricator integration was bypassed using IPv6 loopback [::], reaching internal loopback services like SMTP, SSH, and Squid.

- Payout: $100
- Severity: medium
- Program: Slack
- Credited: agarri_fr
- Disclosed: 2016-09-14
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/61312
- Library page: https://bugbountylibrary.com/r/h1%3A61312
- Tags: domain:web impact:internal-access kind:bounty platform:hackerone sev:medium technique:recon vuln:ssrf

**Target:** Slack slash commands and Phabricator integration URL fetch
**Root cause:** SSRF blacklist blocked IPv4 loopback/private ranges but did not account for IPv6 loopback address [::], which resolves to the same internal host.
**Steps:**
1. Create a Slack slash command with url `http://[::]:25/`
2. Trigger the command via `/api/chat.command`
3. Observe SMTP banner from loopback in the response
4. For Phabricator integration, set `phabricator_url=http://[::]:22/` and observe 302 vs 500 to port-scan loopback
**How found:** Researcher noted the blacklist covered IPv4 loopback/private ranges and hypothesized the IPv6 unspecified/loopback form `[::]` would resolve to loopback but evade the filter.
**Exploitation:** Attacker configures a slash command or Phabricator integration URL pointing at `http://[::]:<port>/`; Slack backend fetches it, bypassing the IPv4-only blacklist, returning internal service banners (SMTP) or enabling blind port scanning via 302/500 differential.
**Insight:** When testing SSRF blacklists, always try alternate IP representations of loopback: IPv6 `[::]`/`[::1]`, decimal/octal/hex IPv4, and DNS names resolving to 127.0.0.1 — filters often only enumerate IPv4 CIDR strings.