Forgejo monthly report - May 2026

The monthly report is meant to provide a good overview of what has changed in Forgejo in the past month. Additionally, this report covers the previous month, April 2026, as well. If you would like to help, please get in touch in the chatroom or participate in the ongoing discussions.

Releases

Forgejo v15

Forgejo v15.0.0 was released on April 16. As a long-term-support release, it will be supported with bug and security fixes until 15 July 2027.

Two security releases have been completed since v15’s initial release: v15.0.1 and v15.0.2. The next security release v15.0.3 is scheduled for June 10.

Report any regressions you find in the issue tracker. If the issues you’re facing are related to security, please report them to the security team according to the security policy.

Security releases: Forgejo v11 and v14

Three security releases occurred in April and May for previous v11 LTS, and the last stable release v14.

  • April 10: Forgejo v11.0.12 & v14.0.3
  • April 29: Forgejo v11.0.13 & v14.0.4
  • May 12: Forgejo v11.0.14

Support for Forgejo v14 ended on April 30, and no future releases will be provided. All v14 installations should upgrade to v15 immediately.

Support for Forgejo v11 will end soon, on July 16, and no future releases will be provided after that date. All v11 installations should upgrade to v15 before the end of support.

As a reminder, Forgejo publishes advance warning of security releases, similar to what is done when a Go release contains a security fix. They do not reveal the details of the vulnerability but will allow admins to plan ahead and better secure their instance. Anyone can watch the dedicated tracker or subscribe to the RSS feed.

Forgejo Runner

Forgejo Runner has received multiple releases since the last monthly report and is currently v12.10.2.

With the introduction of the new runner registration process in Forgejo 15, all commands supporting the old process around the runner registration token and the .runner file have been deprecated (register, create-runner-file). However, support for .runner will be kept around for the foreseeable future. If your use cases aren’t supported well by the new tooling, please let us know.

Apart from numerous bug fixes, the first features slated for Forgejo 16 have landed, too: entrypoint customization for job containers and services.

As every month, the users of Forgejo Actions have been busy filing feature requests. One that has seen a lot of interest and discussion is Pluggable Backend Architecture. The aim is enabling the development of third-party plug-ins that can run jobs in alternative back-ends like virtual machines or Kubernetes. There is already a working prototype that runs jobs in Kubernetes.

forgejo-runner one-job is now capable of requesting a specific job from Forgejo, allowing for precise execution of targeted jobs in managed runner scaling configurations (PR 1443 requires Forgejo 15).

A fix was merged to prevent containers from being left over by jobs in some error conditions (PR 1523).

Forgejo Helm chart v17

Following the release of Forgejo v15, the Forgejo Helm chart received a new major release to update the default Forgejo version. One patch and one minor release followed for the corresponding v15 patch releases: v17.0.1 and v17.1.0. The minor release brought the values.schema.json file for easier values validation.

Security Announcements

’Carrot Disclosure’

Forgejo was the subject of a blog post entitled “Carrot disclosure: Forgejo” on April 28th, which made remarks about Forgejo’s security posture, and made claims that it was vulnerable to one-or-more remote code execution (RCE) security vulnerabilities that the author chose not to disclose to Forgejo.

Forgejo’s security team initially chose to make no public response to this blog post. We internally discussed the situation, and decided there were no actions to take — we have no capability to perform the work requested in the blog post of “perform[ing] a holistic audit of its software, fixing as many issues as possible in the hope of fixing the showcased vulnerability”. As a volunteer team this is outside of the scope of what we can do. We planned to address the opened pull requests, and continue to rely on responsible security researchers to disclose vulnerabilities per the security policy.

The blog’s author decided to change their position on April 30th, and disclosed their proof-of-concept vulnerability scripts to us. We appreciated the change towards an approach of responsible disclosure.

Generally, we collaborate together within the security team to create patches for issues privately when we believe that public disclosure of a Forgejo flaw would put Forgejo users at a great risk while the flaw was exploitable, public, and unpatched. For example, during this same time window, we released Forgejo 15.0.1, 14.0.5, and 11.0.13, which contain a fix for an authorization bypass which allows any authenticated user to write to public repositories that they don’t own. Developing this fix in public would have made more people aware of the issue for a longer period of time, and so it was developed in private and published in coordination with the release team for an immediate new release.

We completed a review of the vulnerability scripts provided by the blog author, and determined that all of the issues raised could be addressed in-public as knowledge about the issues do not indicate any significant risk to Forgejo installations. Describing any of the reported vulnerabilities as an RCE is inaccurate, as the most severe of them require access to internal server or administrator credentials, and no vulnerability has been demonstrated to us to breach those credentials remotely.

