Mend.io Vulnerability Database
The largest open source vulnerability database
What is a Vulnerability ID?
New vulnerability? Tell us about it!
CVE-2026-58511
Published:July 21, 2026
Updated:August 02, 2026
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 1. Admin A creates a webhook with a sensitive authorization header. 2. Admin B (different repo admin) lists webhooks via "GET /api/v1/repos/{owner}/{repo}/hooks". 3. 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
Affected Packages
https://github.com/go-gitea/gitea.git (GITHUB):
Affected version(s) >=v0.9.99 <v1.27.0
Fix Suggestion:
Update to version v1.27.0
gitea.dev (GO):
Affected version(s) >=v0.9.99 <v1.27.0
Fix Suggestion:
Update to version v1.27.0
Do you need more information?
Contact Us
CVSS v4
Base Score:
5.1
Attack Vector
NETWORK
Attack Complexity
LOW
Attack Requirements
NONE
Privileges Required
HIGH
User Interaction
NONE
Vulnerable System Confidentiality
LOW
Vulnerable System Integrity
NONE
Vulnerable System Availability
NONE
Subsequent System Confidentiality
NONE
Subsequent System Integrity
NONE
Subsequent System Availability
NONE
CVSS v3
Base Score:
2.7
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
HIGH
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
LOW
Integrity
NONE
Availability
NONE
Weakness Type (CWE)
Exposure of Sensitive Information to an Unauthorized Actor