Forgejo "carrot disclosure" raises security questions [LWN.net]

By Joe Brockmeier
May 8, 2026

An unusual, some might say hostile, approach to disclosing an alleged remote-code-execution (RCE) flaw in the Forgejo software-collaboration platform has sparked a multifaceted conversation. A so-called "carrot disclosure" in April has raised questions about the researcher's methods of unveiling a security problem, Forgejo's security policies, and the project's overall security posture.

Forgejo was forked from the Gitea collaboration and hosting platform in 2022. It is a project supported by the Codeberg e.V. nonprofit and is the software used by the Codeberg hosting service. The Fedora Project is also in the final steps of replacing its homegrown Pagure platform with Forgejo.

Carrot disclosure

In his disclosure post on April 29, Security researcher Julien Voisin said that it was Fedora's choice of the project as its collaboration platform that had inspired him to "take a good look at Forgejo's security posture". He claimed he had found a number of security flaws in Forgejo:

All in all, it took me one evening after work to find a good amount of vulnerabilities (adding to the one I got from looking at gitea at some point in the past), and chain some of them to obtain a full-blown RCE [...]

On April 27, Voisin had opened a few pull requests with the Forgejo project: a fix to quote attributes in a comment form, a change to remove a method that passed user-supplied strings to a command, and another to remove the "plain" OAuth authentication method. None of the pull requests included a description that might cause a maintainer to address the fixes as urgent for security reasons.

It also appears that he did not report any specific security flaws following the project's rather detailed security policy, even after being asked by "Gusted" when they noticed that Voisin had opened three pull requests with "some security relation". Voisin replied that he was going through his list of low-impact bugs "that could barely qualify as security issues worth reporting privately let alone choreographing an embargo". He also complained that the policy had "a lot of MUST, MUST NOT, MAY" requirements in reporting a security problem and wondered how the policy was enforced.

Rather than reporting the specifics of the RCE directly to the project, Voisin chose to do what he calls a "carrot disclosure", a term that he had coined in 2024. He defined it as "dangling a metaphorical carrot in front of the vendor to incentivise change", though in actuality the approach sounds more like the stick than the carrot. The idea is to demonstrate that the software is exploitable and to force the vendor to "perform a holistic audit of its software, fixing as many issues as possible in the hope of fixing the showcased vulnerability", or to lose users who are unhappy about running known-vulnerable software. "Users of this disclosure model are of course called Bugs Bunnies."

Fans of Looney Tunes cartoons might observe that, as a rule, Bugs did not go looking for trouble. Often he would be hunted or harassed in some fashion and then declare "of course you realize, this means war": but he did not instigate trouble. That seems relevant here, because Voisin's approach was the opposite: to go looking for trouble, and then to be provocative about it after a flaw is discovered.

Voisin claimed to have found an RCE, apparently unrelated to the issues he had opened pull requests about, that required a Forgejo instance to have open registration—in other words, to allow anyone to sign up to use the platform—and for it to have "a configuration option set to a non-default value". He did not specify which configuration option but said that it was enabled on some instances that he had looked at. His example showed him running a Python script, without revealing the actual code, that achieved an RCE against a Forgejo instance running on a local machine.

He said, in his disclosure post, that he could try to resolve the issues one by one with more pull requests but decided against it:

I could disclose the bugs to Forgejo, they even have a Security Policy, with a lot of MUST/MUST NOT about what I must or mustn't do should I decide to go this way. But given the sorry state of the codebase (not their fault though, they inherited the gitea/gogs ones), I'm pretty sure I could spend another evening and find another chain, and odds are that others have a bunch as well. I could try to fix the issues one by one myself and send pull-requests, but even if I wanted, this is a systemic issue, there is little point in playing endless wack-a-mole.

He said he was told, after discussing the topic with a friend, to "put my money where my mouth is, and just go with carrot disclosure that I usually advocate for in this kind of situation". After publishing the disclosure, he promoted it on the infosec.exchange Mastodon server on April 29. It quickly gained attention and became a topic of discussion on the Fediverse and was also shared on Hacker News, Lobste.rs, and other discussion forums.

