GitHub Dependabot Adds Withdrawn Alert Webhooks and 410 Gone API Responses

What changed​

According to GitHub's changelog of October 13, 2026, Dependabot withdraws and removes an alert when the advisory or vulnerability behind it is no longer valid. The announcement doesn't change how Dependabot scans or creates alerts, and it doesn't change remediation. It only changes how you find out about a withdrawal.

The change covers all repositories on github.com. GitHub says it will also ship in GitHub Enterprise Server 3.24. The announcement gives no GHES release date and mentions no extra configuration.

1. A withdrawn webhook action​

The dependabot_alert webhook event now has a withdrawn action. The payload carries identifiers captured before the alert was removed. These are the alert number, the GHSA and CVE IDs, the package, and the manifest path. If you already subscribe to dependabot_alert events, you get the new deliveries automatically. GitHub doesn't say you need to resubscribe.

For context, GitHub's 2022 changelog introducing this webhook listed the actions as created, dismissed, reopened, fixed, or reintroduced. Withdrawal wasn't among them, so downstream tools had no signal for it.

2. 410 Gone instead of 404 Not Found​

Requests to get or update a withdrawn alert through the REST API now return 410 Gone. They used to return 404. A 410 now means the alert existed and was withdrawn. A 404 still covers an alert that isn't found. GitHub's REST documentation lists 410 as a possible status for both the "Get a Dependabot alert" and "Update a Dependabot alert" endpoints.

Why this matters​

The gap was real. Community threads and an Atlassian Jira bug report describe how it played out.

• One user asked why an alert was reported as withdrawn and no longer available with no record that it had existed.
• Atlassian's Jira ticket described a limitation where GitHub's advisory services didn't send webhook events for withdrawn alerts, leaving the Jira Security tab with wrong information. That ticket is marked fixed.
• Another community post described a Jira finding left dangling after the matching Dependabot alert was deleted. The poster suspected a missing webhook.

I can't say whether this changelog is a direct response to those reports. It does address the problem they describe.

Review checklist for integrators​

These steps are my recommendations. GitHub doesn't require them.

1. Handle the new action. Make sure webhook handlers accept withdrawn and don't treat it as a new alert or an ordinary state change. Unknown actions may be ignored or rejected, depending on how your handler is written.
2. Mark, don't erase. In ticketing systems, SIEMs, dashboards and compliance records, consider marking the item as withdrawn so you keep the history. Don't leave it showing as an open vulnerability.
3. Match on the payload identifiers. Use the alert number, advisory IDs, package and manifest path to find the record you stored earlier.
4. Split your error handling. Treat 410 as withdrawn and 404 as not found. Keep handling 403 (forbidden), 400, 409 and 422 separately. A 410 doesn't cover every failure.
5. Reconcile existing data. Alerts withdrawn before this change were never announced by webhook. Stale records may already be sitting in your downstream systems, so a one-time cleanup is worth considering.

Caveats​

• Withdrawal is not dismissal. An alert a user dismisses, or one fixed by a dependency update, is a different outcome from GitHub removing it as no longer valid.
• GitHub's announcement doesn't say whether withdrawn alerts can be retrieved afterward. It also doesn't cover webhook retries, retention, or any payload fields beyond those listed.
• GitHub's REST docs describe Dependabot alerts management as public preview and subject to change. Keep that in mind when building on these endpoints.

Bottom line​

This is a small but useful fix for the security and DevOps teams that mirror Dependabot alerts into other systems. Withdrawals now produce a webhook with the identifiers needed to reconcile records, and a distinct 410 for anyone querying later. If you consume dependabot_alert events, check your handlers.