Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
71 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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. Details The vulnerability is located in internal/markup/sanitizer.go. The application uses the bluemonday HTML sanitizer but explicitly weakens the security policy by allowing the data URL scheme: While the Markdown renderer rewrites relative links (mitigating standard Markdown link attacks), Gogs supports Raw HTML input. Raw HTML anchor tags bypass the Markdown parser's link rewriting and are processed directly by the sanitizer. Since the sanitizer is configured to allow data: URIs, payloads like <a href="data:text/html..." are rendered as-is. PoC 1. Create a file named exploit.md in a repository. 2. Add the following content (Raw HTML): 3. Commit and push the file. 4. Navigate to the file in the Gogs web…
Recommended action: Upgrade to 0.14.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Overwritable LFS object across different repos leads to supply-chain attack, all LFS objects are vulnerable to be maliciously overwritten by malicious attackers. Details Gogs store all LFS objects in the same place, no isolation between different repositories. (repo id not concatenated to storage path) https://github.com/gogs/gogs/blob/7a2dffa95ac64f31c8322cb50d32694b05610144/internal/lfsutil/storage.go#L52-L58 Gogs does not verify uploaded LFS file content against its claimed SHA-256, meaning attackers can manipulate the uploaded file like injecting backdoor. https://github.com/gogs/gogs/blob/7a2dffa95ac64f31c8322cb50d32694b05610144/internal/lfsutil/storage.go#L79-L89 Here's the comment that trust client to retry upload allowing them to overwrite. However, this assumption does not hold in the case of a malicious client. https://github.com/gogs/gogs/blob/7a2dffa95ac64f31c8322cb50d32694b05610144/internal/route/lfs/basic.go#L111-L113 PoC 1. User (admin1) upload a LFS object…
Recommended action: Upgrade to 0.14.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Security Advisory:Unauthenticated File Upload in Gogs Vulnerability Type: Unauthenticated File Upload Date: Aug 5, 2025 Discoverer: OpenAI Security Research Summary 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. Affected Versions - Software: Gogs - Confirmed Version(s): 28f83626d4ed0aa7b89493be2ea8b79ca038331e - Likely Affected: All versions since 2020-04-05 with unauthenticated attachments endpoints - Introduced Commit: 07818d5fa Vulnerability Details The web.go router exposes the following endpoints under the ignSignIn route group: Vulnerable Code Snippet These endpoints are…
Recommended action: Upgrade to 0.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 SSH push, the web interface deletion operation does not trigger Git Hooks, resulting in complete bypass of protection mechanisms. Details Affected Component - File: internal/route/repo/branch.go - Function: DeleteBranchPost (lines 110-155) - Route Configuration: internal/cmd/web.go:589 Root Cause The DeleteBranchPost function performs the following checks when deleting a branch: 1. ✅ User authentication (reqSignIn) 2. ✅ Write permission check (reqRepoWriter)…
Recommended action: Upgrade to 0.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The vulnerability exists in the Web UI's label update endpoint POST /:username/:reponame/labels/edit. The handler function UpdateLabel uses an incorrect database query function that bypasses repository ownership validation: Vulnerable Code (internal/route/repo/issue.go:1040-1054): Root Cause: 1. The function calls database.GetLabelByID(f.ID) which internally passes repoID=0 to the ORM layer 2. According to code comments in internal/database/issuelabel.go:147-166, passing repoID=0 causes the ORM to ignore repository restrictions 3. No validation checks whether l.RepoID == c.Repo.Repository.ID…
Recommended action: Upgrade to 0.14.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
IDOR: Cross-Repository Comment Deletion via DeleteComment Summary 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. Vulnerability Details | Field | Value | |-------|-------| | Affected File | internal/route/repo/issue.go | | Affected Function | DeleteComment (lines 955-968) | | Secondary File | internal/database/comment.go | | Secondary Function | DeleteCommentByID (lines 505-520) | Root Cause The vulnerability exists due to insufficient authorization validation in the comment deletion flow: 1. Missing Repository Ownership Check in DeleteComment In internal/route/repo/issue.go, the function retrieves a comment by ID without verifying repository ownership: 2. Database Layer Performs No Authorization In internal/database/comment.go, the deletion…
Recommended action: Upgrade to 0.14.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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(). Details 0. vulnerability location: - Vulnerable Endpoint：DELETE /api/v1/repos/:owner/:repo - Routing configuration file: internal/route/api/v1/api.go (approximately line 253) - Function handling file: internal/route/api/v1/repo/repo.go (approximately lines 320-338) 1. Root Cause Analysis Code Location 1: API Route Configuration (internal/route/api/v1/api.go ~ line 253) Code Location 2: Delete Function Implementation (internal/route/api/v1/repo/repo.go ~ lines 320-338) 2. Missing Permission Check Comparison with route configurations for other sensitive operations: 3. Data Flow Path -…
Recommended action: Upgrade to 0.13.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Stored XSS via mermaid diagrams due to usage of vulnerable renderer library Details Gogs introduced support for rendering mermaid diagrams in version 0.13.0. Currently used version of the library mermaid 11.9.0 is vulnerable to at least two XSS scenarios with publicly available payloads Resources: https://github.com/mermaid-js/mermaid/security/advisories/GHSA-7rqq-prvp-x9jh https://github.com/mermaid-js/mermaid/security/advisories/GHSA-8gwm-58g9-j8pw PoC 1. Create a markdown file eg. README.md containing following malicious mermaid diagram (payload based on CVE-2025-54880) 2. The XSS should pop whenever either repository or file is viewed Demo https://github.com/user-attachments/assets/98320f62-6c1c-4254-aa61-95598c725235 Impact The attacker can potentially achieve account takeover In a worst case scenario if the victim were an instance admin this could lead to a compromise of the entire deployment Proposed remediation steps 1. Upgrade to a patched version of the third party…
Recommended action: Upgrade to 0.13.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 oldtitle parameter in the wiki editing form. Vulnerability Deatils The vulnerability is located in internal/database/wiki.go. When updating a wiki page, the application accepts an oldtitle parameter to identify the potential rename operation. This parameter is used directly in path.Join and os.Remove without proper sanitization. Code snippet from internal/database/wiki.go: If an attacker provides a path traversal sequence (e.g., ../../../../target) as oldtitle, the os.Remove function will resolve the path relative to the wiki's local directory and delete the target file. The vulnerability is limited to deleting files that end with .md (due to the appended extension), but depending on the filesystem and specific path.Join behavior, or if critical .md…
Recommended action: Upgrade to 0.13.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Description In the endpoint: the :name parameter: Is URL-decoded by macaron routing, allowing decoded slashes (/) Is then passed directly to: which internally resolves the path as: 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: Existing files can be overwritten with attacker-controlled content (Arbitrary File Write). --- Attack Prerequisites The attacker is an authenticated user The attacker has Admin or higher privileges on the target repository The attacker has the AllowGitHook permission (or is a site administrator) The target file is readable/writable by the Gogs process OS permissions --- Attack Scenario 1. An attacker (with AllowGitHook + repository Admin privileges) accesses the Git hook edit URL 2. A path containing ../ is supplied in :name, fully URL-encoded using %2f 3.…
Recommended action: Upgrade to 0.13.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 with read access) --- Attack Scenario 1. The attacker accesses the target repository with a read-only token 2. The attacker sends a PUT /contents request to update an arbitrary file 3. The server creates a commit and performs a git push on behalf of the attacker --- Potential Impact Source code tampering Injection of backdoors Compromise of release artifacts and distributed packages
Recommended action: Upgrade to 0.13.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details If GetMirrorByRepoID fails, the error log dereferencing null pointer. This happens if the repository no longer exits. https://github.com/gogs/gogs/blob/4cc83c498b6ae59356a04912d68a932165bad5e6/internal/database/mirror.go#L333-L337 if err != nil m is alwasa nil https://github.com/gogs/gogs/blob/4cc83c498b6ae59356a04912d68a932165bad5e6/internal/database/mirror.go#L269-L278 PoC Spam mirror-sync on repo and delete this repo code python spam mirror-sync Impact Denial of Service server crash.
Recommended action: Upgrade to 0.13.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Contact OpenAI Security Research at outbounddisclosures@openai.com to engage on this report. See PDF report for easier reading. Security Advisory: 2FA Bypass via Recovery Code Vulnerability Type: 2FA Authentication Bypass Affected Software: GOGS Severity: High Date: Aug 5, 2025 Discoverer: OpenAI Security Research Summary Gogs’ 2FA recovery code validation does not scope codes by user, enabling cross-account bypass. If an attacker knows a victim’s username and password, they can use Security Advisory 2FA Bypass via Recovery Code - Google Docs.pdf any unused recovery code (e.g., from their own account) to bypass the victim’s 2FA. This enables full account takeover and renders 2FA ineffective in all environments where it's enabled. Affected Versions Software: Gogs Confirmed Version(s): All versions with 2FA support Likely Affected: All versions since introduction of UseRecoveryCode logic Introduced Commit: a617d52374e937db0edacfba2a26bdd14a05538e Commit:…
Recommended action: Upgrade to 0.13.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details Function UpdateRepoFile security check under some if conditions. While UpdateRepoFile call in API router will NOT match any of them. It's still possible to update .git/config file via API router. https://github.com/gogs/gogs/blob/d940e692ec58abd45e648c054d7dfd88909034ec/internal/route/api/v1/repo/contents.go#L197-L206 PoC Update file via API router Impact RCE
Recommended action: Upgrade to 0.13.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go gogs.io/gogs < 0.13.3-0.20250608224432-110117b2e5e5
Fixed in
0.13.3-0.20250608224432-110117b2e5e5· Vendor fix available
Issue
A stored XSS is present in Gogs which allows client-side Javascript code execution. Details Gogs Version: Application version: 0.14.0+dev Local setup using: The vulnerability is caused by the usage of a vulnerable and outdated component: pdfjs-1.4.20 under public/plugins/. Read more about this vulnerability at codeanlabs - CVE-2024-4367. PoC 1. Upload the Proof of Concept file hosted at https://codeanlabs.com/wp-content/uploads/2024/05/pocgeneralizedCVE-2024-4367.pdf in a repository. 2. Click on the file to be previewed. Credits Edoardo Ottavianelli
Recommended action: Upgrade to 0.13.3-0.20250608224432-110117b2e5e5 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to the insufficient patch for the CVE-2024-39931, it's still possible to delete files under the .git directory and achieve remote command execution. Details In the patch for CVE-2024-39931, the following check is added: https://github.com/gogs/gogs/commit/77a4a945ae9a87f77e392e9066b560edb71b5de9 While the above code snippet checks if the specified path is a .git directory, there are no checks for symbolic links in the later steps. So, by creating a symbolic link that points to the .git directory, an attacker can still delete arbitrary files in the .git directory and achieve remote command execution. Impact Unprivileged user accounts can execute arbitrary commands on the Gogs instance with the privileges of the account specified by RUNUSER in the configuration. It allows attackers to access and alter any users' code hosted on the same instance.
Recommended action: Upgrade to 0.13.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When the built-in SSH server is enabled ([server] STARTSSHSERVER = true), unprivileged user accounts with at least one SSH key can execute arbitrary commands on the Gogs instance with the privileges of the user specified by RUNUSER in the configuration. It allows attackers to access and alter any users' code hosted on the same instance. Patches The env command sent to the internal SSH server has been changed to be a passthrough (https://github.com/gogs/gogs/pull/7868), i.e. the feature is effectively removed. Users should upgrade to 0.13.1 or the latest 0.14.0+dev. Workarounds Disable the use of built-in SSH server on operating systems other than Windows. References https://www.cve.org/CVERecord?id=CVE-2024-39930
Recommended action: Upgrade to 0.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Unprivileged user accounts can write to arbitrary files on the filesystem. We could demonstrate its exploitation to force a re-installation of the instance, granting administrator rights. It allows accessing and altering any user's code hosted on the same instance. Patches Unintended Git options has been ignored for diff preview (https://github.com/gogs/gogs/pull/7871). Users should upgrade to 0.13.1 or the latest 0.14.0+dev. Workarounds No viable workaround available, please only grant access to trusted users to your Gogs instance on affected versions. References https://www.cve.org/CVERecord?id=CVE-2024-39932
Recommended action: Upgrade to 0.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Unprivileged user accounts can execute arbitrary commands on the Gogs instance with the privileges of the account specified by RUNUSER in the configuration. It allows attackers to access and alter any users' code hosted on the same instance. Patches Deletion of .git files has been prohibited (https://github.com/gogs/gogs/pull/7870). Users should upgrade to 0.13.1 or the latest 0.14.0+dev. Workarounds No viable workaround available, please only grant access to trusted users to your Gogs instance on affected versions. References https://www.cve.org/CVERecord?id=CVE-2024-39931
Recommended action: Upgrade to 0.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Unprivileged user accounts with at least one SSH key can read arbitrary files on the system. For instance, they could leak the configuration files that could contain database credentials ([database] ) and [security] SECRETKEY. Attackers could also exfiltrate TLS certificates, other users' repositories, and the Gogs database when the SQLite driver is enabled. Patches Unintended Git options has been ignored for creating tags (https://github.com/gogs/gogs/pull/7872). Users should upgrade to 0.13.1 or the latest 0.14.0+dev. Workarounds No viable workaround available, please only grant access to trusted users to your Gogs instance on affected versions. References https://www.cve.org/CVERecord?id=CVE-2024-39933
Recommended action: Upgrade to 0.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The malicious user is able to write a file to an arbitrary path on the server to gain SSH access to the server. Patches Writing files outside repository Git directory has been prohibited via the repository file update API (https://github.com/gogs/gogs/pull/7859). Users should upgrade to 0.13.1 or the latest 0.14.0+dev. Workarounds No viable workaround available, please only grant access to trusted users to your Gogs instance on affected versions. References n/a Proof of Concept 1. Generate a Personal Access Tokens 2. Edit any file on the server with this 3. ssh connect to remote server For more information If you have any questions or comments about this advisory, please post on https://github.com/gogs/gogs/issues/7582.
Recommended action: Upgrade to 0.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The malicious user is able to commit and edit a crafted symlink file to a repository to gain SSH access to the server. Patches Editing symlink while changing the file name has been prohibited via the repository web editor (https://github.com/gogs/gogs/pull/7857). Users should upgrade to 0.13.1 or the latest 0.14.0+dev. Workarounds No viable workaround available, please only grant access to trusted users to your Gogs instance on affected versions. References n/a Proof of Concept 1. Create two repositories, upload something to the first repository, edit any file, and save it on the webpage. 2. In the second repository, create a symbolic link to the file you need to edit: 3. Go back to the webpage, edit the symbolic file in the second repository, with the following content, change the filename, and save (here you can notice, with filename changed the symbolic file edit limit is bypassed) 4. Go back to the first repo, edit something, and commit again, you can notice a file called…
Recommended action: Upgrade to 0.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gogs <0.13.2 is vulnerable to symbolic link path traversal that enables remote code execution via the editFilePost function of internal/route/repo/editor.go.
Recommended action: Upgrade to 0.13.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The malicious user is able to update a crafted config file into repository's .git directory in combination with crafted file deletion to gain SSH access to the server on case-insensitive file systems. All installations with repository upload enabled (default) on case-insensitive file systems (Windows, macOS, etc.) are affected. Patches Make sanitization of upload path to .git directory to be case-insensitive. Users should upgrade to 0.12.11 or the latest 0.13.0+dev. Workarounds Disable repository upload. References https://huntr.dev/bounties/18cf9256-23ab-4098-a769-85f8da130f97/ For more information If you have any questions or comments about this advisory, please post on https://github.com/gogs/gogs/issues/7030.
Recommended action: Upgrade to 0.12.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The malicious user is able to craft HTTP requests to access unauthorized Git directories. All installations with are affected. Patches Path cleaning has accommodated for Git HTTP endpoints. Users should upgrade to 0.12.9 or the latest 0.13.0+dev. Workarounds N/A References https://huntr.dev/bounties/22f9c074-cf60-4c67-b5c4-72fdf312609d/ For more information If you have any questions or comments about this advisory, please post on #7002.
Recommended action: Upgrade to 0.12.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.