# Slack SAML authentication bypass

Slack's SAML endpoint accepted a signed assertion issued for GitHub (wrong Audience, expired, different subject), logging the attacker in as that subject.

- Payout: $3,000
- Severity: critical
- Program: Slack
- Credited: Antonio Sanso
- Disclosed: 2017-10-26
- Write-up quality: 6/10
- Original: https://blog.intothesymmetry.com/2017/10/slack-saml-authentication-bypass.html
- Library page: https://bugbountylibrary.com/r/blog%3Ablog-intothesymmetry-com-2017-10-slack-saml-authentication-bypass-html
- Tags: domain:web impact:ato kind:bounty platform:blog sev:critical tech:saml technique:recon vuln:access-control vuln:auth-bypass

**Target:** SAML service provider endpoint /sso/saml
**Root cause:** Slack did not validate the AudienceRestriction/Audience element of the SAML assertion, so an assertion minted for a different SP (GitHub) was accepted as valid for Slack.
**Steps:**
1. Obtain a signed SAML assertion issued by an IdP for a different SP (e.g. GitHub) with a subject not your own.
2. Capture/replay it via Burp with SAML Raider against `POST /sso/saml` on Slack.
3. Observe Slack accepts the assertion despite wrong Audience, expired conditions, and mismatched subject.
4. Get logged into Slack as the assertion's subject.
**How found:** Learned SAML via spec and SAML Raider after reading Ioannis Kakavas's Microsoft/GitHub SAML findings; enumerated SAML-enabled services used daily (GitHub, HackerOne, Slack) and tried the confused-deputy test of presenting an assertion meant for SP B to SP A.
**Exploitation:** Replay a previously captured, expired GitHub-issued SAML assertion to Slack's /sso/saml ACS endpoint; Slack validated the signature but not the Audience, authenticating the attacker as the assertion's subject.
**Insight:** When a target is a SAML SP, test cross-SP assertion reuse: replay a signed assertion you already hold from another SP (even expired, different subject) and check whether Audience/AudienceRestriction, NotOnOrAfter, and Subject are enforced independently.