Forgejo 13.0.0 → 16.0.5

Warning if your instance was already migrated to Forgejo v13.0.0 and is using a PostgreSQL database, make sure you read the releases notes to verify Forgejo Actions secrets are sound.

Forgejo v13.0.2 contains critical security fixes. Originally scheduled for 7 November, the release date of these patches was advanced because a vulnerability had been leaked publicly.

Vulnerability (Critical): prevent writing to out-of-repo symlink destinations while evaluating template repos

• CVSS 9.5 Critical
• Patch

When creating a repository based upon a template repository, Forgejo reads the contents of the template repository files, expands variables within the file content, and writes a new file for use in the newly created repository. In the event that the template repository file was a symlink to a file outside of the repository, Forgejo would follow this symlink to read, expand content, and write to the target of the symlink.

This can be exploited to cause corruption to files on the Forgejo server or container that the server process has write access to.

In specific configurations, it is possible to exploit this vulnerability to gain remote shell access to a Forgejo server. Specifically, remote shell access can be achieved if:

• The paths of sensitive files are known or guessable to an attacker,
• Git access is available through ssh,
• Forgejo provides ssh access through an authorized_keys file, which means:
• The internal ssh server is not used; [server].START_SSH_SERVER=false, which is a default.
• Forgejo manages an authorized_keys file; [server].SSH_CREATE_AUTHORIZED_KEYS_FILE=true, which is a default.
• And, an attacker can craft the necessary repositories.

The creation of repositories based upon template repositories is being fixed by sandboxing the file access to within the newly created repository, preventing any known symlink or path traversal attack.

Vulnerability (Medium): prevent .forgejo/template from being out-of-repo content

• CVSS 6.9 Medium
• Patch

When creating a repository based upon a template repository, Forgejo reads the contents of the .forgejo/template (or .gitea/template) file in the repository in order to identify which files are to be templated content. In the event that the .forgejo/template file was a symlink to a file outside of the repository, Forgejo would follow this symlink to read this file. This can be exploited to cause resource exhaustion in the Forgejo server, affecting service availability.

This issue is fixed by sandboxing the file access to within the newly created repository, preventing any known symlink or path traversal attack.

Vulnerability (Medium): return on error if an LFS token cannot be parsed

• CVSS 6.3 Medium
• Patch

If LFS is enabled on a Forgejo instance with [server].LFS_START_SERVER = true (this is not the default), it was possible for a user to download LFS files for which the OID is known in advance from a private repository to which they did not have read access. This is fixed by returning on error in case the LFS token is invalid instead of returning an inconsistent state.

Vulnerability (Low): prevent commit API from leaking user's hidden email address on valid GPG signed commits

• CVSS 2.3 Low
• Patch

When a signed GPG commit is accessed through the /repos/{owner}/{repo}/git/commits/{sha} API, the verified commit's author's primary email address is exposed in the commit.verification.signer.email field in violation of the author's desire to keep their email address private.

This has been fixed by returning the signature’s identity, rather than the account's private email address, which is consistent with what is stored in the Git repo and returned by git log.

Go 1.25 Upgrade

To provide both the highest confidence in the security of these fixes, as well as to maintain full backwards compatibility with the current Forgejo behaviour, an upgrade to go 1.25 was required in order to use their path-traversal resistant os.Root APIs which had new APIs added in go 1.25.

We recognize that this is an unfortunate change to make in security patches for major versions, and could be difficult for Forgejo packagers to adapt to.

If necessary, a go 1.24 implementation of these security fixes is also included in this release, and go.mod can be patched to use go 1.24. The go 1.24 implementation carries the same security guarantees, but introduces two known behaviour changes. These are edge cases in repository template expansion which are unlikely to affect end-users, but unfortunately could not be addressed safely in go 1.24:

• In the event that a template repo has a file path with a substitution in it, and the file mode is executable, the new file in the target repo will not be executable (and the executable file gets removed).
• In the event that a template repo has a file path with a substitution in it, and the file is a symlink to another in-repo file, the old behaviour would have been to write through the symlink to the file and then rename the symlink; the new behaviour is to write a regular file in-place of the symlink and delete the symlink.

• Breaking security features
• PR: If SSH is enabled and an authorized_keys file is managed by Forgejo, when Forgejo starts up it will read the SSH authorized_keys file and validate the file's contents. If any keys are found in the file that are not expected, then Forgejo will terminate its startup in order to signal to the server administrator that a security risk is present that must be addressed. The server administrator can address this problem either by deleting the authorized_keys file, which Forgejo will regenerate with valid keys; or by disabling the new check by setting [server].SSH_ALLOW_UNEXPECTED_AUTHORIZED_KEYS = true in their app.ini file.

• Breaking bug fixes
• PR: fix!: paginate GET /api/v1/admin/hooks response
• PR: fix!: Prevent forked .profile repositories from displaying profile content. When a user forked a repository named .profile without having created their own .profile repository, the content from the forked repository was unexpectedly displayed on their public profile page. This could lead to users' profiles displaying content they did not intentionally create for that purpose. Forked .profile repositories are now treated as standard repositories and do not populate the user's public profile page. Users who wish to use the content from a forked .profile repository can convert the fork to a regular repository in the "Danger Zone" section of Repository settings. This issue was particularly problematic on instances where users had repository creation limits (-1) and would inappropriately use forked .profile repositories to obtain profile customization.
• PR: Forgejo subcommands which only accept flag options would previously ignore any command-line arguments that were not flags and silently proceed to execute the command. This could lead to unexpected effects; for example, --must-change-password false is actually parsed as two arguments, --must-change-password, and false, where the false argument was ignored. In order to prevent misunderstandings where the user may have intended a supported argument format (--must-change-password=false), the presence of extra arguments that are not flags will now result in an error. Users of the Forgejo CLI who are relying on the previous behavior will find their commands are now resulting in errors.

