Slack Technologies, the cloud-based team-communication platform now owned by Salesforce, has been the subject of two publicly disclosed security incidents that together provide a compact case study in the security challenges facing modern Software-as-a-Service (SaaS) collaboration vendors. The first incident, disclosed in March 2015, involved a four-day intrusion into Slack's central user database in February 2015 (Greenberg, 2015). The second, disclosed on 31 December 2022, involved the theft of Slack employee tokens that were then used to download private GitHub source-code repositories (Sharma, 2023; Wikipedia, 2026). Although both incidents were ultimately contained, they exposed recurring weaknesses in identity management, secrets handling, and supply-chain trust that remain directly relevant for any organisation that depends on cloud collaboration tooling. This report distils the principal security lessons from those two breaches.
The 2015 breach exposed user-profile information including email addresses, usernames, bcrypt-hashed and salted passwords, phone numbers and Skype IDs, with Slack additionally acknowledging "suspicious activity" on a small number of accounts, implying that at least some user communications were accessed in full (Greenberg, 2015). At the time, Slack did not yet offer two-factor authentication (2FA) – a feature that competitors such as Microsoft and Google had supported for years – and the company was forced to rush an unfinished 2FA implementation into production in response to the incident (Greenberg, 2015).
The 2022 breach was disclosed on New Year's Eve, when Slack confirmed that threat actors had stolen valid Slack employee tokens and used them to access and download content from a number of the company's private GitHub repositories during the previous weeks (Wikipedia, 2026, citing Sharma, 2023). Customer data and the production environment were reported to be unaffected, but the incident again highlighted that the attackers' point of entry was credential abuse rather than a novel software vulnerability.
1. Multi-factor authentication must be a Day-One control. The clearest lesson from 2015 is that perimeter passwords – even when bcrypt-hashed and salted – are insufficient for a service holding enterprise communications. Slack's reactive deployment of 2FA, described publicly as "clunky" but necessary (Greenberg, 2015), shows the reputational cost of treating MFA as a roadmap item rather than a launch requirement.
2. Tokens and OAuth credentials are now the crown jewels. The 2022 incident demonstrates that as organisations harden interactive logins, attackers pivot to long-lived machine credentials such as personal access tokens (Sharma, 2023). Effective controls include short token lifetimes, scoped permissions, automated rotation, anomaly-based detection on token use, and treating any token leak as a Severity-1 event.
3. Source-code repositories are a sensitive asset class. Source code can leak architectural details, hard-coded secrets and exploitable logic. The Slack–GitHub episode underscores the need for secrets scanning, branch-protection rules, repository-level audit logging, and conditional access tied to corporate identity providers (Sharma, 2023; Wikipedia, 2026).
4. Detection and disclosure timelines matter. Slack detected the 2015 intrusion only after four days of access (Greenberg, 2015) and disclosed the 2022 GitHub theft weeks after the activity began (Wikipedia, 2026). Both cases reinforce the value of behavioural monitoring on identity events and of pre-rehearsed disclosure playbooks that allow rapid, customer-facing communication.
5. Administrative kill-switches and centralised session control are essential. Slack's post-2015 introduction of an administrator-driven password and session "kill switch" (Greenberg, 2015) is a model worth emulating: tenant administrators should be able to invalidate every active session and credential in seconds.
6. The SaaS supply chain is shared risk. Customers of any SaaS platform inherit the vendor's security posture. The Electronic Frontier Foundation has noted that "Slack stores and is able to read all of your communications" (Wikipedia, 2026), so customers should layer their own controls – enforced SSO, data-loss prevention, retention limits, and channel-level access reviews – on top of the vendor's defences.
The 2015 and 2022 Slack incidents are, in combination, a textbook illustration of how attacker tactics have shifted from password-database theft toward token and source-code compromise, and of how SaaS vendors must continuously raise their identity, secrets-management and detection baselines. For customers, the practical takeaway is to assume that even well-resourced vendors will be breached and to design tenant-level controls accordingly.
Greenberg, A. (2015) Slack says it was hacked, enables two-factor authentication. Wired, 27 March. Available at: https://www.wired.com/2015/03/slack-admits-hacked-enables-2-factor-authentication/ (Accessed: 14 May 2026).
Sharma, A. (2023) Slack's private GitHub code repositories stolen over holidays. Bleeping Computer, 5 January. Available at: https://www.bleepingcomputer.com/news/security/slacks-private-github-code-repositories-stolen-over-holidays/ (Accessed: 14 May 2026).
Wikipedia (2026) Slack (software). Available at: https://en.wikipedia.org/wiki/Slack_(software) (Accessed: 14 May 2026).