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.
The Jupyter Notebook (ipynb) sanitizer endpoint at POST /-/api/sanitizeipynb allows arbitrary data: URIs without proper restrictions, potentially leading to Cross-Site Scripting (XSS). The endpoint uses bluemonday.UGCPolicy() with p.AllowURLSchemes("data") which permits all data URI schemes including data:text/html, enabling attackers to inject malicious HTML/JavaScript. Additionally, the endpoint has no authentication middleware, allowing any registered user to exploit this vulnerability. Severity High Affected Versions All versions using the vulnerable endpoint Vulnerability Details - CVE ID: (To be assigned) - Entry Point: POST /-/api/sanitizeipynb - Attack Vector: Network - Authentication Required: No (only needs a registered user account) Impact An attacker with a registered user account can: - Send malicious HTML containing data:text/html URIs to the sanitization endpoint - Receive sanitized but attacker-controlled HTML in the response - Execute arbitrary JavaScript in…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gogs has an unauthenticated information disclosure vulnerability. The GET /api/v1/orgs/:orgname/teams endpoint at internal/route/api/v1/orgteam.go:8 returns all teams for any organization without requiring authentication. The route group at internal/route/api/v1/api.go:380-385 lacks the reqToken() middleware, and the listTeams() handler performs no authentication check, exposing team IDs, names, descriptions, and permission levels to any unauthenticated caller. Affected Versions Gogs (all current versions) Vulnerability Details Root Cause: Missing reqToken() middleware on org teams route group internal/route/api/v1/api.go lines 380-385: The orgAssignment(true) middleware only loads the organization object — it performs no authentication. The listTeams() handler at orgteam.go:8 returns all teams unconditionally: Compare with other org endpoints that correctly require authentication: Attack Chain - Attacker sends GET /api/v1/orgs/target-org/teams with no authentication -…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Gogs built-in Go SSH server is vulnerable to an unauthenticated, asymmetric Denial of Service (DoS) attack. The application accepts inbound TCP connections and passes them to golang.org/x/crypto/ssh.NewServerConn inside a new goroutine without enforcing any read/write deadlines on the underlying net.Conn. An unauthenticated attacker can open multiple TCP connections to the SSH port and simply withhold the SSH protocol banner. This forces the server to spawn an unbounded number of goroutines that block indefinitely waiting for socket I/O. This leads to complete File Descriptor (FD) exhaustion, preventing legitimate users from accessing the Git SSH service, and ultimately destabilizing the entire Gogs process (e.g., causing internal log rotation failures). Vulnerability Details In internal/ssh/ssh.go, the listen function contains an accept loop that spawns a goroutine for every incoming connection: The golang.org/x/crypto/ssh package is transport-agnostic and explicitly relies on…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Organization names containing path traversal sequences (../) are accepted by Gogs, and repositories under them are written to paths following these path traversals. This allows storing/retrieving data for repositories at arbitrary locations on the filesystem. By creating nested structure of Git repositories, one can overwrite the other's hooks configuration to result in Remote Code Execution (RCE). Details During organization creation, internal/database/org.go calls os.MkdirAll(repox.UserPath(org.Name)) without sanitizing org.Name. https://github.com/gogs/gogs/blob/d7571322a04a29476d4241406ed50bf7eef0a5b7/internal/database/org.go#L165 Repository creation uses this name to decide where to write the Git bare repository's (org/name.git). By setting the org name to ../../../../tmp/test, and creating a repository under that organization, it gets written under /tmp/test on the server.…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Git LFS storage is content-addressed by OID alone (<LFS-root/<oid[0]/<oid[1]/<oid) but per-repo authorization lives in the lfsobject table keyed (repoid, oid). serveUpload skips re-uploading when the OID file already exists on disk and inserts a new (repoid, oid) row pointing at it without verifying the request body hashes to the OID being claimed. Any user with write access to one repo can bind their repo to an OID owned by a private repo and download the original bytes via their own download endpoint. Details Dedupe shortcut at internal/lfsx/storage.go:79-82: Hash verification at internal/lfsx/storage.go:106-108 only runs in the new-file branch — the dedupe path returns earlier. serveUpload (internal/route/lfs/basic.go:78-114) trusts that success and inserts the per-repo binding: CreateLFSObject is an unconditional INSERT on (repoid, oid) with no check that the OID is referenced by the requesting repo's git history. serveDownload at internal/route/lfs/basic.go:42-72 only…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
(Repository).UploadRepoFiles checks for symlinks only on the leaf of the upload target (osx.IsSymlink(targetPath)). The siblings UpdateRepoFile, DeleteRepoFile, and GetDiffPreview use hasSymlinkInPath, which lstats every component — UploadRepoFiles is the lone outlier. An attacker with repo-write access plus a multipart upload whose filename contains a literal backslash (preserved by filepath.Base on Linux, then converted to / by pathx.Clean) redirects the write through a previously-committed directory symlink. iox.CopyFile opens the destination with os.Create (no ONOFOLLOW), so the kernel follows the parent symlink and writes attacker bytes anywhere the gogs UID can write — ~git/.ssh/authorizedkeys → SSH foothold, or <repo.git/hooks/post-receive → next-push RCE. Windows builds are unaffected: filepath.Base treats \ as a separator (strips the multi-segment trick) and git defaults core.symlinks=false at checkout (committed mode-120000 entries become text files, not real…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Git smart HTTP authorizes POST …/git-receive-pack using the client-supplied service query string (so ?service=git-upload-pack is evaluated as read access) while routing still runs git receive-pack, allowing push where only read should be allowed. Details Gogs' Git Smart HTTP handler for repository RPCs relies on a client-supplied query parameter to decide which authorization policy to apply. The Git protocol exposes two primary RPCs over HTTP: upload-pack for fetch (read) and receive-pack for push (write). In the affected implementation, the code derives the access mode from the service query parameter (for example, service=git-upload-pack) instead of the actual RPC path being executed. As a result, a request sent to the receive-pack endpoint can be incorrectly treated as a read operation if the query parameter claims it is an upload-pack. This behavior enables a request to POST to the write endpoint (/repo.git/git-receive-pack) while including a query string that indicates a…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Password-reset tokens are generated using conf.Auth.ActivateCodeLives (the account-activation lifetime), not conf.Auth.ResetPasswordCodeLives. The token lifetime is baked into the token itself at generation time and is re-extracted from the token at verification time, making RESETPASSWORDCODELIVES irrelevant to actual enforcement. When an administrator configures a shorter reset window (e.g., 10 minutes) for compliance or security reasons, reset tokens remain exploitable for the full activation lifetime instead, while the reset email falsely advertises the shorter expiry. Severity Medium (CVSS 3.1: 6.8) CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N - Attack Vector: Network — the reset endpoint is reachable over HTTP/S. - Attack Complexity: High — successful exploitation requires (1) the instance to be configured with RESETPASSWORDCODELIVES < ACTIVATECODELIVES, AND (2) the attacker to have intercepted the victim's reset token (e.g., from a compromised or shared email inbox). -…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Three API endpoints — PATCH /api/v1/repos/:owner/:repo/issue-tracker, PATCH /api/v1/repos/:owner/:repo/wiki, and POST /api/v1/repos/:owner/:repo/mirror-sync — are gated by reqRepoWriter() rather than reqRepoAdmin(). The equivalent operations in the web UI sit behind reqRepoAdmin, which requires AccessMode = AccessModeAdmin. A write-level collaborator (who has AccessMode == AccessModeWrite < AccessModeAdmin) can therefore call these API endpoints directly to disable the native issue tracker or wiki, inject attacker-controlled external tracker/wiki URLs that redirect all repository visitors, or trigger mirror sync — none of which they are authorized to do. Severity High (CVSS 3.1: 7.1) CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L - Attack Vector: Network — the API endpoints are reachable over HTTP/S. - Attack Complexity: Low — a single API call is sufficient; no chaining or race condition required. - Privileges Required: Low — only write-level collaborator access to the…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for GHSA-vgjm-2cpf-4g7c (DOM-based XSS via milestone selection) was only applied to templates/repo/issue/viewcontent.tmpl but not to templates/repo/issue/newform.tmpl. An attacker can store an HTML/JavaScript payload in a milestone name, and when any user opens the New Issue page and interacts with the milestone dropdown, the payload executes in their browser via Semantic UI's preserveHTML behavior. Details GHSA-vgjm-2cpf-4g7c was patched by adding | Sanitize (bluemonday HTML tag stripping) to milestone name rendering in viewcontent.tmpl. However, the same milestone dropdown exists in newform.tmpl and was not patched. In newform.tmpl, milestone names are rendered with Go's default auto-escaping ({{.Name}}), which converts < to < etc. This prevents direct HTML injection. However, when the browser renders the DOM, the text content of the element contains the decoded original payload (e.g., <img src=x onerror=alert(1)). Semantic UI 2.4.2's dropdown component has…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gogs: RCE via git rebase --exec Argument Injection in PR Merge Summary Gogs allows authenticated users to achieve Remote Code Execution (RCE) on the server by creating a pull request with a specially crafted branch name that injects the --exec flag into the git rebase command during the "Rebase before merging" merge operation. Severity Critical - CVSS 3.1 Base Score: 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) Affected Versions - Gogs 0.14.2 (latest supported release) - Gogs 0.15.0+dev (commit b53d3162, main branch as of 2026-03-16) - All prior versions that support the "Rebase before merging" merge style Impact This is a privilege escalation from authenticated user to server-level code execution. The attacker uses their own repository as the delivery mechanism - the target is not the repository but the Gogs server itself. On any multi-tenant Gogs instance (company, university, open source hosting), this gives one authenticated user full control of the underlying server: - Server…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Migration URL validation bypass via HTTP redirect to blocked internal endpoints Summary A Server-Side Request Forgery (SSRF) vulnerability exists in the repository migration functionality. The application validates only the initially submitted URL hostname, but git clone --mirror follows HTTP redirects. An authenticated user can submit a public URL that redirects to a blocked internal endpoint (e.g., 127.0.0.1), importing the internal repository's contents into an attacker-controlled repository. Vulnerability Details The vulnerability is located in internal/form/repo.go. ParseRemoteAddr() validates the clone address hostname against a blocklist of local and private-network addresses. However, the actual migration is performed by git clone --mirror in internal/database/repo.go, which follows HTTP redirects without revalidation: 1. Attacker submits http://attacker.example/redirect.git — passes validation (public hostname). 2. Attacker's server responds with 302 redirect to…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A repository admin collaborator can escalate their privileges to owner-level access by exploiting an off-by-one error in the ChangeCollaborationAccessMode function. Vulnerable Code In internal/database/repocollaboration.go, line 129: AccessModeOwner has value 4. The check mode AccessModeOwner evaluates to 4 4 = false, allowing AccessModeOwner to pass through. The correct check should be mode = AccessModeOwner. The web route at internal/route/repo/setting.go:413-416 takes the mode as a raw integer from query parameters: This allows an admin collaborator to POST mode=4 and escalate to owner. Impact A repository admin collaborator (AccessModeAdmin = 3) can escalate to owner-level access (AccessModeOwner = 4), gaining the ability to: - Delete the repository - Transfer repository ownership to another user - Erase wiki data - Perform all other owner-only operations The access table is also updated (line 181), so the escalated permissions persist across sessions. Contrast The API…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An open redirect vulnerability exists in Gogs where attacker-controlled redirectto parameters can bypass validation, allowing redirection to arbitrary external sites. Details All redirects in Gogs that are validated via the IsSameSite function are vulnerable: The function only inspects the first two characters of the URL string. This check fails to account for directory traversal sequences followed by backslashes. For example: The IsSameSite function checks the input supplied to the redirectto query parameter value /a/../\example.com and considers it valid. Because web browsers normalize backslashes \ to forward slashes /, the normalized URL becomes //example.com. The normalized URL becomes: Resulting in a cross-origin redirect. This affects all endpoints using the redirectto query parameter, including login and other post-action flows. PoC 1. An attacker can provide a user with a link to login to Gogs with a redirectto query parameter that redirects a user to a site the…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Gogs Mirror Settings functionality provide an alternative way from the well protected New Migration functionality for any authenticated users to import local repositories. This issue stems from a lack of validation of SaveAddress function. Details Here is the function implementation of the secure New Migration functionality. <img width="1200" height="755" alt="image" src="https://github.com/user-attachments/assets/a6c2f307-715e-4451-bbc1-7bd934d56f96" / Here is the function implementation of the Mirror Settings without any validation. <img width="1200" height="477" alt="image" src="https://github.com/user-attachments/assets/a11c41b8-1d08-499c-bce6-ab40844211d7" / PoC The New Migration feature correctly blocked my attempt to import a local repository. <img width="1200" height="1008" alt="image" src="https://github.com/user-attachments/assets/dfc5aa3f-1cc4-427d-b7fe-274363c83c4e" / But if I create a normal migration with a valid repository. <img width="1200" height="1006"…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Gogs 0.14.1, organization team member management can be performed via GET requests without CSRF protection. If a victim who is an organization owner is logged in and is tricked into visiting a crafted link, an attacker-controlled user can be added to the Owners team. As a result, the attacker gains organization owner–equivalent privileges. --- Description When a victim is logged in as an organization owner, team member management endpoints are exposed via routes reachable by GET requests, allowing state-changing operations without a CSRF token. Team action route allows GET internal/cmd/web.go:390 CSRF validation is applied only to POST requests Because the global CSRF check is limited to POST requests, state-changing operations reached via GET bypass CSRF protection entirely. internal/context/auth.go:56-61 TeamsAction performs state changes regardless of HTTP method TeamsAction does not branch on the HTTP method. Instead, it performs state-changing operations (such as…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Gogs 0.14.1, GET /attachments/:uuid returns the raw attachment file without verifying whether the requester has view permission for the associated Issue/Comment/Release or the repository. In a test environment with REQUIRESIGNINVIEW = false, we confirmed that an unauthenticated user can download attachments belonging to a private repository. Description /attachments/:uuid retrieves an attachment record solely by the UUID provided in the URL and returns the corresponding local file without performing any authorization checks against the attachment’s parent object (Issue/Comment/Release) or the repository it belongs to. As a result, even attachments under private repositories can be downloaded by an unauthenticated user (or a user without proper permissions) as long as the UUID is known. Relevant code (internal/cmd/web.go:306): The UUID lookup itself also performs no validation tied to repository visibility or user permissions. Authorization is not enforced at this layer.…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Although .ipynb previews are sanitized on the server side via /-/api/sanitizeipynb, the inserted content is re-rendered on the client side without sanitization using marked() on elements with the .nb-markdown-cell class. During this process, links containing schemes such as javascript: can be regenerated. As a result, when a victim views an attacker-crafted .ipynb file and clicks the link, arbitrary JavaScript is executed in the Gogs origin, leading to a click-based Stored XSS. Details After the rendered output of a .ipynb file is sanitized via /-/api/sanitizeipynb and inserted into the DOM, only the Markdown cell portions are re-rendered using marked() and overwritten in the DOM. During this process, links with the javascript: scheme can be regenerated. templates/repo/viewfile.tmpl:42–71 While regular HTML pages (including .ipynb preview pages) are served without a Content Security Policy (CSP), CSP headers are applied only to attachment delivery routes.…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Special template of issue index pattern may cause panic. Details in internal/markup/markup.go Issue index pattern is rendered to link with com.Expand. However, com.Expand is not safe. when { is found but } not found, i comes to 1, template[:-1] will be called, and then panicked finally, all pages than contains issue index are unavailable. PoC 1. set issue index pattern as follow 2. add a commit which point to an issue in its msg using #1 above Impact DoS that cause part of pages of the specify repo unavailable.
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for CVE-2022-1285 prevents adding webooks or running webhooks with URLs with a hostname that resolves in localCIDRs. However, webhooks still follow redirects allowing to access hostname inside localCIDRs. This was already communicated in the initial report but it looks like there was a bit of a miscommunication. Details By creating a webook pointing to any URL that will return the following: It is possible to access 169.254.169.254 PoC 1. Run netcat on any server 2. Use this server as the webhook URL 3. Once you get the request from the webhook (for example by testing it), copy the response above Results from running this on try.gogs: Impact Server Side Request Forgery Fix The "simplest way" to fix it is most likely to leverage Client.CheckRedirect https://pkg.go.dev/net/http#hdr-ClientsandTransports to check if the redirect is pointing to a blocked hostname
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When ENABLEREVERSEPROXYAUTHENTICATION is enabled, Gogs accepts the configured authentication header (default: X-WEBAUTH-USER) directly from client requests without validating that the request originated from a trusted reverse proxy. Any remote attacker who can reach the Gogs service can forge this header to impersonate any user or trigger automatic account creation, completely bypassing authentication. Root Cause The vulnerability exists because Gogs reads the authentication header directly from the incoming HTTP request without any verification that the header was set by a trusted reverse proxy. Vulnerable Code Flow In internal/context/auth.go lines 206-234: The code has zero validation that: 1. The request came through a reverse proxy 2. The header was set by the proxy (not the client) 3. Gogs is actually behind a reverse proxy 4. The direct access to Gogs is restricted The vulnerability occurs when: - Gogs is publicly accessible (e.g., 0.0.0.0:3000) -…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malicious user with rights to create a new file on a repository or wiki page can trigger a denial of service condition in which the pages containing the listing of files will return HTTP error 500 and render the web interface unusable for the repository or wiki. Details The issue is present in file internal/route/repo/wiki.go and internal/route/repo/view.go where the pages try to recover commit information. If errors are returned while recovering commit information, the page will return a 500 error and stop rendering, resulting in a denial of service. In view.go the issue occurs at line 56 while a slightly different issue occurs in wiki.go at line 174 where commits[0] is dereferenced without checking if it contains value. It is possible to trigger issues in assigning the correct value to variable commits by using a specific string as part of the page title. The issue is linked to the fact that file names can contain special characters such as , ?, [, ], etc. that will be…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gogs renders Jupyter notebook files (.ipynb) using jsvine/notebookjs, but the version is outdated, missing patches for known XSS vulnerabilities. Details Gogs uses version 0.4.2 of notebookjs to render Jupyter notebook files: https://github.com/gogs/gogs/blob/7297aee50d4c115836c7de8a3a233daaef87b911/templates/base/head.tmpl#L47 The latest version of jsvine/notebookjs is 0.8.3, patching many XSS vulnerabilities in its releases. The proof of concept below shows an example working payload that renders HTML through Markdown. PoC 1. Create a new repository 2. Create a file inside the repository named xss.ipynb and give it the following content: <img width="1054" height="208" alt="image" src="https://github.com/user-attachments/assets/49b7f33c-c4df-4537-99e9-b1ea74f2c6de" / 3. Save the file and view the file in Gogs. Notice that the XSS popup triggers: <img width="1317" height="407" alt="image" src="https://github.com/user-attachments/assets/3b18d870-7194-41b0-92db-687e952abc07" /…
Recommended action: Upgrade to 0.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability type: Path Traversal Impact: DoS Exploitation prerequisite: authorized user Description: As an authorized user, an intruder can dictate the value which is passed to the git diff command which, together with bypassing the filtering of the passed value, allows the user to bypass the target directory and write the result of the comparison to any arbitrary path. Researcher: Artyom Kulakov (Positive Technologies) Mitigation: 1. https://github.com/gogs/gogs/blob/b7372b1f32cd0bb40984debfb049e3fc04efaee4/internal/route/repo/editor.go#L307 — on this line, instead of the treePath variable, which comes directly from the user unchanged, we should first filter and then pass the entry variable. 2. To filter the treePath variable, it is better to use the preexisting pathutil.Clean function instead of path.Clean from the standard Go library. Exploitation A Positive Technologies researcher discovered that the user has the ability to preview their changes when editing a file in the…
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.
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. Affected Component - internal/database/release.go process.ExecDir(..., "git", "tag", "-d", rel.TagName) Details rel.TagName is used as a CLI argument to git tag -d without -- or --end-of-options. If the tag name begins with -, Git parses it as a flag. The prior mitigation is incomplete. There is path sanitization in place during creation: - internal/database/release.go r.TagName = strings.TrimLeft(r.TagName, "-") But it only covers one creation path and does not reliably protect tag deletions, such as tags added through git push or ref updates. Exploit Conditions 1. An attacker can add a tag name that starts with a dash into the repository. 2. A user with permission to delete releases triggers it through the web UI or API. Recommended Fix 1. Add end-of-options…
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.