Accordingly, all of the issues have had public issues filed, in order for design discussions, workarounds, and contributor developer support to be available to help bring them to a resolution:

Additionally, the pull requests referenced in the blog post have since been reviewed, and either merged, closed, or sent back to the author with requests for changes.

The blog author also noted that Forgejo’s current security policy is a difficult read. We agree. A community member has started a discussion on updates to the policy (https://codeberg.org/forgejo/discussions/issues/462), and we support simplifying and cleaning this policy up.

Private Package Registries

A public security disclosure was made on May 27 2026 that indicated Gitea and other derived software was affected by a security vulnerability tracked as CVE-2026-27771, which alleges to expose private packages to unauthenticated users. Forgejo’s security team disagrees with the characterization and reporting in this case.

When packages are uploaded to Forgejo, they are uploaded to a user or organization that owns the packages. Their visibility to other users is directly tied to the visibility of their owner — a public owner infers a public package, and a private owner infers a private package. When a package is private because of the privacy of the owner, we know of no vulnerabilities that allow access to the package contents.

This tying together of owner visibility and package visibility isn’t as flexible as Forgejo users would like it to be. And, it can be surprising to users as they can get the impression that package visibility should follow repository visibility when packages are linked to repositories. However, these are desired functional enhancements, not security vulnerabilities. It has never been documented or represented that package visibility relates to repository visibility, and the fact that packages are uploaded to Forgejo without being related to a repository is already a strong indicator to users that there is no such security control.

In order to reduce the risk of confusion causing security incidents, Forgejo is adding a warning on private repositories that use packages when the repository owner has a non-private visibility. This will be present in our next v15 Forgejo release. Discussion and design work is underway for future package visibility improvements and community feedback and contributions are welcome.

Documentation: OpenSSH Recommendations

New recommendations have been published in the Forgejo Admin Guide to improve configuration of OpenSSH servers being used to access to Forgejo. These recommendations come from the Codeberg team’s experience in optimizing and improving access to SSH at scale: OpenSSH Recommendations

Forgejo v16 Development

New Forgejo Actions APIs

A new HTTP API for Forgejo Actions artifacts has been merged into Forgejo v16. Endpoints for accessing logs of workflow runs and individual jobs were added, too. If everything goes according to plan, it will be included in Forgejo v16.

We’re looking for feedback. Changing an API once it has been released is very hard. Either build Forgejo yourself or try it on https://v16.next.forgejo.org/. Please open a new issue if you encounter problems or have feature requests.

Important: The HTTP API is not fully compatible to GitHub’s actions/download-artifact and there are no plans to make it fully compatible. Matching GitHub’s REST API requires more than sending some JSON in the right format. Forgejo already had to patch v4 to make it work. We’re currently weighing our options on how to proceed.

Authorized Integrations

Forgejo v16 has landed a capability called Authorized Integrations to accept remotely generated JWT tokens for authentication. Authorized Integrations allow API requests to Forgejo to be authenticated based upon a JSON Web Token (JWT) generated and signed by an external system. Examples of compatible systems include: Forgejo Actions (on the same, or a different, Forgejo instance), GitHub Actions, GitLab CI/CD, and Amazon Web Services.

Forgejo v15 added the ability for Actions to operate as a client with JWT-enabled federated identities, and Authorized Integrations now allows Forgejo to act as a resource server in this workflow.

This capability fills a major functional gap in Forgejo Actions. A long-standing request for the ${{ forgejo.token }} authentication token to have configurable permissions is now covered by this feature implementation, while also enabling cross-server permissions in a network of Forgejo installations.

The Authorized Integrations documentation provides more information.

Federation

Warning

Federation is under active development and is still considered experimental. Enabling it can forever make the domain Forgejo is running on unavailable for federation with other software in the future. See the FAQ for more information.

The last pull request taken from Federated user activity following was merged, which introduces the ability to follow other ActivityPub users and introduces an ActivityPub feed for federated notes from other instances (currently only Forgejo, Mastodon and GoToSocial). The limitation on software federation is temporary and will be removed in a future release.

Forgejo Usage in the Wild

We Forge

Forgejo is a community of people who contribute in an inclusive environment. We forge on an equal footing, by reporting a bug, voicing an idea in the chatroom or implementing a new feature.

The following list of contributors is intended to reflect this diversity and to acknowledge all the contributions made over the past month. If you are missing, please ask for an update.