Skip to main content

Gogs CVE-2026-52815

| EUVDEUVD-2026-39061 MEDIUM
Information Exposure (CWE-200)
2026-06-23 https://github.com/gogs/gogs GHSA-744x-3838-5r56
5.5
CVSS 4.0 · Vendor: https://github.com/gogs/gogs
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Send unauthenticated GET to /api/v1/orgs/:org/teams
  2. Delivery
    orgAssignment middleware loads org, skips auth
  3. Exploit
    ListTeams returns all team metadata
  4. Execution
    Harvest team IDs and permission levels
  5. Persist
    Identify owner/admin teams as targets
  6. Impact
    Use team data in further API reconnaissance

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V14 - Data Protection Data exposure prevention
MITRE ATT&CK

2 techniques across 2 tactics: Collection, Discovery

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

No special conditions are required beyond network access to the Gogs API port (default TCP/3000). The Gogs instance must have at least one organization with teams configured, but that is a standard deployment pattern. The CVSS vector (self-assessed) is AV:N/AC:L/PR:N/UI:N, confirming unauthenticated remote exploitation against default configurations of Gogs. What limits exploitation scope: the disclosed data is organizational metadata only (team names, IDs, descriptions, permission levels) - not credentials, tokens, or repository contents. Organizations using Gogs in a fully private network with no external API exposure are not reachable from the internet, but any internet-facing Gogs instance is trivially exploitable without credentials.

Impact

No vendor-supplied CVSS vector was provided, so risk must be derived from the description and exploit mechanics. The vulnerability is network-reachable, requires zero authentication, zero privileges, and zero user interaction, placing it firmly in the CVSS medium range with a self-assessed vector of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N (approximately 5.3). The confidentiality impact is limited - team metadata (names, IDs, permission levels) is sensitive organizational structure data but does not directly expose credentials, source code, or secrets. However, the tags correctly flag a privilege escalation aid: harvested team IDs and permission mappings can be fed into other API endpoints to identify high-value targets or exploit weaker authorization checks elsewhere. A public proof-of-concept exists per the GHSA advisory, lowering the skill floor to near-zero. No EPSS score is available; no KEV listing exists. Real-world priority is moderate: the fix is a single line change and the patch (v0.14.3) is available, making remediation straightforward with minimal operational risk.

Exploit ScenarioDerived

An external attacker with HTTP access to a Gogs instance sends GET /api/v1/orgs/target-org/teams with no authentication headers. The server responds with a 200 OK containing the full team list including team IDs, names, permission levels, and descriptions. The attacker identifies the team ID for an owner/admin team and uses that ID in subsequent API calls - potentially targeting endpoints with weaker authorization - to escalate access or pivot against team members. A working proof-of-concept using a single curl command is published in the GHSA advisory.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 1.6% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jun 23, 2026

Unauthenticated organization team enumeration in Gogs exposes team IDs, names, descriptions, and permission levels (read/write/admin/owner) to any network-accessible caller without credentials. All versions prior to 0.14.3 are affected - the GET /api/v1/orgs/:orgname/teams endpoint was placed in a route group missing the reqToken() middleware, meaning the orgAssignment(true) middleware loads the org object but enforces no authentication. A publicly available proof-of-concept demonstrates exploitation via a single unauthenticated curl command. No KEV listing is present, but the low attack complexity and zero authentication requirement make this a meaningful reconnaissance aid for follow-on attacks against Gogs installations.

RemediationAI

Upgrade to Gogs v0.14.3, which applies the one-line fix from PR #8336 (commit 2ebc0e27069deade992219e10a89fbc44bec8bb9) adding reqToken() middleware to the org teams route group. The patched release is at https://github.com/gogs/gogs/releases/tag/v0.14.3. If immediate upgrade is not possible, a compensating control is to place the Gogs API behind a network perimeter that restricts unauthenticated external access to /api/v1/orgs/*/teams - for example, via a reverse proxy ACL or WAF rule blocking unauthenticated requests to that path pattern. This has the trade-off of potentially disrupting legitimate API integrations if those integrations incorrectly assume no authentication is needed. The GHSA advisory also recommends that ListTeams() internally verify the authenticated user is a member of the queried organization, which is an additional defense-in-depth improvement beyond the middleware fix.

Affected VersionsENISA

gogs < 0.14.3

Affected Packages

