CISA Adds Gogs CVE-2025-8110 to KEV: Urgent Self-Hosted Git Remediation

CISA confirmed on January 12, 2026 that it has added a high‑severity Gogs path‑traversal vulnerability, tracked as CVE‑2025‑8110, to its Known Exploited Vulnerabilities (KEV) Catalog — a move that triggers urgent remediation requirements for federal agencies under Binding Operational Directive (BOD) 22‑01 and raises the alarm for any organization running self‑hosted Gogs instances.

Overview​

CVE‑2025‑8110 is a symbolic link (symlink) path traversal vulnerability in the PutContents API of Gogs, a lightweight, self‑hosted Git service often used as an alternative to larger platforms. The flaw lets a low‑privileged, authenticated user write files outside the intended repository tree by abusing symlinks — enabling file overwrite of sensitive host files and creating a path to remote code execution (RCE). Multiple independent vulnerability trackers and incident reports assigned this issue a high severity rating (CVSS ~8.7) and reported active exploitation in the wild before the KEV addition.
CISA’s KEV addition formalizes the threat: Federal Civilian Executive Branch (FCEB) agencies are required to follow remediation timelines under BOD 22‑01. CISA also explicitly urged all organizations to prioritize remediation of KEV items as part of vulnerability‑management best practices. The KEV listing gives a concrete due date for federal remediation actions and signals that exploit activity has met CISA’s threshold for coordinated federal response.

---

Background: KEV, BOD 22‑01 and why this matters​

What is the KEV Catalog and BOD 22‑01?​

• The Known Exploited Vulnerabilities (KEV) Catalog is CISA’s authoritative, continuously updated list of CVEs for which CISA has evidence of exploitation in the wild. The catalog exists to help defenders prioritize fixes that reduce immediate operational risk.
• Binding Operational Directive (BOD) 22‑01 directs Federal Civilian Executive Branch agencies to remediate listed KEV vulnerabilities by the due date or otherwise mitigate or discontinue use of affected products. While BOD 22‑01 legally applies to FCEB agencies, CISA regularly advises private sector organizations to follow KEV guidance to reduce exposure.

Why being added to KEV changes the game​

Entry into the KEV Catalog elevates a vulnerability from a security advisory into a time‑bound operational obligation for federal agencies. Practically, this means:

• Agencies must inventory exposure and apply mitigations/patches by the CISA KEV due date.
• Security operations and patch teams should prioritize KEV items over routine backlog items.
• Third‑party risk and vendor management teams must query vendors and partners for KEV exposure evidence.
• Even organizations outside government should treat KEV additions as urgent triage items because they reflect active attacker behavior.

---

Technical breakdown: how CVE‑2025‑8110 works​

The PutContents API and the symlink blind spot​

Gogs exposes a PutContents API that allows updates to repository file contents through the application API rather than strictly through standard Git push mechanics. The earlier fix for a prior path‑traversal issue hardened path validation by disallowing dangerous filename patterns, but it did not validate whether a file path resolved to a symbolic link that pointed outside the repository root.
Key points about the vulnerability:

• Attack vector: Network (authenticated user with repository creation or write permissions).
• Root cause: Improper handling of symbolic links when writing files via the PutContents API; the code writes to the file path without checking whether the destination resolves to a symlink pointing outside the repo.
• Impact: Arbitrary file overwrite on the host filesystem; with careful selection of target files (for example, .git/config or other configuration files), an attacker can trigger execution of commands or cause system behavior leading to full system compromise.
• Exploitability: Low complexity for an attacker who has the required repository permissions; the default configuration on many public deployments (open registration) makes that requirement trivial for remote attackers.
• Severity: High (CVSS ~8.7 on the published metric scale).

Typical exploitation chain​

• Attacker creates or controls a repository in a vulnerable Gogs instance (many installations allow open registration by default).
• The attacker commits a symbolic link whose target points to a sensitive file on the host.
• The attacker uses the PutContents API to write content to the symlink path. Because the API follows the link, the write impacts the linked file outside the repository.
• The overwritten target is chosen to alter service configuration or to inject content that will be executed by some service process (for example by manipulating Git config to set an sshCommand or by overwriting deployment scripts).
• The attacker gains execution control, implants backdoors or persists access.

This symlink‑based bypass is functionally a way to bypass normal path‑validation protections that only inspect textual path segments (like ../) rather than resolving filesystem links.

---

What we know about exploitation and scale​

Independent security researchers reported active exploitation months before the KEV addition. Observed indicators included:

