Security researcher Julien Voisin, known online as jvoisin, needed just one evening to uncover a troubling security picture of Forgejo. In a post published on April 28, he claims to have found multiple vulnerabilities and chained some of them together to achieve remote code execution.

The motivation was practical. Fedora has started migrating from Pagure to Fedora Forge, a new platform built on Forgejo. The transition isn’t finished yet: the final cutover is scheduled for Flock 2026, with remaining Pagure instances being phased out in the Fedora 46 roadmap. Still enough reason for Voisin to take a closer look at the project’s security posture.

What he claims to have found is not reassuring. The list starts with SSRF vulnerabilities, which allow attackers to make the server execute requests to attacker-chosen destinations, potentially including internal resources not exposed to the internet. Add to that browser-side weaknesses like the absence of Content Security Policy and Trusted Types, defenses designed to limit the impact of potential XSS attacks.

The researcher also flags fragile JavaScript templating, cryptographic practices he judges questionable, and problems in authentication mechanisms: OAuth2, OTP, sessions, access management, and post-compromise account recovery. In short, not just isolated bugs, but flaws in areas that should protect identity, permissions, and account persistence.

The picture is completed by various denial of service vectors, information leaks, and TOCTOU race conditions: bugs where the software checks a condition at one moment, then uses that resource later when the state may have changed. On a platform managing code, users, repositories, and permissions, that’s exactly the kind of surface that can turn a local flaw into a wider attack chain.

According to Voisin, by combining some of these vulnerabilities, it’s possible to achieve full RCE, leak secrets, gain persistent account access, and escalate privileges via OAuth2. One important detail for context: the RCE chain described is not presented as exploitable on every Forgejo installation. The researcher notes it requires open registration and at least one configuration option set to a non-default value. He adds, however, that he found both conditions active on some real public instances.

The carrot disclosure approach

Rather than opt for coordinated disclosure, private vendor notification with time to fix and later publication, or immediate full disclosure, Voisin chose an approach he had already theorized in 2024: carrot disclosure.

The idea is simple and deliberately uncomfortable: publish only the output, possibly redacted, of an exploit for a critical vulnerability, without releasing the exploit code itself. This demonstrates the vulnerability is exploitable without handing out a ready-made recipe.

The vendor faces a choice: conduct a broader audit of the software hoping to fix the chain shown, or live with the reputational risk of having their software publicly flagged as vulnerable. In his Forgejo post, Voisin also publishes the SHA256 hash of the script used for the demonstration, so he can later prove the exploit existed at the time of disclosure.

The trickiest part is just this: the post doesn’t contain the technical details needed to reproduce the chain, but shows code execution output and a file structure suggesting multiple exploits or supporting scripts exist. It also references some already-open pull requests, but argues the problem isn’t a single bug to fix. His view is that the issue is more systemic.

For those running an instance

The RCE chain Voisin describes shouldn’t be read as automatically exploitable on every Forgejo instance. The prerequisites mentioned in the post are open registration and a non-default configuration. It’s worth noting, though, that in Forgejo’s documentation, DISABLE_REGISTRATION defaults to false. In other words, open registration is the documented default behavior unless your administrator configures otherwise.

The published output mentions a “server-side hook”. This makes it worth carefully reviewing settings related to Git server-side hooks. Forgejo documents DISABLE_GIT_HOOKS: true as the default value and warns that enabling them can allow arbitrary code execution on the host system. Voisin’s post, however, doesn’t explicitly identify that option as the non-default prerequisite for the chain, so it’s better to treat it as an area to verify rather than a certain diagnosis.

Until clarification or updates from the project, anyone running a Forgejo instance should review their configuration, evaluate whether public registration is truly necessary, and carefully check any features that could introduce server-side code execution or unnecessary attack surfaces.