Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSend unauthenticated GET to /api/v1/orgs/:org/teams
-
DeliveryorgAssignment middleware loads org, skips auth
-
ExploitListTeams returns all team metadata
-
ExecutionHarvest team IDs and permission levels
-
PersistIdentify owner/admin teams as targets
-
ImpactUse 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 an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – 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
Affected Packages
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
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
Network-reachable, no auth (PR:N), exposes only team metadata so confidentiality impact is Low, no integrity or availability impact.
Primary rating from Vendor (https://github.com/gogs/gogs).
CVSS VectorVendor: https://github.com/gogs/gogs
Lifecycle Timeline
1DescriptionCVE.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:
// 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:
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:
m.Group("/orgs/:orgname", func() {
// ... other endpoints ...
}, reqToken(), orgAssignment(true, true)) // reqToken() enforces authAttack Chain
- Attacker sends
GET /api/v1/orgs/target-org/teamswith no authentication orgAssignment(true)loads the organization but does not check authListTeams()queries all teams and returns them- Response includes team IDs, names, descriptions, and permission levels (read/write/admin/owner)
Proof of Concept
# 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
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
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.
What every action level means
SSVC AssessmentENISA
Priority Score
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.
Same weakness CWE-200 – Information Exposure
View allSame technique Privilege Escalation
View allVendor 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 |
| openSUSE Leap 15.6 | Affected |
EUVD-2026-39061
GHSA-744x-3838-5r56
NVD
CVE.org
EPSS
Exploit-DB