Carrot Disclosure: Forgejo

This is so wrong. Because he didn't like a PR removing a feature, and they haven't yet merged another PR that was opened yesterday?!?

I wonder why they didn't change it to use DOM APIs instead. Related comment:

https://news.ycombinator.com/item?id=47945472

The author sent 5 more pull requests fixing (tragically) fundamental security flaws. https://codeberg.org/forgejo/forgejo/pulls?q=&type=all&sort=...

--- 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.

I'm really confused by this interpretation. I see a single comment by the maintainer, saying:

> That mistake was made in the past (#8634), where there was still a lot of usages of a old and announced deprecated method (and even with quite some effort there is).

It was a related, but separate issue, which is perhaps best-described in this upstream issue: https://github.com/python-social-auth/social-core/issues/121...

The "plain" setting jvoison wants to remove is described here: https://security.stackexchange.com/a/218554

I do agree with the maintainer that a discussion is warranted before removing this setting. But I also wouldn't personally have closed the PR while waiting for said discussion to occur - and the maintainer could have created a discussion themselves. They are signaling they don't want this change, full stop.