Tell HN: GitHub might have been leaking your webhook secrets. Check your emails.

43 points by ssiddharth ↗ HN
Got an email from Github a few minutes back asking me to rotate my webhook secrets, the relevant portions of it below.

We're writing to let you know that between September 2025 and January 2026, webhook secrets for webhooks you are responsible for were inadvertently included in an HTTP header on webhook deliveries. This means that any system receiving webhook payloads during this window could have logged the webhook secret from the request headers. Webhook deliveries are encrypted in transit via TLS, so the header containing the secret was only accessible to the receiving endpoint in a base64-encoded format. We have no evidence to suggest your secrets were intercepted. This issue was fixed on January 26, 2026. Please read on for more information.

User privacy and security are essential for maintaining trust, and we want to remain as transparent as possible about events like these. GitHub itself did not experience a compromise or data breach as a result of this event.

What happened?

On January 26, 2026, GitHub identified a bug in a new version of the webhook delivery platform where webhook secrets were included in an `X-Github-Encoded-Secret` HTTP header sent with webhook payloads. This header was not intended to be part of the delivery and made the webhook secret available to the receiving endpoint in a base64-encoded format. Webhook secrets are used to verify that deliveries are genuinely from GitHub, and should only be known to GitHub and the webhook owner.

The bug was limited to only a subset of webhook deliveries that were feature flagged to use this new version of the webhooks platform. The bug was present between September 11, 2025, and December 10, 2025, and briefly on January 5, 2026. The bug was fixed on January 26, 2026.

What information was involved?

The webhook secret for each affected webhook was included in HTTP request headers during the window that the bug was present. The webhook payload content itself was delivered normally and was not additionally affected. No other credentials or tokens were affected. Webhook deliveries are encrypted in transit via TLS, so the header containing the secret was only accessible to the receiving endpoint.

If the receiving system logged HTTP request headers, the webhook secret may be present in those logs. The webhook secret is used to compute the `X-Hub-Signature-256` HMAC signature on deliveries — if compromised, an attacker who knows the secret could forge webhook payloads to make them appear to come from GitHub.

9 comments

[ 3.5 ms ] story [ 31.6 ms ] thread
Got that too. My first reaction: Go to HN to understand what's going on. Where are the comments?
> webhook secrets for webhooks you are responsible for were inadvertently included in an HTTP header on webhook deliveries

LOL how does this even happen?

How come it took them so much time to send this notification? I'm so fed up with their bs.
Closing the barn door well after the horses are long gone.
How is this not a bigger deal on hn? Was expecting a lot more conversation
Assuming I've understood correctly...

Checking the listed impacted web hooks I noticed that no repo's listed twice, even though some have multiple hooks defined... That makes me think the report may have a bug.

Also, many of the listed hooks show as `This hook has never been triggered`; which if correct means it wouldn't have had an issue as the compromised payload's never been sent to it.

I'll write a powershell script (well, AI will write it and then I'll tweak) to help check which webhooks have been called in this time window (or at least, say they were most recently triggered after the issue first began) to help get a more accurate report of what's concerning. If that proves useful, I'll share here.

Waiting 3 months to disclose this is suboptimal.
I don't understand how this story is not in the front page yet.