Gitea CVE-2025-68945

Requires a network-reachable Gitea instance running a version before 1.21.2 that hosts at least one private (or limited-visibility) individual user account with a projects page. Per the CVSS vector (PR:N/UI:N), exploitation is unauthenticated and needs no user interaction - an anonymous HTTP GET to the private user's project route (e.g. /{user}/-/projects) suffices, because individual user permissions were not checked after org-assignment. Limiting factors: impact is confined to disclosure of private user project pages (C:L, no I/A impact); the instance must expose such private user projects and be reachable by the attacker; patched versions (1.21.2+) return HTTP 404 to anonymous and non-owner, non-admin users.

Signals are consistent and point to a genuine but modest-severity information-disclosure issue rather than a top-priority emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N = 5.3 Medium) describes a remotely reachable, trivially executed, unauthenticated flaw affecting only confidentiality at a LOW level, with no integrity or availability impact - matching CWE-359 (exposure of private information). EPSS is low at 0.36% (27th percentile), the CVE is NOT on CISA KEV, and no public exploit is indicated; these three low-probability signals reinforce one another and argue against widespread active exploitation. The only amplifying factor is that no authentication or user interaction is required, so exploitation is technically easy - but the payoff is limited to viewing private user project pages, not code execution or credential theft. Net: a real, patch-worthy bug for Gitea operators but a routine-priority item, not a drop-everything issue. No signals conflict; the main gap is that exploit/POC status is not reported in the input (treated here as none identified).

An unauthenticated attacker browsing a publicly reachable Gitea instance (version before 1.21.2) directly requests the projects URL of a private individual user, e.g. GET /user31/-/projects, and the server returns the private project page instead of a 404. No exploit code is required beyond a normal HTTP GET; the leaked data is limited to the private user's project information. No public POC is identified in the provided data, though the fix PR includes an integration test demonstrating the pre-patch behavior.