go gogs.io/gogs fix: 0.14.3
euvd gogs fix: 0.14.3

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Gogs is a self-hosted Git service written in Go. Its API routing layer uses the Macaron web framework, where middleware is chained per route group. The root cause (CWE-200: Exposure of Sensitive Information to an Unauthorized Actor) is a missing reqToken() middleware call on the /:orgname group that handles /teams. The orgAssignment(true) middleware correctly resolves the organization object by name but performs no authentication gate - it is purely a data-loading helper. The ListTeams() handler at internal/route/api/v1/org_team.go:8 calls database.GetTeamsByOrgID() unconditionally with no c.IsLogged or membership check. The affected package is gogs.io/gogs (Go module), versions less than 0.14.3 per the GHSA advisory and confirmed CPE data.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/gogs/gogs) PRIMARY 5.5 MEDIUM
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P
vuln.today AI 5.3 MEDIUM

Network-reachable, no auth (PR:N), exposes only team metadata so confidentiality impact is Low, no integrity or availability impact.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
SUSE MEDIUM

Primary rating from Vendor (https://github.com/gogs/gogs).

CVSS VectorVendor: https://github.com/gogs/gogs

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
Low
Vulnerable system: Integrity
None
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

1
CVSS changed
Jun 24, 2026 - 21:22 NVD
5.5 (MEDIUM)

DescriptionCVE.org

Summary

Gogs has an unauthenticated information disclosure vulnerability. The GET /api/v1/orgs/:orgname/teams endpoint at internal/route/api/v1/org_team.go:8 returns all teams for any organization without requiring authentication. The route group at internal/route/api/v1/api.go:380-385 lacks the reqToken() middleware, and the listTeams() handler performs no authentication check, exposing team IDs, names, descriptions, and permission levels to any unauthenticated caller.

Affected Versions

Gogs (all current versions)

Vulnerability Details

Root Cause: Missing reqToken() middleware on org teams route group

internal/route/api/v1/api.go lines 380-385:

go
// Org teams route group - no reqToken() middleware
m.Group("/:orgname", func() {
    m.Get("/teams", org.ListTeams) // No auth required
}, orgAssignment(true))

The orgAssignment(true) middleware only loads the organization object - it performs no authentication. The listTeams() handler at org_team.go:8 returns all teams unconditionally:

go
func ListTeams(c *context.APIContext) {
    org := c.Org.Organization
    teams, err := database.GetTeamsByOrgID(org.ID)
    // Returns all teams - no c.IsLogged check, no permission check
}

Compare with other org endpoints that correctly require authentication:

go
m.Group("/orgs/:orgname", func() {
    // ... other endpoints ...
}, reqToken(), orgAssignment(true, true)) // reqToken() enforces auth

Attack Chain

  • Attacker sends GET /api/v1/orgs/target-org/teams with no authentication
  • orgAssignment(true) loads the organization but does not check auth
  • ListTeams() queries all teams and returns them
  • Response includes team IDs, names, descriptions, and permission levels (read/write/admin/owner)

Proof of Concept

bash
# List all teams in an organization - no authentication needed
curl -s "http://TARGET:3000/api/v1/orgs/myorg/teams" | python3 -m json.tool
# Expected: 200 OK with full team list
# [
#   {
#     "id": 1,
#     "name": "Owners",
#     "description": "Admin team",
#     "permission": "owner"
#   },
#   {
#     "id": 2,
#     "name": "backend-devs",
#     "description": "Backend development team",
#     "permission": "write"
#   }
# ]

Impact

An unauthenticated attacker can:

  • Enumerate all teams within any organization, including private/internal teams
  • Discover team permission levels (read/write/admin/owner), aiding privilege escalation planning
  • Map organizational structure and identify high-value targets (admin/owner teams)
  • Harvest team IDs for use in other API calls that may have weaker authorization checks

Suggested Remediation

go
m.Group("/:orgname", func() {
    m.Get("/teams", org.ListTeams)
}, reqToken(), orgAssignment(true))

Add reqToken() middleware to the org teams route group, consistent with other authenticated org endpoints. Additionally, ListTeams() should verify the authenticated user is a member of the organization.

Threat Intelligence Overview

EPSS Score
1.6%
Top 28% exploitable
Prevalence
Low
niche self-hosted Git alternative, overshadowed by GitLab and Gitea
Threat Intel
1
1 sources
Exploit
POC
Public exploit code exists
Social Media
1
Sightings
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC Yes
EPSS 1.6%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
Poc
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact· derived
Medium

Priority Score

50
Low Medium High Critical
KEV: 0
EPSS: +2
CVSS: +28
PoC: +20
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP5 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP6 Affected
openSUSE Leap 15.5 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy