CVE-2025-8110

What it actually does

The flaw is an improper symbolic-link handling issue in Gogs' PutContents API. A user able to invoke repository content-write functionality can cause Gogs to follow a crafted symlink and write content to an unintended local filesystem path instead of safely constraining the write to the repository path. Depending on filesystem permissions and deployment layout, this can enable arbitrary file write and local code execution as the operating-system account running Gogs, for example by modifying executable hooks, startup/configuration files, or other writable files that are later executed or loaded by the service.

Why it matters to the business

Compromise of a Gogs instance can expose private source code, credentials embedded in repositories, CI/CD secrets, deployment keys, and release artifacts. Because source-control systems are often trusted by build and deployment pipelines, successful exploitation can become a supply-chain foothold that allows attackers to tamper with code, insert backdoors, disrupt development operations, or pivot into connected infrastructure. This issue is listed in CISA KEV, has active in-the-wild exploitation, and has a high EPSS score, so internet-exposed or self-registration-enabled Gogs deployments should be treated as urgent and remediated before the KEV due date of 2026-02-02.

How an attack unfolds

An attacker first obtains the ability to write repository contents through Gogs, commonly by using a compromised account, abusing open registration, or gaining collaborator access to a repository. The attacker then creates or manipulates a repository path involving a symbolic link and uses the PutContents API to write data through that symlink. Because vulnerable versions do not correctly reject or resolve the symlink boundary, the write lands outside the intended repository content path. The attacker targets a file that can influence execution, such as a Git hook, service-loaded configuration, scheduled task, shell profile, or another writable execution point. Once Gogs or Git performs the relevant action, or the service reloads the modified file, attacker-controlled code runs locally under the Gogs service account. Active exploitation campaigns have been reported against this vulnerability, so defenders should assume that exposed vulnerable instances may have been probed or exploited.

How to fix it

Upgrade Gogs to a version containing commit 553707f3fd5f68f47f531cfcff56aa3ec294c6f6 or a later release that includes this fix. If an immediate upgrade is not possible, restrict access to the Gogs web and API interfaces to trusted networks, disable open user registration, remove unnecessary repository write permissions, and block or closely monitor API content-write operations. Run Gogs with a dedicated least-privilege operating-system account that cannot write to system directories, service manager paths, shell startup files, cron directories, SSH authorized_keys files, or other sensitive locations. Review repository hooks and filesystem permissions, and consider temporarily disabling custom hooks where operationally feasible until the fix is deployed.

How to confirm the fix worked

Confirm the deployed Gogs build includes commit 553707f3fd5f68f47f531cfcff56aa3ec294c6f6 or a vendor release that incorporates it. Inventory all exposed Gogs instances, including container images and bundled deployments, and verify the running binary version rather than only package metadata. Test that content-update requests involving symlinks are rejected or safely constrained to the repository path. Confirm that untrusted users cannot self-register or obtain repository write permissions unexpectedly. After patching, review the filesystem for unauthorized modifications to hooks, configuration files, cron/systemd paths, SSH keys, and files owned by the Gogs service account that changed during the exposure window.

Typical attack path

1. Identify a reachable Gogs instance and determine whether API access, registration, or repository write permissions are available.
2. Obtain or abuse a Gogs account with permission to create or modify repository contents.
3. Create or modify a repository entry involving a symbolic link that points to a sensitive local filesystem target writable by the Gogs process.
4. Send a crafted PutContents API request to write attacker-controlled content through the symbolic link.
5. Trigger execution by causing Git hooks, service configuration, scheduled jobs, or other modified execution points to run.
6. Establish persistence, access private repositories and secrets, or pivot to CI/CD and deployment infrastructure.

How to detect it

Review Gogs application logs, HTTP access logs from Gogs and any reverse proxy, authentication logs, repository audit events, filesystem metadata, and operating-system process execution telemetry for activity during the vulnerable exposure window. Look for PUT requests to repository contents API paths, especially from new users, unusual IP addresses, newly issued API tokens, or requests involving encoded traversal-like path components. Investigate recent creation or modification of symbolic links in repositories and any file writes outside expected repository working paths by the Gogs service account. Examine Git hook directories for new or modified executable files, including pre-receive, post-receive, update, pre-commit, post-commit, and post-update hooks. Correlate suspicious content-write activity with child processes spawned by Gogs or Git such as shells, curl/wget, Python, Perl, nc, bash, sh, chmod, chattr, or package managers. Review system locations commonly abused for persistence, including cron directories, systemd unit paths, SSH authorized_keys, shell profiles, Gogs custom configuration, and writable web/script directories. If active exploitation is suspected, image the host, preserve logs, rotate Gogs tokens and repository secrets, and inspect source repositories for unauthorized commits or backdoors.

• PUT /api/v1/repos/
• /contents/
• PutContents
• ../
• ..%2f
• %2e%2e%2f
• %2f..%2f
• gogs-repositories
• /hooks/pre-receive
• /hooks/post-receive
• /hooks/update
• /hooks/post-update
• /hooks/pre-commit
• /hooks/post-commit
• custom/conf/app.ini
• /home/git/.ssh/authorized_keys
• /var/spool/cron/
• /etc/cron.d/
• /etc/systemd/system/
• /usr/lib/systemd/system/
• /etc/init.d/
• /etc/profile.d/
• /bin/sh -c
• /bin/bash -c
• curl http
• wget http
• chmod +x
• chattr +i
• nc -e
• bash -i

What your security team should do

• Patch or upgrade all Gogs deployments to a fixed build containing commit 553707f3fd5f68f47f531cfcff56aa3ec294c6f6 or later as the highest priority.
• Treat internet-facing vulnerable instances as potentially compromised because the vulnerability is in KEV, has active in-the-wild exploitation, and has high exploitation probability.
• Restrict Gogs administrative and API access with network controls, SSO/MFA where available, and least-privilege repository permissions.
• Disable open registration and audit recently created users, access tokens, deploy keys, collaborators, and repositories.
• Hunt for suspicious PutContents API activity, symlink manipulation, unexpected Git hook changes, and process execution spawned by the Gogs service account.
• Rotate credentials that may be stored in repositories, Gogs configuration, deploy keys, webhooks, CI/CD integrations, or environment files if exploitation cannot be ruled out.
• Preserve logs and filesystem metadata before remediation if incident response is required.