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.
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.
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 REQUIRE_SIGNIN_VIEW = false, we confirmed that an unauthenticated user can download attachments belonging to a private repository.
Although .ipynb previews are sanitized on the server side via /-/api/sanitize_ipynb, 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 …
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.
Special template of issue index pattern may cause panic.
When ENABLE_REVERSE_PROXY_AUTHENTICATION 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.
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.
Gogs renders Jupyter notebook files (.ipynb) using jsvine/notebookjs, but the version is outdated, missing patches for known XSS vulnerabilities.
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: https://github.com/gogs/gogs/blob/b7372b1f32cd0bb40984debfb049e3fc04efaee4/internal/route/repo/editor.go#L307 — on this line, instead …
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 …
Improper Symbolic link handling in the PutContents API in Gogs allows Local Execution of Code.
A stored XSS is present in Gogs which allows client-side Javascript code execution.
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.
The malicious user is able to commit and edit a crafted symlink file to a repository to gain SSH access to the server.
The malicious user is able to write a file to an arbitrary path on the server to gain SSH access to the server.
When the built-in SSH server is enabled ([server] START_SSH_SERVER = 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 RUN_USER in the configuration. It allows attackers to access and alter any users' code hosted on the same instance.
Unprivileged user accounts can execute arbitrary commands on the Gogs instance with the privileges of the account specified by RUN_USER in the configuration. It allows attackers to access and alter any users' code hosted on the same instance.
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] SECRET_KEY. Attackers could also exfiltrate TLS certificates, other users' repositories, and the Gogs database when the SQLite driver is enabled.
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.
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.
OS Command Injection in GitHub repository gogs/gogs prior to 0.12.11.
In Gogs, versions v0.6.5 through v0.12.10 are vulnerable to Stored Cross-Site Scripting (XSS) that leads to an account takeover.
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.
Impact The malicious user is able to delete and upload arbitrary file(s). All installations on Windows with repository upload enabled (default) are affected. Patches Path cleaning has accommodated for Windows. Users should upgrade to 0.12.9 or the latest 0.13.0+dev. Workarounds N/A References https://huntr.dev/bounties/2e8cdc57-a9cf-46ae-9088-87f09e6c90ab/ For more information If you have any questions or comments about this advisory, please post on #7001.
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. All installations with repository upload enabled (default) are affected. Patches File deletions are prohibited to repository's .git directory. Users should upgrade to 0.12.9 or the latest 0.13.0+dev. Workarounds N/A References https://huntr.dev/bounties/776e8f29-ff5e-4501-bb9f-0bd335007930/ For more information If you have any questions or comments …
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in gogs.io/gogs.
Server-Side Request Forgery (SSRF) in GitHub repository gogs/gogs prior to 0.12.8.
Impact The malicious user is able to upload a crafted config file into repository's .git directory with to gain SSH access to the server. All Windows installations with repository upload enabled (default) are affected. Patches Repository file uploads are prohibited to its .git directory. Users should upgrade to 0.12.8 or the latest 0.13.0+dev. Workarounds Disable repository files upload. References https://www.huntr.dev/bounties/9cd4e7b7-0979-4e5e-9a1c-388b58dea76b/ For more information If you have any questions or comments …
Missing input validation in internal/db/repo_editor.go in Gogs before 0.12.8 allows an attacker to execute code remotely. An unprivileged attacker (registered user) can overwrite the Git configuration in his repository. This leads to Remote Command Execution, because that configuration can contain an option such as sshCommand, which is executed when a master branch is a remote branch (using an ssh:// URI). The remote branch can also be configured by editing the …
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in gogs.io/gogs.
Stored xss bug in GitHub repository gogs/gogs prior to 0.12.7. As the repo is public, any user can view the report and when open the attachment then xss is executed. This bug allow executed any javascript code in victim account .
An SSRF vulnerability in webhooks in Gitea through 1.5.0-rc2 and Gogs through 0.11.53 allows remote attackers to access intranet services.
In Gogs 0.11.53, an attacker can use a crafted .eml file to trigger MIME type sniffing, which leads to XSS, as demonstrated by Internet Explorer, because an "X-Content-Type-Options: nosniff" header is not sent.
In pkg/tool/path.go in Gogs before 0.11.82.1218, a directory traversal in the file-upload functionality can allow an attacker to create a file under data/sessions on the server, a similar issue to CVE-2018-18925.
Remote Command Execution in uploading repository file in GitHub repository gogs/gogs prior to 0.12.6.
Impact The malicious user is able to discover services in the internal network through repository migration functionality. All installations accepting public traffic are affected. Patches Internal network CIDRs are prohibited to be used as repository migration targets. Users should upgrade to 0.12.5 or the latest 0.13.0+dev. Workarounds Run Gogs in its own private network. References https://www.huntr.dev/bounties/327797d7-ae41-498f-9bff-cc0bf98cf531/ For more information If you have any questions or comments about this advisory, please …
Impact Expired PAM accounts and accounts with expired passwords are continued to be seen as valid. Installations use PAM as authentication sources are affected. Patches Expired PAM accounts and accounts with expired passwords are no longer being seen as valid. Users should upgrade to 0.12.5 or the latest 0.13.0+dev. Workarounds In addition to marking PAM accounts as expired, also disable/lock them. Running usermod -L <username> will add an exclamation mark …
Server-Side Request Forgery (SSRF) in GitHub repository gogs/gogs prior to 0.12.5.
Improper Authorization in GitHub repository gogs/gogs prior to 0.12.5.
Open redirect vulnerability in Gogs before 0.12 allows remote attackers to redirect users to arbitrary websites and conduct phishing attacks via an initial /\ substring in the user/login redirect_to parameter, related to the function isValidRedirect in routes/user/auth.go.
SQL injection vulnerability in the GetIssues function in models/issue.go in Gogs (aka Go Git Service) 0.3.1-9 through 0.5.6.x before 0.5.6.1025 Beta allows remote attackers to execute arbitrary SQL commands via the label parameter to user/repos/issues.
Multiple SQL injection vulnerabilities in Gogs (aka Go Git Service) 0.3.1-9 through 0.5.x before 0.5.6.1105 Beta allow remote attackers to execute arbitrary SQL commands via the q parameter to (1) api/v1/repos/search, which is not properly handled in models/repo.go, or (2) api/v1/users/search, which is not properly handled in models/user.go.
Cross-site scripting (XSS) vulnerability in models/issue.go in Gogs (aka Go Git Service) 0.3.1-9 through 0.5.x before 0.5.8 allows remote attackers to inject arbitrary web script or HTML via the text parameter to api/v1/markdown.
routes/api/v1/api.go in Gogs 0.11.86 lacks permission checks for routes: deploy keys, collaborators, and hooks.
In Gogs 0.11.91, MakeEmailPrimary in models/user_mail.go lacks a "not the owner of the email" check.