PT-2026-63303 · Go · Code.Gitea.Io/Gitea

CVE-2026-58437

·

Published

2026-07-21

·

Updated

2026-07-21

CVSS v3.1

7.1

High

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

Repository Visibility Manipulation via Git Push Options

FieldValue
Affected Filerouters/private/hook post receive.go
Affected FunctionHookPostReceive()
Affected Lines173–225
PrerequisiteAttacker must have owner-level or admin collaborator access to the target repository

Description

Gitea's post-receive git hook handler processes git push options — key-value pairs transmitted by a client during git push using the -o flag. Two undocumented push options, repo.private and repo.template, allow any user with repository owner or admin-collaborator access to toggle the visibility (private/public) and template status of a repository as a side effect of a normal git push.
This capability was originally intended solely for the "push-to-create" feature (automatically creating a repo on first push). However, the options are processed without restriction on already-existing repositories, and — critically — the visibility change bypasses every control that a proper settings change would trigger:
  • No entry written to the repository's audit/activity log
  • No webhook event fired (repository event with visibility changed action)
  • No org-level notification to owners
  • No team permission re-calculation
  • No email alert to watchers
  • The database update uses UpdateRepositoryColsNoAutoTime, which also suppresses the updated at timestamp change

Vulnerable Code

routers/private/hook post receive.go:173–225
go
isPrivate := opts.GitPushOptions.Bool(private.GitPushOptionRepoPrivate) // "repo.private"
isTemplate := opts.GitPushOptions.Bool(private.GitPushOptionRepoTemplate) // "repo.template"

if isPrivate.Has() || isTemplate.Has() {
  // ... loads repo and verifies pusher is owner or admin ...
  if !perm.IsOwner() && !perm.IsAdmin() {
    ctx.JSON(http.StatusNotFound, ...)
    return
  }

  // FIXME: these options are not quite right, for example: changing visibility
  //    should do more works than just setting the is private flag
  // These options should only be used for "push-to-create"
  if isPrivate.Has() && repo.IsPrivate != isPrivate.Value() {
    // TODO: it needs to do more work
    repo.IsPrivate = isPrivate.Value()
    repo model.UpdateRepositoryColsNoAutoTime(ctx, repo, "is private")
    //     ^^^ bypasses updated at timestamp, audit trail suppressed
  }
  if isTemplate.Has() && repo.IsTemplate != isTemplate.Value() {
    repo.IsTemplate = isTemplate.Value()
    repo model.UpdateRepositoryColsNoAutoTime(ctx, repo, "is template")
  }
}
The push option constants are defined in modules/private/pushoptions.go:18–19:
go
GitPushOptionRepoPrivate = "repo.private"
GitPushOptionRepoTemplate = "repo.template"

Attack Scenario

Scenario A — Insider threat / rogue admin collaborator
An organization grants a contractor repo admin access to contribute to a private repository containing proprietary source code. The contractor, before their access is revoked, makes a private repo public for several minutes — long enough to clone, archive, or index the content — then makes it private again. The action leaves no audit trail distinguishable from a normal git push.
Scenario B — Supply-chain template poisoning
A repository marked as a template is used by CI/CD pipelines to generate new project repositories. An admin collaborator uses repo.template=false to silently remove the template designation, then makes changes to the repo's content, re-marks it as a template with repo.template=true, and waits for downstream consumers to regenerate projects from the now-backdoored template. The updated at timestamp is unchanged due to UpdateRepositoryColsNoAutoTime, making diff-detection harder.

Step-by-Step Reproduction

Prerequisites:
  • A Gitea user account with either owner or admin-collaborator access to a private repository
  • git client with push access to the repository
Step 1 — Confirm the target repository is private
Step 2 — Clone the repository
bash
git clone http://USER:PASSWORD@<gitea-host>/OWNER/REPO.git /tmp/target-repo
cd /tmp/target-repo
Step 3 — Make any commit (the push option rides on a real push)
bash
echo "$(date)" >> .gitkeep
git add .gitkeep
git commit -m "routine update"
Step 4 — Execute the exploit push
bash
# Make the repository public
git push http://USER:PASSWORD@<gitea-host>/OWNER/REPO.git main 
 -o repo.private=false

# The push completes with a normal success message:
#  remote: Processed 1 references in total
#  To http://<gitea-host>/OWNER/REPO.git
#   abc1234..def5678 main -> main
Step 5 — Verify the repository is now public
Step 6 — Restore and cover tracks
Re-make it private in the same session, leaving no visible audit trail
The repository activity feed shows only two normal push events. The visibility change is invisible.
Verification: confirm no activity log entry

Impact Details

ImpactDescription
Data exfiltrationPrivate source code, CI/CD secrets in plain-text files, environment configs become publicly cloneable for the window the repo is public
No audit trailUpdateRepositoryColsNoAutoTime suppresses the updated at change; no activity log entry; no webhook; no notification
Supply chainCombined with repo.template=true/false, an attacker can silently rotate repository template status, affecting all downstream repositories that generate from this template
ScopeAffects all repos where the attacker has admin-collaborator access — not only repos they own

Recommended Fix

Option 1 (preferred) — Remove the options from post-receive hook entirely. The repo.private and repo.template push options were designed for the push-to-create flow and have no legitimate use on existing repositories. They should be gated with:
go
// routers/private/hook post receive.go
if isPrivate.Has() || isTemplate.Has() {
  if !wasEmpty {
    // repo already existed — refuse these options on established repos
    log.Warn("Repo push options repo.private/repo.template ignored for existing repo %s", repoName)
    // do not process
  } else {
    // original push-to-create path only
    ...
  }
}
Option 2 — Route through the full visibility-change service so that audit events, webhooks, and team re-syncs are triggered:
go
// Instead of the raw UpdateRepositoryColsNoAutoTime call:
if err := repo service.UpdateRepositoryVisibility(ctx, repo, isPrivate.Value()); err != nil {
  ...
}
Where UpdateRepositoryVisibility fires the repository webhook event and writes an activity log entry.

Fix

Improper Access Control

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-284

Related Identifiers

CVE-2026-58437
GHSA-8P9H-49RC-QGXJ

Affected Products

Code.Gitea.Io/Gitea