What is the CVSS score of CVE-2026-58417?

CVE-2026-58417 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.2%.

Which versions of Gitea are affected by CVE-2026-58417?

Gitea's REST API unintentionally exposes confidential organization membership through API tokens, information the web interface correctly conceals.. A patch is available.

How to fix or mitigate CVE-2026-58417?

Within 24 hours, identify all Gitea deployments and their current versions; consult the Gitea security advisory and GHSA-jr5x-6h83-wrxf to locate the patched version. Within 7 days, stage and deploy the patched release to all instances, validating that dependent tools and API integrations continue functioning correctly. Within 30 days, audit which users and service accounts hold active API tokens, review logs for unauthorized organization membership enumeration attempts, and restrict API scopes to minimum necessary permissions.

Gitea CVE-2026-58417

EUVD-2026-58152 HIGH

Information Exposure (CWE-200)

2026-07-21 https://github.com/go-gitea/gitea

GHSA-jr5x-6h83-wrxf

Information Disclosure Gitea

7.5

CVSS 3.1 · Vendor: https://github.com/go-gitea/gitea

Severity by source

Vendor (https://github.com/go-gitea/gitea) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

vuln.today AI

6.5 MEDIUM

PoC requires an authenticated API token (PR:L); pure information disclosure with no integrity or availability impact (I:N, A:N).

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Red Hat

4.3 MEDIUM

qualitative

Primary rating from Vendor (https://github.com/go-gitea/gitea).

CVSS VectorVendor: https://github.com/go-gitea/gitea

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Analysis Updated

Aug 14, 2026 - 18:49 vuln.today

v3 (cvss_changed)

Analysis Updated

Aug 14, 2026 - 18:47 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Aug 14, 2026 - 18:22 vuln.today

cvss_changed

CVSS changed

Aug 14, 2026 - 18:22 NVD

7.5 (HIGH)

Source Code Evidence Fetched

Jul 21, 2026 - 21:18 vuln.today

Analysis Generated

Jul 21, 2026 - 21:18 vuln.today

DescriptionCVE.org

Summary

The endpoint "/orgs/{org}/public_members/{username}" + GET exposes organization membership of public members in a private organization.

PoC

Spin up the nightly container of Gitea.
Perform the default installation.
Register a new user (let's call this user "user1").
Create a new organization with "private" visibility. We will refer to this organization as "user1org".
Make the user "user1" inside the organization visible.
Log out and register a new user ("user2").
Create an access token for "user2" with full access to the API.
Use the endpoint "/orgs/{org}/public_members/{username}" + GET with the correct username of "user1", organization name, and access token of "user2" to query whether "user1" is a member of the organization. The following curl command demonstrates the usage:

curl -X 'GET' \ 'http://localhost:4700/api/v1/orgs/user1org/public_members/user1' \ -H 'accept: application/json' \ -H 'authorization: token <user2-token>'

You will receive status code 204, which leaks the organization membership.

Impact

The vulnerability discloses organization membership. An information that is not accessible via the web app (the organization is hidden, and therefore, the organization membership on the user's profile page is also hidden).

AnalysisAI

Gitea's REST API leaks private organization membership through the GET /orgs/{org}/public_members/{username} endpoint, bypassing the visibility controls that correctly conceal this information in the web UI. All versions up to and including 1.26.4 are affected, permitting any user with a valid API token to confirm whether a specific user belongs to a hidden organization - data intentionally withheld from the web interface. No public exploit is confirmed in CISA KEV, though a detailed proof-of-concept with curl commands is documented in GHSA-jr5x-6h83-wrxf; EPSS stands at 0.16% (5th percentile), indicating low observed exploitation probability.

Technical ContextAI

Gitea is a self-hosted Git service written in Go (CPE: pkg:go/gitea.dev). The vulnerability originates in routers/api/v1/org/member.go, where both the ListPublicMembers and IsPublicMember API handlers were missing a call to HasOrgOrUserVisible() before processing requests. This function gates visibility of an organization based on its privacy setting and the requesting user's relationship to it. Without this check, the handlers responded to any authenticated request - returning HTTP 204 to confirm membership - regardless of whether the organization was configured as private. The web application correctly hides private organization membership on user profile pages, making this an API-layer access control gap. CWE-200 (Exposure of Sensitive Information to Unauthorized Actor) applies: the system possessed the correct logic to restrict disclosure but failed to invoke it consistently across API and web surfaces. The patch (PR #38145, commit 685b62c) adds the HasOrgOrUserVisible gate to both handlers, returning HTTP 404 rather than 204 when the requesting user lacks visibility into the organization, treating the organization's existence itself as non-disclosable.

RemediationAI

Upgrade to Gitea 1.27.0, which resolves this issue via commit 685b62c60fc595e3612a85f0895471876db56292, merged in pull request https://github.com/go-gitea/gitea/pull/38145; the release is documented at https://blog.gitea.com/gitea-1.27.0-is-released/ and the advisory at https://github.com/go-gitea/gitea/security/advisories/GHSA-jr5x-6h83-wrxf. For installations that cannot immediately upgrade, two compensating controls are available: first, block or rate-limit access to the API path pattern /api/v1/orgs/*/public_members* at a reverse proxy or WAF layer - this eliminates the leak but also disables legitimate public member lookups for all clients; second, audit every private organization and set all member visibility to hidden (non-public), ensuring no members have publicized their membership within private organizations - this removes the data the endpoint would disclose, but requires per-organization auditing and ongoing policy enforcement. Neither workaround substitutes for patching, and both carry operational trade-offs for legitimate use of the public member feature.