CVE-2024-55947

What it actually does

This is an arbitrary file write/path traversal vulnerability in Gogs. A user who can reach the vulnerable functionality may cause the Gogs server process to write attacker-controlled content outside the intended repository or application path. If the Gogs process has sufficient filesystem permissions, the attacker can place an SSH public key into an authorized_keys file or otherwise modify security-sensitive files, enabling persistent SSH access as the operating-system account running Gogs or as another writable local account. The practical impact can escalate from repository-level access to host-level compromise, depending on service permissions and filesystem layout.

Why it matters to the business

A compromised Gogs instance can expose source code, credentials stored in repositories, CI/CD secrets, deployment keys, and internal development history. Because the flaw can be used to obtain SSH access to the underlying server, it may allow attackers to pivot into build systems, production deployment paths, or other internal infrastructure. Although it is not currently listed in CISA KEV and exploit maturity is reported as none, the EPSS score is high, so internet-facing or broadly accessible Gogs deployments should be treated as urgent remediation targets.

How an attack unfolds

An attacker first obtains access to a vulnerable Gogs deployment, typically as a registered or compromised user with enough privileges to interact with repository features that write files on the server. The attacker then submits crafted input that causes Gogs to resolve a file path outside the intended repository or application directory. Instead of writing only to an expected controlled location, the server writes attacker-supplied content to an arbitrary path that is writable by the Gogs process. A common objective is to write an SSH public key into a writable authorized_keys file for the service account, such as the git or gogs user. The attacker then connects to the server over SSH using the corresponding private key, gaining shell access under that account. From there, they can inspect repositories, steal secrets, alter code, add persistence, or attempt local privilege escalation and lateral movement.

How to fix it

Upgrade Gogs to a version containing commit 0c40e600a275d490481cfeea53705810fbe94d9b or later. If packaged builds are used, install the vendor or distribution release that includes this fix. Until patched, restrict access to Gogs to trusted networks or VPN, disable public self-registration if not required, review and minimize repository write privileges, and ensure the Gogs service account cannot write to sensitive OS locations beyond required application directories. Run Gogs under a dedicated low-privilege account, enforce strict ownership and permissions on home directories and .ssh directories, and consider temporarily disabling SSH access for the Gogs service account if operationally feasible. After patching, rotate potentially exposed SSH keys, deploy keys, access tokens, webhooks secrets, and CI/CD credentials associated with affected repositories.

How to confirm the fix worked

Confirm the running Gogs build includes fixed commit 0c40e600a275d490481cfeea53705810fbe94d9b or a later release that contains it. Validate package provenance if using container images or downstream packages. Check the Gogs version and build metadata from the application UI, binary, package manager, or container image labels. Review filesystem permissions to confirm the Gogs process cannot write to arbitrary user home directories, root-owned paths, or SSH configuration locations. In a controlled test environment only, verify that attempts to write outside allowed repository/application paths are rejected and logged. Confirm no unexpected SSH keys have been added to service-account authorized_keys files and that recent SSH logins for the Gogs-related OS account are legitimate.

Typical attack path

1. Identify a Gogs instance that is vulnerable and reachable over the network.
2. Obtain or use an existing Gogs user account with access to the vulnerable file-writing workflow.
3. Craft input that abuses path traversal or unsafe path handling to target a filesystem location outside the intended directory.
4. Write attacker-controlled content to a sensitive path, commonly an SSH authorized_keys file for a local service account.
5. Authenticate to the server over SSH using the matching private key.
6. Use host access to access repositories, configuration files, secrets, deployment keys, and other local resources.
7. Establish persistence, modify source code, or pivot to connected development and deployment infrastructure.

How to detect it

Investigate whether the Gogs server wrote files outside expected application and repository directories. Review Gogs application logs, web access logs from reverse proxies, SSH authentication logs, auditd or endpoint telemetry, file integrity monitoring, and shell history for the service account. Focus on activity involving path traversal sequences, suspicious repository operations followed by filesystem changes, newly created or modified authorized_keys files, and SSH logins for service accounts that do not normally have interactive sessions. Compare the contents and modification times of .ssh directories for gogs, git, and any account writable by the Gogs process against known-good backups. Search for unexpected SSH public keys, unfamiliar source IPs authenticating as the Gogs service account, new cron/systemd persistence, and post-compromise access to repository secrets or deployment material. If centralized EDR is available, look for Gogs spawning shells, SSH-related processes, file write events to .ssh paths, or unusual child processes from the Gogs service.

• ../
• ../
• ..%2f
• ..%2F
• %2e%2e%2f
• %2E%2E%2F
• .ssh/authorized_keys
• /home/git/.ssh/authorized_keys
• /home/gogs/.ssh/authorized_keys
• /var/lib/gogs/.ssh/authorized_keys
• /data/git/.ssh/authorized_keys
• /root/.ssh/authorized_keys
• authorized_keys
• Accepted publickey for git
• Accepted publickey for gogs
• Failed publickey for git
• Failed publickey for gogs
• sshd: git
• sshd: gogs
• /etc/ssh/sshd_config
• /etc/cron.d/
• /var/spool/cron/
• /etc/systemd/system/

What your security team should do

• Inventory all Gogs deployments, including containers, appliances, developer-hosted instances, and non-production systems.
• Prioritize internet-facing or broadly accessible Gogs instances for immediate upgrade to a build containing commit 0c40e600a275d490481cfeea53705810fbe94d9b or later.
• Disable public self-registration and restrict access to trusted users and networks until remediation is complete.
• Audit local accounts used by Gogs, especially git and gogs, for unexpected SSH keys and recent interactive logins.
• Review Gogs logs, reverse proxy logs, SSH authentication logs, and filesystem modification times for evidence of path traversal, arbitrary file writes, and new authorized_keys entries.
• Rotate repository credentials, deploy keys, personal access tokens, webhook secrets, and CI/CD secrets if compromise cannot be ruled out.
• Harden the service account by limiting shell access, reducing filesystem write permissions, and enforcing least privilege on repository storage and application directories.
• Add monitoring for modifications to SSH authorized_keys files and other persistence-sensitive paths on servers running Gogs.