CVE-2026-28744: 
Gitea Analyse et atténuation des vulnérabilités

CVE-2026-28744 is an incorrect authorization vulnerability in Gitea's Git Smart HTTP path that allows Bearer token authentication to bypass repository-scoped permission checks. Affecting Gitea versions up to and including v1.26.1, the flaw enables a PAT or OAuth2 token presented as Authorization: Bearer <token> to clone, fetch, or push to private repositories without the required read:repository or write:repository scopes. The vulnerability was published on May 25, 2026, and patched on June 16, 2026. It carries a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory, Gitea Advisory).

The root cause is CWE-863 (Incorrect Authorization): the CheckRepoScopedToken() function in services/context/permission.go returns early unless ctx.IsBasicAuth is true, meaning scope enforcement is silently skipped for Bearer/OAuth2-authenticated requests. When a token is presented via Authorization: Bearer, the OAuth2 auth handler in services/auth/oauth2.go correctly records IsApiToken=true and ApiTokenScope, but ctx.IsBasicAuth remains false, so the scope data is available but never evaluated. This affects both read flows (git-upload-pack) and write flows (git-receive-pack) since both call the same flawed scope check before normal RBAC. A public proof-of-concept test case is included in the advisory, demonstrating that a token scoped only to read:notification can successfully retrieve refs for a private repository over Bearer auth while being correctly rejected over Basic auth (GitHub Advisory, Gitea Advisory).

Successful exploitation breaks the access-token scope boundary, allowing an attacker in possession of any valid token (even one scoped to unrelated operations such as read:notification) to clone or fetch private repository contents, and potentially push unauthorized commits via Git Smart HTTP. Confidentiality and integrity impacts are both rated High, as sensitive source code, secrets embedded in repositories, and repository history may be exposed or tampered with. Availability is not impacted. Importantly, the attacker must already hold a valid token for a user who has normal RBAC access to the target repository, so this does not grant access beyond the token owner's existing repository permissions (GitHub Advisory).

1. Obtain a valid token: Acquire any PAT or OAuth2 token for a user who has normal RBAC access to the target private repository — the token does not need read:repository or write:repository scope; even read:notification suffices.
2. Identify the target: Locate a Gitea instance running version ≤ 1.26.1 with Git Smart HTTP enabled and identify a private repository the token owner can access via RBAC.
3. Craft a Bearer-authenticated request: Send an HTTP GET request to the Git Smart HTTP discovery endpoint using Authorization: Bearer <token> instead of HTTP Basic auth:

   GET /user2/repo2/info/refs?service=git-upload-pack HTTP/1.1
   Host: <gitea-host>
   Authorization: Bearer <token>

4. Receive refs response: The server returns a 200 OK with the repository's ref list, bypassing the scope check entirely.
5. Clone or push: Use standard Git tooling (e.g., git clone, git fetch, git push) with the Bearer token to exfiltrate private repository contents or push unauthorized commits to the repository (GitHub Advisory, Gitea Advisory).

• Network: HTTP GET requests to /<owner>/<repo>/info/refs?service=git-upload-pack or /<owner>/<repo>/info/refs?service=git-receive-pack with an Authorization: Bearer header from unexpected clients or IP addresses; successful 200 OK responses to such requests from tokens not expected to have repository scope.
• Logs: Gitea access logs showing Git Smart HTTP activity (/info/refs, /git-upload-pack, /git-receive-pack) authenticated via Bearer token for users whose tokens should not have repository access; mismatches between token scope and repository operations in audit logs.
• Behavioral: Unexpected repository clone or fetch activity for private repositories, particularly from service accounts or tokens associated with non-repository workflows (e.g., notification integrations); unusual volume of Git HTTP traffic from a single token or IP.

Gitea has released version 1.26.2 which patches this vulnerability by correcting the CheckRepoScopedToken() function to enforce token scopes regardless of whether the token was presented via Basic or Bearer authentication. All users running Gitea ≤ 1.26.1 should upgrade to 1.26.2 immediately. No configuration-based workaround is documented; disabling Git Smart HTTP entirely would mitigate the issue but is likely operationally disruptive. Administrators should also audit token usage logs for signs of scope bypass activity prior to patching (GitHub Advisory, Gitea Advisory).

The vulnerability was reported by ohxorud-dev and remediated by Gitea maintainer lunny. The Gitea release blog announced version 1.26.2 shortly after the advisory was published. The FreeBSD ports tree (FreshPorts/VuXML) also tracked the issue, indicating uptake in downstream package ecosystems. No significant broader media coverage or notable researcher commentary beyond the official advisory has been identified (Gitea Release Blog).