Forgejo 13.0.0 → 14.0.0

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.