In Gitea versions before 1.27.0, the function ToHook() decrypts the webhook's HeaderAuthorizationEncrypted field and includes the plaintext authorization header in API responses. This behavior exposes sensitive authorization headers to any repository admin who queries webhook information via endpoints like GET /api/v1/repos/{owner}/{repo}/hooks. Although the authorization header is encrypted in storage using the server's SecretKey, the API response reveals the decrypted value, effectively converting a write-only secret into a readable credential. This affects multiple endpoints requiring admin privileges and risks cross-admin secret exposure and potential external service compromise.

The vulnerability allows repository administrators to access plaintext webhook authorization headers set by other admins, exposing sensitive credentials such as Bearer tokens, Basic authentication credentials, and API keys. This can lead to credential harvesting if an admin's Gitea token is compromised and may result in unauthorized access to external services integrated via webhooks. The exposure undermines the intended encryption-at-rest protection of these secrets, increasing the risk of secret leakage within shared repositories.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The suggested fix is to make the authorization header write-only by returning a masked or redacted version or a boolean flag indicating the presence of an authorization header instead of the plaintext value. Until an official fix is available, restrict repository admin access to trusted users and avoid sharing sensitive authorization headers in webhooks.