• Large‑scale scanning for internet‑facing Gogs instances.
• Creation of many short, randomized repository names on compromised hosts, consistent with automated mass‑exploitation tooling.
• Evidence suggesting hundreds of publicly exposed instances were compromised in researcher scans, with numbers repeatedly reported in the mid‑hundreds (e.g., a >700 count in some investigator summaries).

Caveats and verification:

• The counts of compromised servers come from security vendor research and external scanning heuristics; these are useful indicators but can over‑ or under‑estimate true compromise counts because of sampling, false positives, and differences in internet visibility.
• Multiple independent advisories and vulnerability databases corroborate active exploitation, even if the exact number of compromises is estimates. Where numerical claims appear (such as "700+ servers"), treat those as researcher estimates unless confirmed by centralized telemetry or vendor incident reports.

---

Vendor response and patch status — a nuanced picture​

The public advisory record and repository history show the following:

• GitHub Advisory entries and public vulnerability databases list affected versions as ≤ 0.13.3.
• At the time CISA added CVE‑2025‑8110 to the KEV Catalog, the Gogs ecosystem had commits and pull requests addressing symlink handling — but there were conflicts in public reporting about whether a formal versioned release (for example, an official 0.13.4) had been published at that time.
• Some vulnerability trackers and security vendors indicated a release or patch availability in certain distributions, while others flagged "no patched release available yet" and recommended mitigations instead.

Practical takeaway:

• Do not assume a vendor release is fully available or widely deployed until the official release note or package is published and packaged by your distribution/vendor.
• If a patch release is available for your distribution of Gogs, apply it immediately. If no patch exists yet for your deployment, enforce mitigations (see the mitigation section below).

---

Immediate mitigations and recommended actions (operational checklist)​

For organizations with any Gogs exposure, take the following prioritized steps immediately.

• Inventory
• Identify all Gogs instances (internet‑facing and internal).
• Determine running versions and whether open registration or anonymous repository creation is permitted.
• Flag all internet‑reachable instances and prioritize them.
• Short‑term containment (apply immediately)
• Disable open registration and any self‑service repository creation.
• Restrict access to Gogs to a management network, VPN, or IP allowlist.
• Block PutContents API endpoints via WAF rules or deny access at the edge for untrusted networks.
• If feasible, take public‑facing instances offline until mitigations or patches are applied.
• Detection and forensics
• Look for repositories created with random eight‑character owner/repo names or unusual creation patterns.
• Scan for newly created symlinks or suspicious file changes under repositories and system folders.
• Check logs for PutContents API activity coming from unexpected accounts, IPs, or automation.
• Search for unexpected changes to .git/config or other git‑related files.
• Capture forensic snapshots before remediation if compromise is suspected.
• Patching and long‑term remediation
• When a vendor patch/release is published, validate release authenticity and apply to production after a brief test.
• If your Gogs distribution is packaged by a third party, coordinate with the packager to verify and deploy the vendor fix.
• After patching, re‑scan and monitor for indicators of compromise; perform deeper incident response if prior exploitation is suspected.
• Third‑party and supply chain actions
• Notify vendors, partners, or managed service providers that run Gogs on your behalf and demand patch verification or evidence of mitigations.
• For CI/CD pipelines that interact with Gogs instances, review build artifacts and deployment steps for signs of tampering.

---

Risk analysis: what this means for different sectors​

For federal agencies (FCEB)​

CISA’s KEV entry creates a binding operational imperative. Agencies must meet the KEV due date for remediation or apply CISA‑approved mitigations and report actions to appropriate authorities. The operational risk is elevated because:

• KEV indicates active exploitation is ongoing.
• Gogs’ default configuration choices increase attack surface (open registration).
• The vulnerability allows direct file system manipulation that can lead to full server compromise — a high consequence for systems that host source code, CI/CD hooks, or credentials.

For private sector and SMEs​

Although not legally required to follow BOD 22‑01, private organizations should treat KEV listings as high‑priority. The combination of active exploitation and ease of triggering (with default configurations) raises the probability of compromise for exposed, under‑maintained systems.

For software supply chain and DevOps teams​

This vulnerability is emblematic of supply‑chain risk: source repositories and developer tooling are prime targets because compromise can lead to downstream code pollution, build vector manipulation, and widespread deployment of backdoors. Teams must:

• Harden version control infrastructure.
• Segregate build and production credentials from source hosting services.
• Monitor for abnormal repository activity and enforce stricter account controls.

---

Strengths of the KEV response — and remaining risks​

Notable strengths​

