CVE-2026-58438

LOWPre-NVD 0.0
0.0
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No confirmed exploitation signals yet
CISA-KEV: Not listedEPSS: —CVSS: —Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

Gitea: Cross-repository IDOR in issue-dependency removal lets an attacker tamper with and comment on private repos they cannot access

Details

RemoveDependency in routers/web/repo/issue_dependency.go takes a removeDependencyID form parameter identifying the other issue by its global numeric ID, and fetches it with issues_model.GetIssueByID(ctx, depID) - no repository or permission check at all. It then calls issues_model.RemoveIssueDependency(ctx, ctx.Doer, issue, dep, depType) (models/issues/dependency.go), which deletes the dependency join row and then writes a comment referencing the removal, attributed to the calling user, onto the dependency record.

The sibling function in the very same file, AddDependency, does this correctly when the two issues are in different repos (which ALLOW_CROSS_REPOSITORY_DEPENDENCIES, on by default, permits):

if issue.RepoID != dep.RepoID {
  if !setting.Service.AllowCrossRepositoryDependencies { ... }
  depRepoPerm, err := access_model.GetDoerRepoPermission(ctx, dep.Repo, ctx.Doer)
  if !depRepoPerm.CanReadIssuesOrPulls(dep.IsPull) {
    return // you can't see this dependency
  }
}

RemoveDependency has no equivalent block at all - it goes straight from resolving dep by ID to deleting the link, regardless of which repo dep lives in or whether the caller can see it. I confirmed this same code is present in the current latest release, v1.26.4.

PoC

Prerequisites: an account with write access to issues on some repo ownerA/repoA, and the global numeric issue ID of an issue in a private repo repoB that is (or was) legitimately dependency-linked to one of the attacker's issues in repoA (cross-repo dependencies are commonly used between related public/private repos, and ALLOW_CROSS_REPOSITORY_DEPENDENCIES defaults to enabled).

curl -s -b "gitea_session=$ATTACKER_SESSION_COOKIE" -X POST \
  --data-urlencode "removeDependencyID=" \
  --data-urlencode "dependencyType=blockedBy" \
  "https://TARGET_HOST/ownerA/repoA/issues/N/dependency/delete"

Expected: the dependency link is deleted and a "removed dependency" comment


authored by the attacker is added to the repoB issue, even though the


attacker has no read access to repoB.

Impact

This is a cross-repository IDOR / broken access control issue. An attacker can tamper with issue-tracking state (dependency relationships) and inject an attacker-authored comment into a private repository they cannot otherwise read or write to, crossing a trust boundary the "add" path explicitly enforces. Impact is bounded - it requires an existing dependency link and discloses no repository content - but it is a genuine unauthorized-write primitive across a private-repo boundary.

Fix

Add the same cross-repo permission check used in AddDependency (access_model.GetDoerRepoPermission(ctx, dep.Repo, ctx.Doer).CanReadIssuesOrPulls(dep.IsPull)) to RemoveDependency before allowing the deletion to proceed when issue.RepoID != dep.RepoID.

If possible, please apply for a CVE number when publishing. I would greatly appreciate it.

CVSS v3
—
EG Score
0.0(none)
EG Risk
0
EG Risk 0/100

EG Risk is EchelonGraph's 0–100 priority score. It fuses intrinsic severity with real-world exploitation and automatability, so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. It is distinct from the 0–10 EG Score, which measures severity.

EPSS
—
KEV
Not listed

Published

July 21, 2026

Last Modified

July 21, 2026

Vendor Advisories for CVE-2026-58438(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Affected Packages

(1 across 1 ecosystem)
Go(1)
PackageVulnerable rangeFixed inDependents
gitea.dev—1.27.0—

Data Freshness Timeline

(refreshed 2× in last 7d / 2× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-23 03:21 UTCEG score recompute
  2. 2026-07-21 21:21 UTCEG score recompute

Frequently asked(3)

What is CVE-2026-58438?
CVE-2026-58438 is a low vulnerability published on July 21, 2026. Gitea: Cross-repository IDOR in issue-dependency removal lets an attacker tamper with and comment on private repos they cannot access Details RemoveDependency in routers/web/repo/issuedependency.go takes a removeDependencyID form parameter identifying the other issue by its global numeric ID, and…
When was CVE-2026-58438 disclosed?
CVE-2026-58438 was first published in the National Vulnerability Database on July 21, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
How do I remediate CVE-2026-58438?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-58438, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2026-58438

Explore →

Is Your Infrastructure Affected by CVE-2026-58438?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.

Start Free Scan →Browse All CVEs