This release includes an upgrade of Go version with security fixes. The issues addressed by this update do not pose any risk to the system or data security of Forgejo deployments, only potential for denial of service attacks.

• Breaking features
• PR: remove admin-level permissions from repo-specific & public-only access tokens
• PR: The template generation (POST /repos/{template_owner}/{template_repo}/generate) and repository deletion (DELETE /repos/{username}/{reponame}) APIs have been updated to require the same permission scope as creating a new repository. Either write:user or write:organization is required, depending on the owner of the repository being created or deleted.
• PR: Accessing the /repositories/{id} API with a public-only access token did not restrict read access to only public repositories, which is now prevented.
• PR: Accessing the /repos/{owner}/{repo}/issues/{index}/dependencies and /repos/{owner}/{repo}/issues/{index}/blocks APIs with a public-only access token had access to modification operations against private repositories in the form component of the API (not the URL component), which is now prevented.
• PR: Accessing the /repos/{owner}/{repo}/issues/{index}/dependencies and /repos/{owner}/{repo}/issues/{index}/blocks APIs with a public-only access token could view dependencies or blocking issues from private repositories, which is now prevented.
• PR: Accessing the /repos/{owner}/{repo}/issues/{index}/timeline API with a public-only access token could view comment cross-references from private repositories, which is now prevented.
• PR: Accessing the /teams/{id}/repos/{org}/{repo} API with a public-only access token could view private repositories assigned to a team, which is now prevented.
• PR: Access the watched repos and starred repos of a your own user through /user/subscriptions and /user/starred APIs with a public-only access token could view private repositories, which is now prevented.
• PR: implement repo-specific access tokens in relevant search & list APIs. Breaking: the following APIs could previously return private repositories when using a public-only access token, but can no longer do so: /user/repos, /users/{username}/repos, /orgs/{org}/repos, and /teams/{id}/repos.
• PR: implement repo-specific access tokens broadly for universal API permission checks. Breaking: API access with a public-only access token would previously return a 403 Forbidden error when attempting to access a private repository where the repository is on the API path. As part of incorporating the public-only logic into the centralized permission check, these APIs will now return 404 Not Found instead, consistent with how most permission checks are implemented in order to reduce the risk of data probing through error messages.

• Breaking bug fixes
• PR: fix(ui)!: Remove the instance configuration option repository.pull-request.ADD_CO_COMMITTER_TRAILERS (was enabled by default). It was responsible for addition of unexpected trailers to commit messages in squash merges. These trailers were Co-authored-by: and Co-committed-by:. Both used the pull request author as value, who is also assigned as the author of the squash merge commit, which they were just repeating. Furthermore, Co-committed-by: is an uncommon commit trailer, and there is only one committer for a commit. The trailers were being added by Forgejo while performing the merge, bypassing user input in the UI and weren't shown in it. See further description and more examples in #11097.

• Breaking changes without a feature or bug label
• PR: In Forgejo v8.0.0, the default location for the config file was changed from /etc/gitea/app.ini to /var/lib/gitea/custom/conf/app.ini. Backward compatibility logic and startup warnings were added to container setup and entrypoint scripts. Now they are removed. This change only affects those using container deployments with rootless images. If you have the config file stored in a volume bound to container's /etc/gitea, move it to the new location or override the environment variable GITEA_APP_INI. An unused volume /etc/gitea can be safely removed from the container after moving the config or if the deployment never used versions prior to v8.0.0.
• PR (backported): chore(Dockerfile.rootless): update shadowed env variables
• PR: Make cookie names brand independent. Attention: All users need to re-login, if you haven't manually set a cookie name in the settings. This can be prevented by changing the remember me cookie back to gitea_incredible

Also see a security announcement. Manual action is needed for some v15 deployments, as well as for upgrade to v16.0.0.

Learn more about most notable changes and addressing the breaking changes in our news post: Forgejo v16.0 is available.

Git hooks are now stored in a centralized location instead of being duplicated in every repository, and Git hook example files are no longer generated for new repositories. While a backwards-compatible change, your instance can benefit from following an upgrade guide to clean up these files for the existing repositories. As always, make sure you to have a usable backup before upgrading!

• Breaking security bug fixes
• PR: remove default 'REVERSE_PROXY_TRUSTED_PROXIES = *' from docker config
• PR: Improved compliance with the config settings [migrations].ALLOWED_DOMAINS, [migrations].BLOCKED_DOMAINS, and [migrations].ALLOW_LOCALNETWORKS, which control the remotes that Forgejo can access for git & LFS migration and mirroring operations, fixing time-of-check vs. time-of-use issue and missing checks in LFS. git mirror HTTP operations have been adjusted to never follow HTTP redirects in order to ensure that these settings are followed, which will break HTTP mirroring if a redirect is served by the git HTTP remote.

• Breaking bug fixes
• PR: use proper ${{ forgejo.ref }} in scheduled workflows
• PR: return API URL in the url field for pull requests using the API