• Speed and clarity: Adding CVE‑2025‑8110 to KEV is a clear, authoritative signal that attackers are exploiting the flaw and that organizations should act now.
• Operational mandate for federal agencies: BOD 22‑01 establishes concrete deadlines and accountability, which helps focus scarce patching resources.
• Cross‑community visibility: Public advisories, researcher blogs, and vulnerability databases converged on the same technical root cause and exploitation pattern, enabling defenders to share indicators and mitigations rapidly.

Continued risks and gaps​

• Patch availability and release cadence: When the vendor’s code is fixed in the source tree but not yet released as a packaged version, many operators cannot safely upgrade, leaving a window of exposure.
• Default insecure configurations: Many Gogs installs use default open registration, which makes exploitation trivial and difficult to detect until after compromise.
• Detection challenges: Exploits that overwrite or mutate legitimate configuration files can be stealthy; many organizations lack file‑integrity monitoring or baseline artifacts that would make detection straightforward.
• Supply chain implications: Compromise of development‑facing servers can lead to build contamination; organizations relying on third‑party code hosted on suspect servers need to consider broader integrity checks.

---

Forensics and incident response considerations​

If a Gogs instance is suspected of being compromised:

• Preserve evidence immediately: snapshot disks, collect API server logs, and isolate the host from the network.
• Review repository history and object content for unexpected symlinks, unusual commits, or repository creation timestamps.
• Inspect system logs, cron jobs, and authorized_keys for persistence mechanisms.
• Consider rebuilding compromised hosts from known‑good images after capturing necessary evidence; do not simply apply patches and re‑expose a suspect host.
• Evaluate CI/CD pipelines that pull from the compromised host for possible code tampering or credential exfiltration.

---

Policy and governance implications​

CVE‑2025‑8110 and its rapid elevation into the KEV catalog underscore several governance priorities:

• Patch governance must be operationalized: Vulnerability triage should incorporate KEV listings as a highest priority class; playbooks should routinize KEV responses with roles, deadlines, and verification steps.
• Default configuration review: Organizations should inventory default settings across developer tools and enforce hardened profiles before exposing them to the internet.
• Third‑party oversight: Contracts and vendor questionnaires must require evidence of vulnerability remediation and secure configuration for hosted developer services.
• DevSecOps posture: Build pipelines and artifact signing must assume that source hosting can be compromised; cryptographic signing of releases and reproducible builds reduce systemic risk.

---

How to communicate this risk to executives and boards​

When briefing leadership, focus on three clear messages:

• Severity and immediacy: This is a high‑severity, active exploit that can lead to full takeover of code hosting infrastructure and potentially contaminate build and release processes.
• Business impact: Compromise of source control risks intellectual property loss, supply‑chain poisoning, regulatory exposure, and operational downtime.
• Actionable asks: Request immediate funding and staffing for remediation, temporary service containment (e.g., taking public instances offline), and third‑party validation for any hosted code services.

Provide executives with a short remediation timeline and a one‑page risk impact statement listing affected business units and suggested emergency SLAs.

---

Final assessment and recommendations​

CVE‑2025‑8110 is a textbook example of how subtle filesystem semantics (symbolic links) can negate otherwise reasonable path validation logic, producing a high‑impact exploitation vector. The KEV listing formalizes the urgency: federal agencies must act by the KEV due date, and every operator of self‑hosted Gogs should treat this CVE as an immediate, high‑priority risk.
Top recommended actions, distilled:

• Inventory all Gogs instances and determine public exposure.
• If you cannot patch immediately: disable open registration, restrict access to management networks, and block the PutContents API from untrusted sources.
• Apply vendor patches as soon as an official release is available; if a patch is not yet released, apply mitigations and monitor for indicators of compromise.
• Conduct targeted forensic checks on all internet‑facing Gogs servers for signs of repository creation and symlink misuse.
• Implement longer‑term controls: reduce default attack surface, enforce account hardening, and require cryptographic signing and reproducible builds in CI/CD.

---

Cautionary notes on reporting and numbers​

Several public reports cited large counts of compromised instances (commonly "700+"), based on internet scanning and telemetry. Those numbers are credible indicators of widespread abuse, but they are researcher estimates and may change as more data is gathered. Where reporting conflicts over whether a formal patched release exists, organizations must verify directly with vendor release channels and package maintainers before assuming remediation status.

---

CISA’s addition of CVE‑2025‑8110 to the KEV Catalog is both a wake‑up call and an operational directive: this is not a theoretical flaw, it’s an active exploitation scenario that targets the very infrastructure that software organizations rely on to build and ship code. Remediate quickly, assume compromise where you cannot prove otherwise, and treat developer tooling as a high‑value security boundary rather than a convenience service.

---

Source: CISA CISA Adds One Known Exploited Vulnerability to Catalog | CISA