Carrot Disclosure: Forgejo (opens in new tab)

Yeah, ITOps and software teams are totally aware of the second order effects of their shitty software and compliance failures, security are always the wrong ones.

I believe the discussion in #8634 is for a different change, but one of a similar nature.

PR isn't a place for discussion about what or how to implement change in the first place, that should be forum/mailing list/issues

and there is open issue for that discussion https://codeberg.org/forgejo/forgejo/issues/8634

The response was, "needs a discussion," as in a post on `https://codeberg.org/forgejo/discussions`, rather than directly creating a PR.

There also was feedback saying approximately that they've been burned by security changes in the recent past and don't want to run into similar issues without due consideration.

Seems like grandstanding bad faith to me. They didn't even bother to follow the established disclosure policy for this project because the author feels this quality of the code is so crap, so instead does this...

--- In this session we are going to explore the vulnerabilities documented in this carrot disclosure post at https://dustri.org/b/carrot-disclosure-forgejo.html and try to reproduce the script that explores the chain to gain admin access to forgego.

The post mentions just briefly what's been used to create the vuln chain: `SSRF in a lot of places, no CSP/Trusted-Types, a bit of ghetto templating in javascript, cryptographic malpractices, overlooks in the authentication mechanisms (OAuth2, OTP, sessions/access handling, post-compromission recovery, …), a bunch of low-hanging DoS, information leak all over the place, various TOCTOU, … 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`.

There is also the outline of the script call and the output we will use to base the script reproduction:

``` $ python3 ./chain_alpha.py --target http://127.0.0.1:3000 > out.txt $ grep Backdoor out.txt [+] Backdoor admin created: svc_ljeopgid / dukecepapsygiqks!A1 $ tail -n17 out.txt

================================================================ [+] COMMAND EXECUTION CONFIRMED! ================================================================

Server-side hook output (received via git push stderr):

  remote: ==========================================
  remote: FORGEJO RCE PoC - Command Execution Proof
  remote: ==========================================
  remote: hostname: chernabog
  remote: uid:      uid=1000(jvoisin) gid=1000(jvoisin) groups=1000(jvoisin),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
  remote: date:     Tue Apr 28 19:16:59 UTC 2026
  remote: proof:    chernabog
  remote: ==========================================

================================================================ $ sha256 ./chain_alpha.py c10d28a5ff74646683953874b035ca6ba56742db2f95198b54e561523e1880d7 ./poc/chain_alpha.py jvoisin@chernabog 11:35 ~/Documents/exploits/forgejo tree . ├── chain_alpha.py ├── chain_beta.py ├── chain_gamma.py ├── dos │ ├── cpuburn_authenticated.py │ ├── cpu_dos.py │ ├── dbburn.py │ ├── dfburn.py │ ├── exhaust.py │ ├── gburn.py │ ├── grpstarve.py │ ├── rstarve.py │ ├── starve.py │ └── storage.py ├── f9_repo_settings.py ├── get_version.py ├── leak_secrets.py ├── leak_token.py ├── merge.py └── NOTES.md

2 directories, 19 files $ ```

Our working directory already contains the source for forgego.

I am no security expert so we will need to approach this in four stages:

First I need you to guide me through each of the vuln concepts exposed in the article. In this step I am going to read through them and understand each of them.

I am also not familiar with forgego codebase, so in the second step I need you to guide me through the code, as we explore and understand the architecture and implementation of this git platform.

In the third stage we are going to validate my understanding of the first stage by linking each of the concept with the actual codebase.

Finally, in the fourth stage we are most likely prepared to tackle reproducing the vuln chain exploit.

Create one work item for each step. We are going to go through each of them in separate sessions.

> But the author's whole attitude is that Forejo is such a mess and it's barely worth their time to try and clean it up. Nobody's twisting their arm to contribute to an open source project that they don't even like!

> From the perspective of Forgejo maintainers, the author is just some random new contributor barging in and telling them to drop some legacy support that hasn't been discussed in detail yet. And of course, this new contributor hasn't actually followed the security policy to disclose it as a high severity issue to justify the change.

It does affect my own willingness to use Forgejo, as a current non-user. It sounds like it has some security vulnerabilities that the maintainers aren't taking seriously, perhaps because they think the people who report those vulnerabilities are jerks. Are the Forgejo maintainers themselves sure that their software isn't going to get pwned in a way they don't have the right techniques to mitigate? I'd rather know that before I run it on my own infra.

Don’t forget, repeatedly ignoring the requirements for including tests, and instead offering up a “have tested it locally, trust me” as a substitute.

Idunno, I think this model of disclosure feels more natural to me. The "coordinated" model can have the smack of extortion to it.

And yes, I very much want there to exist people whose specialty is finding security bugs. I wouldn't expect such a person to be a diehard contributor to any particular project. Their motivation isn't making one tool better, but keeping users safe. We need those people and the work they do badly!

While I agree with you that this blog post (and the "carrot disclosure" described in it) is ill-considered, the pull request is not really "new code", it adds quotes to HTML attributes that are missing them. I think it's entirely reasonable for a contributor to assume that a new test case would not be needed for this small change, and that the maintainer's response ("So a simple question: is this code covered under a test? If not, you will have to add one.") is more abrasive than necessary.

> Someone asking you to write a test for new code

per the response: "I'm not sure what kind of test would you like me to write for this change, as it's simply adding 4 quotes"

To hell with writing a test for you. That’s what you say to someone who gets paid by you. If the project doesn’t want the fix. That’s their issue, not the reporter’s.