Response

The public response was mixed and generally fell into two categories: those critical of Voisin's approach, and those who took Forgejo to task for its security policy and perceived problems. For example, Hans van Zijst said that it was "an incredibly condescending way to talk about someone else's work, and a horrible attempt to force volunteers to follow your priorities". Henry Catalini Smith said: "what you've done here was below any reasonable standard of professional conduct, and also very strange to me". He said that he had recently begun looking at Forgejo's accessibility bugs and thought it would be fun to work with the project on solving them; it made no sense to him that a specialist in a type of problem would want to "build a brand as someone this publicly hostile" to projects that had security problems.

On the Privacy Guides forum, "HackOrSwim" said that the reporter had acknowledged that many of Forgejo's problems were inherited when it forked from Gitea, but not that it would require a lot of resources to correct those problems. "This is essentially technical debt, which doesn't make it acceptable, but it makes it understandable why these issues are there. It's a non-profit, volunteer-driven project."

On the other side, Tony Arkles said that the policy "comes across as pretty demanding for a team that's getting free support from a community member", and called the process grating. "I think I'm with the author on this one." Elliot Speck, an information-security consultant and researcher, found that the Forgejo security guidelines are "obnoxious and pretentious". He said the project was "too busy taking the wrong things seriously".

Follow-up

Voisin published a follow-up with a summary of the events that took place after the disclosure on April 30. He said that he had been "called a handful [of] vile names", received complaints that he had "brought unwanted attention to an easy target", and responded to complaints that his conduct was unprofessional: "The terms 'not professional' (as in 'not acceptable in a professional environment') has been thrown around a lot, but nothing here is or was being done in a professional context."

He also said that he'd learned that "various entities" had revised their opinion about what Forgejo is, and isn't, "which was the main goal of the previous blogpost". Despite the drama, though, Voisin said it had led to some productive, good-faith conversations:

It seems that experimenting with odd vulnerability disclosure schemes is frowned upon. So I ended up sending an email to Forgejo security team, containing: an apology, a bit about my reasoning for proceeding with carrot disclosure, recommendations about what to harden/review, and a bunch of commented exploits/proof-of-concepts as attachment. We'll see how it goes.

On April 30, the Forgejo project published a short response. It said that Voisin had been in contact with Forgejo's security team with his findings:

The issues raised concern defense-in-depth improvements and denial-of-service risks. There is no known RCE exploit possible without internal server credentials.

We believe these findings can be addressed publicly. The security team will open issues where approaches to implement new defensive measurements will be discussed, we believe there's no single answer and as such appreciate the opinion of other Forgejo contributors on this matter.

The statement that the RCE is not possible without credentials seems to be at odds with Voisin's claims, but without more information there's no way to ascertain which is the case.

Given the increasing ease of using LLMs to find security flaws, it's entirely likely that Voisin casting a spotlight has increased the number of people spending tokens on finding holes in the project. Some of them may not be as well-intentioned as Voisin. In the coming weeks and months it will be interesting to watch Forgejo to see what kind of security improvements are made, and what kind of security flaws come to light.

to post comments

This is not disclosure, this is ransom bs

