Yes. CISA added CVE-2025-8110 to its Known Exploited Vulnerabilities catalogue on 12 January 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Gogs contains a path traversal vulnerability affecting improper Symbolic link handling in the PutContents API that could allow for code execution.
What “actively exploited” means for this CVE
For a practitioner, the key signal is not the product name alone but the combination of confirmed exploitation and a vulnerability that sits on a code path reachable by normal use. CISA’s KEV listing means you should treat this as an exposure that may already have been used against real systems, not as a theoretical issue waiting for proof of concept.
Because the flaw is in Gogs and involves path traversal in the PutContents API, exposure depends on whether the application is internet-facing, reachable by untrusted users, or embedded in a workflow that allows file or repository content operations. A quick inventory of deployed Gogs instances and their access paths is the first decision point.
For broader triage on exploited vulnerabilities, use Zero-Day and Exploited Vulnerabilities Guide to separate routine patching from emergency response, and check the CISA Known Exploited Vulnerabilities Catalog for the authoritative exploitation and remediation context.
How to confirm exposure and reduce the blast radius
Start by confirming whether any Gogs deployment is present, which version branch it is on, and whether the PutContents API is exposed through the network path used by users, automation, or reverse proxies. If you cannot prove the instance is absent, assume it is in scope until inventory catches up.
When a flaw can traverse paths in a repository service, the practical concern is not only arbitrary file access but also whether attacker-controlled content can influence code execution, credentials on disk, or application state. That means you should pair exposure review with a targeted search for suspicious file writes, unexpected repository changes, and abnormal API usage around the affected operation.
Use the NIST National Vulnerability Database and the CVE Program to align internal records with the canonical vulnerability record, then map any live Gogs instance to the specific advisory guidance instead of relying on asset labels or assumptions.
What to do if patching has to wait
If remediation cannot be completed immediately, treat the service as high-risk and reduce the attack surface rather than hoping the issue is rare. Restrict who can reach Gogs, narrow access to the API layer, and remove any unnecessary exposure from the internet, shared networks, or automation runners that can reach repository services.
Where the service is needed for production work, put compensating controls around the most sensitive operations: limit PutContents access, segment the host, and review permissions on the local filesystem so that a traversal attempt cannot easily reach secrets or executable paths. In parallel, preserve logs and evidence so you can validate whether the weakness has already been exercised.
For a control-oriented view of emergency vulnerability handling, the Vulnerability Management Guide is the right internal reference for prioritisation, exceptions and verification, while the FIRST EPSS can help you decide whether to accelerate this item ahead of non-exploited findings.
Risk and Threat Considerations
Confirmed exploitation changes the risk posture immediately: the question is no longer whether the flaw could be abused, but whether your deployment has already been targeted or silently altered. Because this issue can touch repository content and server-side file handling, the likely failure mode is unauthorised path access that can cascade into code execution or follow-on compromise.
Failure mechanism: An attacker abuses path traversal in the API’s symbolic link handling to reach files or paths outside the intended repository boundary, potentially affecting execution or persistence paths.
Impact: If that access is successful, the attacker may be able to read, overwrite, or leverage server-side content in ways that expose secrets, alter code, or support broader takeover.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The subject is an exploited vulnerability requiring rapid prioritisation and verification. |
| CIS-8 — Audit Log Management | Checking for exploitation depends on retaining and reviewing logs and telemetry. | |
| Recommendation — Prioritise, track and validate remediation for the vulnerable Gogs deployment. Preserve and review logs to detect use of the affected API path. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The answer centers on confirming exposure and responding to an actively exploited vulnerability. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-exploitation checking requires analysis of logs and security events. | |
| SI-2 — Flaw Remediation | CVE exploitation makes rapid flaw remediation the core control action. | |
| Recommendation — Scan for Gogs exposure and track remediation until the finding is closed. Review logs for suspicious access to the vulnerable path and related file activity. Apply the vendor fix or mitigation as soon as operationally possible. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Path traversal in API/file handling is an application security weakness addressed by secure design and verification. |
| Recommendation — Verify file-handling logic blocks traversal and symbolic-link abuse. | ||
| MITRE ATT&CK | T1006 — Direct Volume Access | The issue involves abusing filesystem path handling to reach unauthorized locations. |
| Recommendation — Hunt for filesystem access patterns that indicate traversal abuse and follow-on tampering. | ||
Practitioner Guidance
What to verify: Confirm whether any Gogs instance is reachable from untrusted networks, whether the affected API path is enabled, and whether recent logs show unusual repository writes or path-related requests.
Decision rule: If you cannot patch immediately, treat the instance as potentially exposed and prioritise containment and compromise assessment before normal backlog work.
Evidence to retain: Keep access logs, application logs, file integrity data and host telemetry long enough to determine whether the vulnerable path was used before or after you narrowed access.
Practitioner takeaway: For an actively exploited flaw, the operational question is not just “can we patch it?”, but “can we prove no one already used it and no sensitive paths were reached?”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org