Listen to this Post
This vulnerability in Gitea versions prior to 1.22.3 stems from improper authorization checks when processing API requests with tokens scoped only to public resources. The system incorrectly validates the token’s scope against the visibility of the requested resource. When an API request is made for a private repository, issue, or other asset, the authorization middleware checks the token’s permissions but fails to adequately verify if the token’s “public-only” scope should be restricted from accessing private entities. The flaw lies in the logic that maps scope permissions to resource visibility levels. A token created with the “public_repo” scope, intended solely for accessing public repositories, is not correctly blocked from making API calls to private repositories belonging to the same user or organization. The request flow bypasses the scope enforcement step after initial authentication, allowing the token to be treated with broader permissions than assigned. This occurs because the scope validation is not integrated with the subsequent access control check that verifies repository privacy status. The token’s identity is correctly authenticated, but the system erroneously grants access based on the user’s overall permissions rather than the token’s limited scope. The vulnerability is triggered when a crafted HTTP request, such as GET /api/v1/repos/private-owner/private-repo, uses a bearer token with only public scope. The API endpoint processes the request, and the authorization layer does not cross-reference the token’s scope with the target resource’s visibility flag before proceeding with the operation. This allows read or write actions depending on the endpoint, contrary to the scope’s intention.
Platform: Gitea
Version: before 1.22.3
Vulnerability: API scope bypass
Severity: Moderate
date: Dec 26 2025
Prediction: Patched Dec 26 2025
What Undercode Say:
Analytics
Generate token with public scope only
curl -X POST -H "Authorization: token <personal_access_token>" -H "Content-Type: application/json" -d '{"name":"public_token", "scopes":["public_repo"]}' https://gitea.instance/api/v1/users/<username>/tokens
Attempt to access private repository with the scoped token
curl -H "Authorization: token <generated_public_token>" https://gitea.instance/api/v1/repos/owner/private-repo
Check server logs for access attempts
tail -f /var/log/gitea/gitea.log
Python script to demonstrate vulnerability
import requests
api_token = "token_with_public_scope_only"
headers = {"Authorization": f"token {api_token}"}
response = requests.get("https://gitea.example.com/api/v1/repos/private_owner/private_repo", headers=headers)
print(response.status_code, response.text)
How Exploit:
Attacker obtains a token scoped to public resources only, via legitimate creation or leak. They then craft API requests to private endpoints using this token. The server grants access, allowing unauthorized reading of private issues, repositories, or metadata. Exploitation requires prior authentication to obtain any valid token, limiting attack surface.
Protection from this CVE
Upgrade to Gitea 1.22.3. Implement network ACLs. Review token scopes. Monitor API logs.
Impact:
Unauthorized data disclosure. Privacy violation. Information leakage.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
