A Stored Cross-site Scripting (XSS) vulnerability exists in the comment and issue description functionality. The application's HTML sanitizer explicitly allows data: URI schemes, enabling authenticated users to inject arbitrary JavaScript execution via malicious links.
Stored XSS is still possible through unsafe template rendering that mixes user input with safe() plus permissive sanitizer handling of data URLs.
There is a security issue in Gogs where deleting a release can fail if a user-controlled tag name is passed to Git without the right separator, allowing Git option injection and therefore interfering with the process.
It was confirmed in a test environment that an attacker can store an HTML/JavaScript payload in a repository’s Milestone name, and when another user selects that Milestone on the New Issue page (/issues/new), a DOM-Based XSS is triggered.
Overwritable LFS object across different repos leads to supply-chain attack, all LFS objects are vulnerable to be maliciously overwritten by malicious attackers.
The Gogs API still accepts tokens in URL parameters such as token and access_token, which can leak through logs, browser history, and referrers.
Gogs exposes unauthenticated file upload endpoints by default. When the global RequireSigninView setting is disabled (default), any remote user can upload arbitrary files to the server via /releases/attachments and /issues/attachments. This enables the instance to be abused as a public file host, potentially leading to disk exhaustion, content hosting, or delivery of malware. CSRF tokens do not mitigate this attack due to same-origin cookie issuance.
A broken access control vulnerability in Gogs allows authenticated users with write access to any repository to modify labels belonging to other repositories. The UpdateLabel function in the Web UI (internal/route/repo/issue.go) fails to verify that the label being modified belongs to the repository specified in the URL path, enabling cross-repository label tampering attacks.
An access control bypass vulnerability in Gogs web interface allows any repository collaborator with Write permissions to delete protected branches (including the default branch) by sending a direct POST request, completely bypassing the branch protection mechanism. This vulnerability enables privilege escalation from Write to Admin level, allowing low-privilege users to perform dangerous operations that should be restricted to administrators only. Although Git Hook layer correctly prevents protected branch deletion via …
The POST /:owner/:repo/issues/comments/:id/delete endpoint does not verify that the comment belongs to the repository specified in the URL. This allows a repository administrator to delete comments from any other repository by supplying arbitrary comment IDs, bypassing authorization controls.
Due to the insufficient patch for the https://github.com/gogs/gogs/security/advisories/GHSA-wj44-9vcg-wjq7, it's still possible to update files in the .git directory and achieve remote command execution.
Stored XSS via mermaid diagrams due to usage of vulnerable renderer library
A Path Traversal vulnerability exists in the updateWikiPage function of Gogs. The vulnerability allows an authenticated user with write access to a repository's wiki to delete arbitrary files on the server by manipulating the old_title parameter in the wiki editing form.
Contact OpenAI Security Research at outbounddisclosures@openai.com to engage on this report. See PDF report for easier reading.
The DELETE /api/v1/repos/:owner/:repo endpoint lacks necessary permission validation middleware. Consequently, any user with read access (including read-only collaborators) can delete the entire repository. This vulnerability stems from the API route configuration only utilizing the repoAssignment() middleware (which only verifies read access) without enforcing reqRepoOwner() or reqRepoAdmin().
Vulnerability Description In the endpoint: /username/reponame/settings/hooks/git/:name the :name parameter: Is URL-decoded by macaron routing, allowing decoded slashes (/) Is then passed directly to: git.Repository.Hook("custom_hooks", name) which internally resolves the path as: filepath.Join(repoPath, "custom_hooks", name) Because no path sanitization is applied, supplying ../ sequences allows access to arbitrary paths outside the repository. As a Result: GET: Arbitrary file contents are displayed in the hook edit page textarea (Local File Inclusion). POST: …
An authenticated user can cause a DOS attack. If one of the repo files is deleted before synchronization, it will cause the application to crash.
Vulnerability Description The endpoint PUT /repos/:owner/:repo/contents/* does not require write permissions and allows access with read permission only via repoAssignment(). After passing the permission check, PutContents() invokes UpdateRepoFile(), which results in: Commit creation Execution of git push As a result, a token with read-only permission can be used to modify repository contents. Attack Prerequisites Possession of a valid access token Read permission on the target repository (public repository or collaborator …