Eddieran

**Name of the Vulnerable Software and Affected Versions** Gitea versions 1.25.4 through 2026-05-16 **Description** When a public repository is changed to private via the REST API, watch records are not properly cleared. This occurs because the `updateRepository()` function, which is utilized by the `PATCH /api/v1/repos/{owner}/{repo}` endpoint, fails to call the `ClearRepoWatches` function, unlike the web UI path. Consequently, users whose access has been revoked can still see the now-private repository in the `GET /api/v1/user/subscriptions?private=true` endpoint, exposing sensitive metadata such as the repository description, default branch, language, and license list. Additionally, this issue allows the `NumWatches` counter to remain inflated and creates a potential for content leakage through future notification paths that may lack proper access checks. **Recommendations** In the `updateRepository()` function within `services/repository/repository.go`, add a call to `ClearRepoWatches` immediately after `ClearRepoStars` when a repository is set to private. As a temporary mitigation, avoid using the `PATCH /api/v1/repos/{owner}/{repo}` endpoint to change repository visibility to private and use the web UI Settings instead.

**Name of the Vulnerable Software and Affected Versions** NocoDB versions prior to 2026.05.1 **Description** A flaw in the token-exchange flow allows two concurrent requests using the same OAuth authorization code to each generate a distinct valid `access token` and `refresh token` pair. This occurs because the system previously read the `is used` status and performed the `markAsUsed` update unconditionally at the end of the process, failing the single-use guarantee of PKCE (Proof Key for Code Exchange), a security extension for OAuth 2.0. An attacker who observes an authorization code and the corresponding PKCE verifier could obtain a long-lived refresh token alongside the legitimate user. **Recommendations** Update to version 2026.05.1.