{
	"id": "9b7c9cf7-41dc-46e6-91dc-201ef748b712",
	"created_at": "2026-04-06T00:18:00.33109Z",
	"updated_at": "2026-04-10T13:11:23.810534Z",
	"deleted_at": null,
	"sha1_hash": "69c055a85f36f197473aca232c1a45ae2d1380ee",
	"title": "Slack bot token leakage exposing business critical information",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1567362,
	"plain_text": "Slack bot token leakage exposing business critical information\r\nBy Detectify\r\nPublished: 2016-04-28 · Archived: 2026-04-05 23:33:25 UTC\r\nDevelopers are leaking access tokens for Slack widely on GitHub, in public repositories, support tickets and\r\npublic gists. They are extremely easy to find due to their structure. It is clear that the knowledge about what\r\nthese tokens can be used for with malicious intent is not on top of people’s minds…yet. The Detectify team\r\nshows the impact, with examples, and explains how this could be prevented.\r\nUpdate: Slack has made a follow-up response: “we’ve revoked the tokens you reported, notified affected users and\r\nteam owners directly, and that we’ll be doing that proactively going forward”.\r\nSlack has become one of the world’s most popular corporate tools for communicating internally. The simplicity of\r\nthe Slack API and its tokens also inspire people to create services using Slack to automate manual tasks. This\r\naligns well with the ChatOps movement, a conversation-driven development widely credited to GitHub. Using\r\nChatOps enables you to do automation only by writing simple commands in a chat.\r\nThe problem is that many developers tend to include Slack tokens – credentials tied to their personal Slack\r\naccount – directly in the code when building Slack bots. These projects are also shared publicly on GitHub. Now,\r\nbecause the code contains these tokens, the developer is actually giving anyone – that finds the token – access to\r\nthe developer’s company’s internal chats and files on Slack. And not only that, there’s no easy way to see if\r\nsomeone is eavesdropping on the communication.\r\nThe problem is that many developers tend to include Slack tokens – credentials tied to their personal\r\nSlack account – directly in the code when building Slack bots. These projects are also shared publicly\r\non GitHub.\r\nThe irony is that a lot of these bots are mostly fun “weekend projects”. We saw examples of fit bots, reminding\r\nyou to stretch throughout the day, quote bots, quoting both Jurassic Park (“Ah ah ah…you didn’t say the magic\r\nword”) and Don Quijote. Yet, these hobby projects, in combination with being shared on GitHub, risk exposing\r\nboth sensitive company information as well as private messages and files for the user that created the token.\r\nIn the worst case scenario, these tokens can leak production database credentials, source code, files with\r\npasswords and highly sensitive information. The Detectify Team have already been able to find thousands of\r\ntokens by simply searching GitHub; and new tokens are becoming publicly available every day.  \r\nHow to generate Slack tokens – and where the problem occurs\r\nThere are multiple open source projects to easily create Slack bots, such as Hubot. Hubot does a great job of using\r\nenvironment variables for access tokens. One reason behind environment variables is to separate credentials from\r\nthe code completely, getting the environment that runs the code to provide the data depending on where the code\r\nruns.\r\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 1 of 13\n\nHowever, developers tend to be creative in how to work with these variables. Here are real life examples where\r\nthe developers are injecting the tokens inside the code onto the environment, which breaks the whole concept of\r\nhow environment variables are supposed to be set up:\r\nWe also saw examples of where log output from applications was spitting out the Slack tokens in clear text,\r\nleaking them when people posted GitHub issues needing help in public projects:\r\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 2 of 13\n\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 3 of 13\n\nHow big is the problem?\r\nIndependently of Slack, tokens on GitHub are unfortunately very common. But in this case, compared to AWS\r\ntokens that were reported being scraped by black hats a few years ago, it’s most likely because the developers\r\ndon’t know about the full impact of leaking a Slack token. Also, a bonus is how GitHub’s full text index work and\r\nthe format of Slack tokens, since the tokens use a prefix with a hyphen as a separator:\r\nxoxp-XXXXXXXXX-XXXXXXXXXXXXXXXXXXX\r\nxoxb-XXXXXXXXX-XXXXXXXXX-XXXXXXXXX-XXXXXX\r\nGitHub’s search treats hyphenated strings as separate words, and since these prefixes are very distinguishable of\r\nbeing tokens to Slack, you will find a huge amount of Slack tokens on GitHub just by searching for the prefixes.\r\nUsing the tokens it’s possible to eavesdrop on a company. Outsiders can easily gain access to internal chat\r\nconversations, shared files, direct messages and even passwords to other services if these have been shared on\r\nSlack. Here are some examples of sensitive messages being shared among people inside Slack teams (the\r\nsensitive information in these examples has been modified or redacted):\r\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 4 of 13\n\nCompanies that we’ve been in contact with to let them know about them leaking their token were surprised of the\r\namount of data that was accessible by this token as per default. One of the most common responses were “I did\r\nnot know that token gave that much access” which indicates that the process to generate these tokens does not\r\nadequately explain how much data could be exposed by abusing the token.\r\nThere are different types of tokens in Slack, and some of them has less access than others. The problem is that it is\r\ndifficult to create a proper limited token whereas creating a very open token with full access is easy.\r\nWho is affected?\r\nUp until now we’ve identified over 1500 tokens that match the pattern of a Slack token being publicly available\r\non GitHub. These tokens belong to different users and companies; among them Forbes 500 companies, payment\r\nproviders, multiple internet service providers and health care providers. Renowned advertising agencies that want\r\nto show what they are doing internally. University classes at some of the world’s best-known schools. Newspapers\r\nsharing their bots as part of stories. The list goes on and on.\r\nOur research and results\r\nAs we’ve mentioned, there are different kinds of tokens in Slack. There are also different restrictions to them. To\r\nexplain this we need to understand what types of API-endpoints there are:\r\nSearch API. This API makes it possible to search using a query and get all results back in a list.\r\nIM/Groups API. The private messages sent to a user, both by direct messages and groups.\r\nChannels API. Using these APIs you can gather all data for all public channels in a team. Please\r\nunderstand that public in this sense means that anyone internally in the team can join, the information in\r\nthis channel is not public per se.\r\nUsers API. You will get all users in the complete Slack team together with their e-mail address and user\r\ninformation.\r\nThere are many more APIs, you can find them all here.\r\nNow, these APIs above are essential for someone that wants to eavesdrop on a company. If a token is leaked,\r\ndepending on the token there are different scenarios for how the company data can get exposed:\r\nxoxb – Custom Bot Token\r\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 5 of 13\n\nA xoxb-token (which has the prefix xoxb) is created by the “Custom Bot”-page for each team. This token is\r\ndetached from the creator, it is marked as a bot and behaves like a separate user. You cannot restrict this token to\r\ndisable a certain API endpoint. It does have one significant restriction though, the search.all API will respond\r\nwith: Error: user_is_bot . However, since it still has access to all channel’s messages, all data can be retrieved\r\nusing this token.\r\nxoxp – Private Token\r\nThe xoxp-token (prefix xoxp) can be generated from the OAuth Test Token-page. This token is exactly like having\r\nthe complete username and password for the user. Even for a user with two factor authentication enabled, you can\r\nstill access Slack with nothing else but this token.\r\nThis token can use the search.all-API, being able to search not only for channel messages and files, but also in the\r\ncurrent user’s internal messages and groups.\r\nThere are additional types of tokens, but these two types are the ones being leaked the most.\r\nWe found 626 private tokens and 879 bot tokens. On the page where you generate the Private Tokens, this\r\nmessage is shown:\r\nOn the Custom Bot page on Slack, there’s no indication at all that the token should be kept secret, but looking at\r\nthe data, that message on the Private Token page doesn’t really make any difference.\r\nWhen we identified companies running responsible disclosure, with security contact or an email for the owner of\r\nthe repository, we got mixed results as you see here:\r\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 6 of 13\n\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 7 of 13\n\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 8 of 13\n\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 9 of 13\n\nWhat we found:\r\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 10 of 13\n\nDatabase credentials, login to continuous integration platforms and internal services, private messages to the token\r\nowner and files with passwords. We also concluded from the internal communication inside Slack teams, that\r\npeople tend to be really sloppy with passing credentials in general.\r\nWhat happened next?\r\nWe reported this to Slack as “The sad state of Slack tokens on GitHub” on Mar 26th. The report was closed as\r\ninformative by Slack on Apr 18th. During the discussions we mentioned different ways for Slack to actually be\r\nproactive around the cause of this. Some of the things was to be able to restrict access per API, being able to\r\nrevoke the API-key using the API itself and to automatically revoke the tokens that ended up on GitHub.\r\nSlack believe that it is foremost the responsibility of the users not to be sharing their tokens around – and are also\r\nclear with stating this on their website when a token is created.\r\nThe problem though, is what to do when people are obviously sharing this data publicly online daily.\r\nIn their last response they said;\r\n“Thanks for the additional tokens. We’re proactively looking for tokens ourselves now, and reaching out to\r\ncustomers to let them know when we’ve disabled tokens and where we found them. We’ll deactivate these in the\r\nnext batch.”\r\nWe haven’t been able to confirm this is actually the case yet but it sounds like a great plan.\r\nUpdate: We received the message sent by Slack to teams with leaked tokens:\r\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 11 of 13\n\nBest Practice\r\nNEVER COMMIT CREDENTIALS INSIDE CODE. EVER.\r\nThe first thing you should do is to create environment-variables inside a file and ignore that file from the code\r\nrepository from start. Also, public due diligence of your company: What type of public repositories do you have?\r\nHow does the commit history of them look like? Do they have a bunch of legacy in them? Could there be any\r\ncredentials forgotten inside the commit history? Are all developers in our company able to create private\r\nrepositories?\r\nWhen passing credentials internally, use services like onetimesecret.com to place passwords in a only-visible-once\r\nout-of-context. Sending the URL to the secret together with the username in the message will be an improvement\r\ncompared to today, since the viewer of the secret can only watch it once, and if onetimesecret.com is hacked, no\r\none will know what the password belongs to.\r\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 12 of 13\n\nAlso, Slack has some settings that could be great to enable. The important one is disabling the ability for all users\r\nto create integrations and tokens:\r\nYou will find this setting over at Admin Settings in Slack.\r\nLast words\r\nGitHub is full of sensitive data. Slack just made it really simple to search for their tokens due to how they are\r\nformed. We hope that this advisory might help people realize how big impact getting these tokens exposed really\r\nis. \r\nAlso, if we can help limit the amount of robots in the world somehow, the Skynet hopefully won’t happen that\r\nsoon.\r\n(We love robots, but not exploited ones)\r\nSource: https://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nhttps://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://labs.detectify.com/writeups/slack-bot-token-leakage-exposing-business-critical-information/"
	],
	"report_names": [
		"slack-bot-token-leakage-exposing-business-critical-information"
	],
	"threat_actors": [],
	"ts_created_at": 1775434680,
	"ts_updated_at": 1775826683,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/69c055a85f36f197473aca232c1a45ae2d1380ee.pdf",
		"text": "https://archive.orkl.eu/69c055a85f36f197473aca232c1a45ae2d1380ee.txt",
		"img": "https://archive.orkl.eu/69c055a85f36f197473aca232c1a45ae2d1380ee.jpg"
	}
}