Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-3r5c-2xxx-h872
No affected components available
Summary
The ToHook() function in services/webhook/general.go decrypts the webhook's HeaderAuthorizationEncrypted field and returns the plaintext authorization header in the API response. Any repository admin can read the full plaintext value of webhook authorization headers (Bearer tokens, Basic auth credentials, API keys) set by other admins.
The authorization header is stored encrypted in the database using the server's SecretKey, but ToHook() decrypts it before serializing it into the API response — converting a write-only secret into a readable credential.
Vulnerable Code
File: services/webhook/general.go:407-420
func ToHook(repoLink string, w *webhook_model.Webhook) (*api.Hook, error) {
// ...
authorizationHeader, err := w.HeaderAuthorization() // DECRYPTS from DB
if err != nil {
return nil, err
}
return &api.Hook{
// ...
AuthorizationHeader: authorizationHeader, // PLAINTEXT in response
// ...
}, nil
}
Decryption function: models/webhook/webhook.go:209-216
func (w Webhook) HeaderAuthorization() (string, error) {
if w.HeaderAuthorizationEncrypted == "" {
return "", nil
}
return secret.DecryptSecret(setting.SecretKey, w.HeaderAuthorizationEncrypted)
}
Affected Endpoints
All call ToHook():
GET /api/v1/repos/{owner}/{repo}/hooks(requires repo admin)GET /api/v1/repos/{owner}/{repo}/hooks/{id}(requires repo admin)GET /api/v1/admin/hooks(requires site admin)GET /api/v1/orgs/{org}/hooks(requires org admin)GET /api/v1/user/hooks(requires authenticated user)
Steps to Reproduce
- Admin A creates a webhook with a sensitive authorization header.
- Admin B (different repo admin) lists webhooks via
GET /api/v1/repos/{owner}/{repo}/hooks. - The API response includes the full plaintext authorization header set by Admin A.
Impact
- Cross-admin secret exposure on shared repositories
- Credential harvesting if a repo admin's Gitea token is stolen
- External service compromise via leaked Bearer tokens and API keys
- Undermines the intentional encryption-at-rest protection
Suggested Fix
The authorization header should be write-only. Return a masked/redacted version or a boolean has_authorization_header flag instead.
References
- Vulnerable function:
services/webhook/general.go:392-425 - Decryption function:
models/webhook/webhook.go:209-216 - Verified against commit 19f0169
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker needs high-level or administrative privileges. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a low impact on the confidentiality of the information.
Limited exploitation activity has been observed. Close monitoring and planned remediation are recommended.
Probability that this vulnerability will be exploited in the wild within the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
- CVE-2026-58511Alias
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard