Leaked Slack Webhook URL? Regenerate It in 5 Minutes

A Slack incoming webhook is a URL that posts a message to one channel. The URL itself is the secret: there is no token or login behind it, so anyone who has the address can post to that channel as your integration, with the name and icon you configured. A webhook cannot read messages or list members, so the damage is bounded, but it is a convincing channel for spam and for phishing links aimed at your own team. Replace it and look at what was posted.

Check your GitHub account for leaked secrets — free

Provider: Slack
Severity: High
Impact: SaaS account access and billing
Checked live by LeakWatch: No

What a Slack webhook URL looks like

The secret is the whole URL, with a host and a path made of identifiers:

https://hooks.slack.com/services/T…/B…/…XXXX   Slack incoming webhook (masked)

Slack also serves other webhook-style addresses from the same host. Webhooks used by Workflow Builder use a /workflows/ path, and workflow triggers use a /triggers/ path. They work the same way: knowing the URL is enough to start the action.

A Slack bot token (xoxb-…), a user token (xoxp-…) or an app-level token (xapp-…) is not a webhook. Those tokens can read data and act through the Slack API, so they are more serious, and the steps differ. If that is what you leaked, use the Slack API token guide.

How Slack webhook URLs get leaked

Alerting and monitoring config. Prometheus Alertmanager, Grafana, Uptime tools and cron scripts all take a webhook URL, and the config is committed.
CI/CD notifications. Pipeline definitions and .env files that post build or deploy results to a channel.
Application settings. A SLACK_WEBHOOK_URL setting in a framework config, a Helm values file or a Terraform variable.
Documentation and README examples. A “post to Slack” snippet with the real URL instead of a placeholder.
Browser and chat shares. A URL pasted into a ticket, a public chat or a screenshot of a configuration page.

What to do in the first hour

Open the Slack app that owns the webhook. Go to the Slack API apps page, choose your app and open its Incoming Webhooks section. Find the leaked URL in the list of webhooks for your workspace.
Remove the exposed webhook and add a new one. Create a webhook for the same channel, then revoke the old URL. Slack gives a new URL; there is no way to keep the old address.
Update every consumer of the old URL: monitoring, CI, scripts and apps. Anything that still uses the old one will fail with an error, which tells you where to look.
Check the channel for unwanted messages. Scroll the destination channel since the exposure and look for posts from your integration’s name that you did not send, especially with links or requests for passwords.
Warn the channel’s members if something was posted. A short note that a message was not from you, plus the link to delete, limits the damage. Remove the messages you find.
Check the workspace’s app list and audit logs, if your plan has them. Confirm that no extra apps or webhooks were added to the workspace. Restrict who is allowed to install apps and create webhooks.
Then clean the repository: remove the value and rewrite history if you want to. See I accidentally pushed an API key to GitHub.

Not sure what else leaked? Run a free scan.

Revoke it at Slack

There is no single account page for this. Webhooks belong to the Slack app that created them. Sign in at the Slack API site, open Your Apps, pick the app, and go to Incoming Webhooks in its settings. Remove the webhook you want to retire and add a new one for the same channel. For a Workflow Builder webhook, open the workflow in Slack and change or recreate its web request trigger, which produces a new URL. If you cannot find the app, ask a workspace admin: only the app’s collaborators and workspace admins can manage it. After removal, posts to the old URL fail.

How LeakWatch detects it

The rule is called “Slack Webhook”. It matches https://hooks.slack.com/services/ followed by three segments in the exact shape Slack uses, and it also matches the /workflows/ and /triggers/ variants with a more general pattern. A URL that is cut short, or one that uses plain http, is not reported. LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it. Testing a webhook means posting a message to someone’s channel, which is why we do not do it.

LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.

FAQ

Can someone read my Slack messages with the webhook?

No. An incoming webhook only posts. It cannot read channels, list users or fetch files. The risk is messages that look like they came from you, so check the channel and warn people.

Can an attacker post to other channels?

A classic incoming webhook is tied to the channel it was created for. A leaked URL for a private channel does not expose other channels, but it does expose that one. Workflow webhooks run the workflow as it is configured, so review what the workflow does.

Do I need to rotate the webhook if my repository was private?

Anyone with access to the repository can read the URL, including former contractors and any tool with repository access. If the URL was in a place you cannot fully control, regenerating takes a few minutes and is the safe option.