Improper authorization control for web services In gogs.io/gogs

Description

Gogs allows users to write to readonly repositories using receive-pack + service=git-upload-pack confusion

Summary

Git smart HTTP authorizes POST …/git-receive-pack using the client-supplied service query string (so ?service=git-upload-pack is evaluated as read access) while routing still runs git receive-pack, allowing push where only read should be allowed.

Details

Gogs' Git Smart HTTP handler for repository RPCs relies on a client-supplied query parameter to decide which authorization policy to apply. The Git protocol exposes two primary RPCs over HTTP: upload-pack for fetch (read) and receive-pack for push (write).

In the affected implementation, the code derives the access mode from the service query parameter (for example, service=git-upload-pack) instead of the actual RPC path being executed. As a result, a request sent to the receive-pack endpoint can be incorrectly treated as a read operation if the query parameter claims it is an upload-pack. This behavior enables a request to POST to the write endpoint (/repo.git/git-receive-pack) while including a query string that indicates a read service.

Route dispatch still executes the receive-pack code path, but authorization is evaluated as if the request were a read. A user who is normally only allowed to read a repository, can now write to it.

One edge case is fully public repositories, viewable by anonymous users. Since performing this exploit results in a AuthUser property becoming nil in this case, a part of the code that uses it crashes (500 Internal Server Error), making it impossible to exploit.

The two situations in which this is vulnerable are:

    Attacker = collaborator with only Read rights & victim = owner of the repository

    Instance using REQUIRE_SIGNIN_VIEW = true. Attacker = any signed in user & victim = any user with a public repository

PoC

    Create a Gogs instance (eg. http://localhost:3000) with 2 users: victim & attacker

    As the victim, create a new private repository and add the attacker as a Read collaborator:

image

    As the attacker, execute the following Python script (editing global vars as required):

from __future__ import annotations

import os
import shutil
import subprocess
import sys
import tempfile
import threading...

    Reload the repo URL and notice the attacker successfully wrote to the read-only repo:

image

Impact

If you can read a repository, and an anonymous user cannot, you can write to it. This affects some cases where read-only collaborator access is given, but is most impactful in instances with REQUIRE_SIGNIN_VIEW = true configured, because then all repositories will be writable to any user. Using force push this can also affect availability, as the original code in the main branch, for example, can be overridden without leaving history.

Mitigation

Update Impact

Minimal update. May introduce new vulnerabilities or breaking changes.

Ecosystem
Package
Affected version
Patched versions