Posted May 8, 2026 19:25 UTC (Fri) by IanKelling (subscriber, #89418) [Link] (1 responses)

It is somewhat interesting, but I'm not a fan of giving attention to this kind of behavior.

This is not disclosure, this is ransom bs

Posted May 8, 2026 23:12 UTC (Fri) by jpeisach (subscriber, #181966) [Link]

Basically the ShinyHunters approach to extortion.

Can we rename it a Fudd disclosure?

Posted May 9, 2026 0:59 UTC (Sat) by mbg (subscriber, #4940) [Link]

Double entendres? We don't do those here...

Let's not participate to this

Posted May 9, 2026 5:29 UTC (Sat) by wtarreau (subscriber, #51152) [Link] (4 responses)

I think the person who did this did it only to have their moment of fame, and it apparently worked. I would personally have omitted their name from the description above to avoid further promoting such bad behaviors.

It's easy to say "gnagnagna I found a bug and you don't know it, now read your code". The reality is that large code bases take a very long time to be audited while the first one likely found it by chance, so the probability that an in-depth review finds the same issues is very low. This is just a bad self-promoting approach and certainly not a helpful way to report bugs.

Motivation

Posted May 9, 2026 5:52 UTC (Sat) by pabs (subscriber, #43278) [Link]

Definitely wasn't for any fame. They said in their original blog post that their motivation was that since they use Fedora, who switching to Forgejo, they had an incentive to finally look at security for it.

Let's not participate to this

Posted May 9, 2026 13:47 UTC (Sat) by marcH (subscriber, #57642) [Link] (1 responses)

> I think the person who did this did it only to have their moment of fame, and it apparently worked.

... whereas throwing a lot of sloppy and insecure code over the wall (= most open-source projects) and getting a lot of unsuspecting - and TBH: naive - users while not being open about the flaws and not warning them ... that it is never for fame of course!

(from the main article)

> For example, Hans van Zijst said that it was "an incredibly condescending way to talk about someone else's work, and a horrible attempt to force volunteers to follow your priorities". Henry Catalini Smith said: "what you've done here was below any reasonable standard of professional conduct, and also very strange to me".

In many (most?) cultures, "production" is valued a lot more than finding bugs, issues or critique in general. This is why everyone wants test coverage, code reviews and quality in theory but no one ever wants to pay for those. In my experience, an very large fraction of software developers show such a strong bias and hubris and can become very "condescending" and very dismissive very quickly as soon as you start pointing at flaws. But that's apparently OK cause you know, "look at all the code they wrote!" Never mind all the bugs and users losing data, time, money or worse.

Most users share the blame of course, too eager to jump on the latest shiny thing because FOMO and YOLO!

tl;dr: most software is very buggy and gets a lot more respect than it should and some course correction is good. If Mythos is as good and humbling as rumoured then it's great news. Who knows, we might get fewer lines of better code in the end? Contrary to other AI predictions - the irony.

To be clear: I have no idea how good or bad Forgejo is, LWN readers seem to have higher standards than the average SW slop and I'm sure Julien could have done better (good thing he apologized). These are general observations from a few decades of SW experience.

Let's not participate to this

Posted May 10, 2026 13:22 UTC (Sun) by ballombe (subscriber, #9523) [Link]

> Most users share the blame of course, too eager to jump on the latest shiny thing because FOMO and YOLO!

And if you do not jump, your project is flagged with having a "technical debt".

Let's not participate to this

Posted May 9, 2026 20:22 UTC (Sat) by tilt12345678 (subscriber, #126336) [Link]

At first read i also had this impression, that it even is wrong to contribute to the publicity of the reporter because of the weird theatrics surrounding the finding, but - after some hours in my mental background - it filed itself into the "stuff that happens" category. In the end it's security problems being found and (hopefully) eliminated, thus essentially a good thing overall from my consumer perspective. The bad vibes surrounding it highlight some problematic current internet customs (as does much else), but that's about it.

String based HTML building

Posted May 9, 2026 5:41 UTC (Sat) by pabs (subscriber, #43278) [Link] (7 responses)

I note in the patch to quote attributes that Forgejo are doing string based HTML building in JavaScript. Not using DOM based HTML building (document.createElement and friends) is a pretty poor security practice, so it doesn't surprise me that Forgejo code could be full of other insecure practices. Of course many other codebases create HTML this way. Probably the JavaScript ecosystem needs to deprecate and remove string based HTML building methods altogether.

Same goes for os.system() in Python and other sharp-edged APIs elsewhere.

String based HTML building

Posted May 9, 2026 17:39 UTC (Sat) by DemiMarie (guest, #164188) [Link]

That is indeed a serious problem. Not always exploitable but indeed a very poor practice.

String based HTML building

Posted May 10, 2026 4:30 UTC (Sun) by khim (subscriber, #9252) [Link] (5 responses)

> Probably the JavaScript ecosystem needs to deprecate and remove string based HTML building methods altogether.

And replace it… with what exactly?

> DOM based HTML building (document.createElement and friends)

Are entirely unsuitable for responsible interface. Because browsers don't have analogue of WM_SETREDRAW.

In an ideal world something like this would have been added decades ago… but in our world we have browsers with support for USB controllers and Bluetooth… but without sensible way of doing responsive UI except via crazy hacks.

String based HTML building

Posted May 10, 2026 6:36 UTC (Sun) by kleptog (subscriber, #1183) [Link]

While string based HTML creation is probably required under the hood, I thought the same until someone introduced me to Vue.js. As a developer it allows you to decompose your UI into components with interfaces, and you have straightforward templating for the output. All your escaping issues vanish and suddenly I could reason about a JS application without going crazy.

This is hardly new technology. If this project is still creating HTML by string concatenation in 2026, then it does make me concerned for the state of the rest of the project. Even Django with its templating engine is 17 years old now.

String based HTML building

Posted May 10, 2026 6:58 UTC (Sun) by cladisch (✭ supporter ✭, #50193) [Link] (1 responses)

> > DOM based HTML building (document.createElement and friends)
>
> Are entirely unsuitable for responsible interface. Because browsers don't have analogue of WM_SETREDRAW.

By now, browsers have the View Transition API: https://developer.chrome.com/docs/web-platform/view-trans...

(Most of the documentation talks about animations; what matters is that all DOM changes are put into a single animation.)

String based HTML building

Posted May 11, 2026 14:57 UTC (Mon) by khim (subscriber, #9252) [Link]

Nice. So something that should have been available since the day one was added, after quarter century.

But it takes time to change the codebase. Three years is not enough to switch everything to a new API after quarter century of kludges.

String based HTML building

Posted May 11, 2026 3:50 UTC (Mon) by pabs (subscriber, #43278) [Link] (1 responses)

You are building DOM elements either way, string vs API seems orthogonal to responsiveness. Make some new DOM elements (with strings or APIs), replace the existing DOM elements. With API based DOM element building, you still do the page updates in the same way.

String based HTML building

Posted May 11, 2026 15:14 UTC (Mon) by khim (subscriber, #9252) [Link]

> You are building DOM elements either way

Yes. But compiting resources matter.

> string vs API seems orthogonal to responsiveness.

Only when you can stop automatic updates of the screen. If you couldn't (and for decades it was impossible) then it's Ω(N²) vs Ω(N).

> Make some new DOM elements (with strings or APIs), replace the existing DOM elements.

That may work, sure — but at this point you are no longer dealing with DOM, anyway, you are using DOM as canvas… may as well pick API that makes things marginally better (things like Vue.js).

You couldn't have safety and speed in the pre View Transition API web, and picking safety when your app is unusable is not something people like.

Followup

Posted May 9, 2026 5:50 UTC (Sat) by pabs (subscriber, #43278) [Link] (4 responses)

https://dustri.org/b/follow-up-to-carrot-disclosure-forge...

Magnifying glass

Posted May 9, 2026 15:47 UTC (Sat) by marcH (subscriber, #57642) [Link] (3 responses)

> https://dustri.org/b/follow-up-to-carrot-disclosure-forge...
> On a more personal note, I found the amount of flak and hate completely wild,

This is what everyone keeps getting so wrong about the Internet. Sure, there were a large number of aggressive comments, but how does this number compare to the number of people who read about it? Considering this went viral, this could be 0.0001 % or even less, no one knows. So, maybe a surprisingly low amount.

In this "global village" with billions of people, we are still trying really hard to hang to tribe-sized communities and behaviors. The era with 1 or 2 degrees of separation is long gone but we keep acting like it's still there more often than not.

Probably the top priority is to much more "aggressively" filter and increase the signal/noise ratio. How much of this "flak and hate" came from people Julien actually cares or should care about? I bet extremely little. So how come he even saw that in the first place? He should never have.

The practical death of email is some progress towards that goal but it's not enough. We need much more "elitist" communication channels based on distributed reputation systems and what not. But most current information filtering systems are only designed to maximize clicks, echo chambers, propaganda and addiction. For kids even!

Magnifying glass

Posted May 14, 2026 19:21 UTC (Thu) by archaic (subscriber, #111970) [Link] (2 responses)

> The practical death of email is some progress towards that goal but it's not enough. We need much more "elitist" communication channels based on distributed reputation systems and what not. But most current information filtering systems are only designed to maximize clicks, echo chambers, propaganda and addiction. For kids even!

<old man rant>
I don't understand this paragraph. You are welcoming the death of email and in the same breath bemoaning the things that all other modern forms of communication more naturally lend themselves to (echo chambering, etc.). Not every thing I may want to say to someone should be required to be blasted from a megaphone atop a building. Perhaps it is just my age, but we lost the "personal" in personal communication (along with much that that entails).
</old man rant>

Magnifying glass

Posted May 15, 2026 12:06 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

> I don't understand this paragraph. You are welcoming the death of email and in the same breath bemoaning the things that all other modern forms of communication more naturally lend themselves to (echo chambering, etc.).

Yes, because they are both buggy by design. The former has no filtering. To "solve" that lack of filtering, you are the product in the latter. And what the dopamine drugs the attention merchants get us dependent on is so addictive and effective that we don't even look for alternatives. Just for fun, try to move people away from Instagram and to Mastodon.

The rest of your comment lost me, sorry.

Magnifying glass

Posted May 15, 2026 12:13 UTC (Fri) by marcH (subscriber, #57642) [Link]

Forgot to say, sorry.

> Just for fun, try to move people away from Instagram and to Mastodon.

I'm not claiming Mastodon is some perfect solution to it all. But:
- for sure it's trying hard
- Most people on Instagram and co. won't even want to _hear_ about it. That was my point.

Open registration

Posted May 9, 2026 22:37 UTC (Sat) by vimja (subscriber, #91577) [Link] (4 responses)

> The statement that the RCE is not possible without credentials seems to be at odds with Voisin's claims [...]

I'm not so sure. Before, you write:

> [...] required a Forgejo instance to have open registration [...]

Open registration means anyone can have an account. So "having credentials" and "open registration" could just be two different ways of saying the same thing.

Open registration

Posted May 10, 2026 16:52 UTC (Sun) by jzb (editor, #7867) [Link] (3 responses)

So "having credentials" and "open registration" could just be two different ways of saying the same thing.

I don't believe so; their statement, which was quoted, said: "no known RCE exploit possible without internal server credentials". (Emphasis added.) I don't interpret "internal server credentials" as something one gets from simply signing up for a Foregjo account.

Open registration

Posted May 11, 2026 0:08 UTC (Mon) by muase (subscriber, #178466) [Link] (2 responses)

But if we follow that interpretation, the question is what those "internal server credentials" are supposed to be? Because aside from administrative credentials, there are no other "internal server credentials" I know of here.

> So "having credentials" and "open registration" could just be two different ways of saying the same thing

Tbh I also read it the same way, for two reasons. First, the emphasis on internal credentials doesn't make sense: if an attacker has internal server credentials aka admin access, the server is compromised – it doesn't make sense to emphasize that here; it's a no-brainer. Non-open registration would make a lot of sense though: in my experience most gitea/forgejo servers are private and public signup is disabled, so – unlike above – this differentiation would make sense.

Open registration and 'internal server credentials'

Posted May 14, 2026 10:59 UTC (Thu) by kpfleming (subscriber, #23250) [Link]

Forgejo also has INTERNAL_TOKEN and SECRET_KEY in its server configuration.

Open registration

Posted May 15, 2026 18:36 UTC (Fri) by jzb (editor, #7867) [Link]

Since it was ambiguous, I asked the Forgejo folks to clarify what was meant here. I received this reply, which said, "It requires either admin credentials or an internal access token that Forgejo uses to communicate with itself in some situations."