CVE-2026-26194: 
Gogs Analisi e mitigazione delle vulnerabilità

CVE-2026-26194 is a git argument injection vulnerability in Gogs, an open-source self-hosted Git service, affecting all versions up to and including 0.14.1. The flaw exists in the release deletion workflow, where a user-controlled tag name is passed to git tag -d without the -- end-of-options separator, allowing git options to be injected. It was disclosed on March 5, 2026, and patched in version 0.14.2. The vulnerability carries a CVSS v3.1 score of 7.3 (High) and a CVSS v4.0 score of 8.8 (High) (Github Advisory, Gogs Advisory).

The root cause is CWE-88 (Improper Neutralization of Argument Delimiters in a Command — Argument Injection). In internal/database/release.go, the function DeleteReleaseOfRepoByID invokes process.ExecDir(..., "git", "tag", "-d", rel.TagName) without using -- or --end-of-options to terminate option parsing, meaning a tag name beginning with - is interpreted by Git as a flag rather than a positional argument. While a partial mitigation (strings.TrimLeft(r.TagName, "-")) exists during release creation, it only covers one code path and does not protect against tags pushed directly via git push or ref updates. The fix replaces the raw process.ExecDir call with the safe git-module library's Repository.DeleteTag method, which properly handles option termination (Gogs Advisory, Fix Commit).

Successful exploitation can cause tag and release deletion to fail or behave unexpectedly, resulting in operational denial of service within release cleanup workflows and potential release metadata inconsistency. An authenticated attacker with repository access can inject arbitrary git options, corrupting repository state or disrupting git operations. Confidentiality impact is assessed as low, while integrity and availability impacts are rated high (Github Advisory, Gogs Advisory).

1. Gain repository access: Obtain push access to a Gogs repository running version 0.14.1 or earlier, either as a legitimate contributor or through compromised credentials.
2. Push a malicious tag: Use git push or a ref update to create a tag whose name begins with a dash (e.g., -v or --delete), bypassing the creation-time sanitization that only strips leading dashes from tags created via the web UI or API.
3. Trigger release deletion: Wait for or social-engineer a user with release management permissions to delete the release associated with the malicious tag via the Gogs web UI or API endpoint (e.g., DELETE /api/v1/repos/{owner}/{repo}/releases/{id}).
4. Inject git options: When DeleteReleaseOfRepoByID executes git tag -d <malicious-tag-name>, Git interprets the leading dash as a flag, injecting unintended options into the command and causing the deletion to fail or behave unexpectedly, potentially corrupting repository state (Gogs Advisory, Github Advisory).

• Logs: Gogs application logs showing errors from DeleteReleaseByID (git tag -d) with unexpected stderr output referencing unknown git flags or options; error messages containing git tag -d: invalid option or similar git flag-parsing errors.
• Repository State: Presence of tags with names beginning with - or -- in a repository, which would not normally be created through the standard Gogs web UI.
• Process: Unexpected git subprocess behavior or exit codes when the Gogs process invokes git tag -d with a dash-prefixed argument, observable in process audit logs.
• Network: API calls to release deletion endpoints (DELETE /api/v1/repos/.../releases/...) shortly after unusual tags appear in the repository (Gogs Advisory).

Upgrade Gogs to version 0.14.2 or later, which replaces the vulnerable process.ExecDir call with the safe git-module library's Repository.DeleteTag method that properly terminates option parsing (Gogs Release, Fix Commit). Note that version 0.14.3 is also available and recommended by the Gogs project. As a workaround prior to patching, restrict release management and repository push permissions to trusted users only, and implement server-side hooks to reject tag names beginning with -. All git commands accepting user-controlled input should be audited to ensure the -- end-of-options separator is consistently used (Github Advisory).

Rapid7 published a technical blog post on the vulnerability, describing it as authenticated RCE via argument injection and noting it was initially unfixed (Rapid7 Blog). BleepingComputer covered the issue twice — first reporting on the unpatched zero-day and later on Gogs patching the critical flaw, noting over 2,300 exposed servers (BleepingComputer). A Reddit discussion in r/golang highlighted community interest in the release tag option injection issue. OpenSUSE also issued a security announcement referencing the vulnerability (OpenSUSE).