A Microsoft Teams incoming webhook is a long URL that posts messages into one channel. The URL is the secret: there is no sign-in, no token header and no second factor behind it. Anyone who has the address can post to that channel under the name and icon of the integration you set up, and nothing in Teams asks who is calling. A webhook cannot read the channel or list its members, so the damage is bounded, but a message that appears to come from your own bot is a convincing place for phishing links and fake alerts. Replace the URL, then look at what was posted.
Check your GitHub account for leaked secrets — free
- Provider
- Microsoft
- Severity
- High
- Impact
- SaaS account access and billing
- Checked live by LeakWatch
- No
What a Teams webhook URL looks like
The whole URL is the credential. It starts with https://, a tenant-specific host under webhook.office.com, and a long path made of identifiers separated by an @ sign and a fixed IncomingWebhook segment:
https://…XXXX.webhook.office.com/webhookb2/…/IncomingWebhook/…/… Teams webhook URL (masked)
The host and the path are not secret on their own, but the last part of the path is, and the URL as a whole is enough to post. Do not try to tell a live URL from a dead one by its shape. Treat every value that matches the pattern as live until its channel says otherwise.
Some Teams integrations use a different address format, such as an Azure Logic Apps or Power Automate HTTP endpoint. Those are not covered by this page. If the leaked value is one of those, follow the steps below for the flow that owns it.
How Teams webhook URLs get leaked
- Configuration files committed to a repository. A
TEAMS_WEBHOOK_URLorMS_TEAMS_WEBHOOKvariable in a.envfile, aconfig.jsonor a CI workflow, pushed with the rest of the project. - Notification scripts. A deploy script or monitoring hook that posts build results to a channel, with the URL hard-coded so it works on any machine.
- Copied snippets. A tutorial or a gist pasted into a repository with a real URL still in the sample code.
- Build logs. A CI step that echoes its environment or a
curlcommand, which prints the full URL in plain text. - Chat and ticket threads. A URL pasted into a support request or a shared chat to “test” a notification.
What to do in the first hour
- Create a replacement webhook first. Open the channel in Teams, use the connector or workflow option to add a new incoming webhook, and give it a name that says what it is for. Copy the new URL once, into your secret manager or deployment settings.
- Deploy the new URL to the systems that post to the channel. Send one test message, then confirm it arrived in the channel with the expected name.
- Remove the exposed webhook in the same channel, using the steps in the Teams connectors and workflows below. Once it is gone, requests with the old URL fail, which is what ends the exposure.
- Check the channel for posts you did not send. Scroll through the period since the exposure. Look for alerts that do not match your real monitoring, links to unfamiliar domains, and messages that imitate a colleague or a bot. Note the times, because an attacker’s posts often cluster.
- Warn the people who read the channel. A fake message from your own integration is most dangerous when a team trusts it. Tell them what the real alerts look like and ask them not to act on unexpected links.
- Check other webhooks and connectors in the same team. If the leaked file held several URLs, treat each one as exposed and replace them all.
- Clean the repository. Remove the value from the working tree, and rewrite history if the repository is public. See I accidentally pushed an API key to GitHub.
Not sure what else leaked? Run a free scan.
Revoke it at Microsoft Teams
A Teams webhook cannot be rotated in place, so you remove the old one and add a new one. Open the channel where the webhook was created and find its connector or workflow settings. The menu names have changed several times, and Microsoft has been moving older connectors toward Workflows, so look for the list of webhooks or flows attached to that channel. Delete the entry that owns the leaked URL, or turn off the workflow that receives it. If you cannot find it in the channel, check the Workflows app in the team, since a flow can be created there and not show up in the old connector list. Your tenant settings decide which of these screens you can reach. If the page you see differs from these steps, follow Microsoft’s current documentation for removing a webhook from a channel.
How LeakWatch detects it
The rule is called “Microsoft Teams Webhook”. It matches an https:// URL whose host ends in .webhook.office.com, whose path starts with webhookb2/, and whose remaining segments follow the shape of an incoming webhook: two dash-separated identifiers joined by @, a fixed IncomingWebhook segment, and a 32-character identifier followed by a final identifier. The match is case-sensitive to lowercase letters and digits, as Teams URLs are issued. The severity is high. This type is not checked live: LeakWatch does not send any request to Microsoft with the URL it found, so a hit tells you the value matches the format, not that the webhook is still active.
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 our Teams messages with this URL?
No. An incoming webhook can only post. It cannot read the channel’s history, list its members or access files. The risk is what they post, not what they can see.
Does deleting the webhook remove the messages it already sent?
No. Removing the webhook stops new posts. Old messages stay in the channel until someone deletes them, which is why the review of the channel in the first hour matters.
Why not just edit the webhook and keep the same URL?
Teams issues a new URL when you create a webhook, and the old one stops working when you remove it. There is no step that rotates the URL in place, so plan the switch: create the new URL, deploy it, then remove the old one.