Removing .git after expansion seems fragile. Sandboxing the git step would close the whole class of bugs.
Forgejo <=16.0.3 Critical RCE
71–80 of 87 posts
Re: Forgejo <=16.0.3 Critical RCE
#72I'm just reading the code here:
// Before template expansion, .git was removed so that a fresh repo can be initialized; remove it again in case
// some template variable usage has conflicted with this directory and impacts git operations.
if err := root.RemoveAll(".git"); err != nil {
return fmt.Errorf("unable to remove .git folder")
}
User/operator can't really fix the problem if you keep giving them information this vague.
Re: Forgejo <=16.0.3 Critical RCE
#73Earlier quoted context omitted.
It looks like Gitea made the same fix (rm -r .git after template processing) back in February: https://github.com/go-gitea/gitea/commit/2176e84ab977011ff2b... PR: https://github.com/go-gitea/gitea/pull/36734 So likely Gitea < 1.25.5 was vulnerable.
It is unfortunate nobody tipped anyone off downstream.
given the fact that they communicated about this as a CVE, and Forgejo is a fork of gitea, one could say that this is on Forgejo though.
Re: Forgejo <=16.0.3 Critical RCE
#74I'm working on a tool to reproduce stuff like this exactly.
Yep this is an RCE with the forgejo user on the host.
https://www.pruva.dev/reproductions/REPRO-2026-00345 for details.
you can even start your version of the repro using github codespaces
========================================
REPRO-2026-00345
========================================
Title: Forgejo Severity: CRITICAL
CVE: CVE-2026-89094
========================================
[pruva] Working directory: /workspaces/pruva-sandbox/pruva-results/REPRO-2026-00345
[pruva] Found script artifact: bundle/repro/reproduction_steps.sh
[pruva] Downloaded 4 repro artifact(s), script: 324 lines
[pruva] ==========================================
[pruva] WARNING: This will execute code that
[pruva] exploits a real vulnerability.
[pruva] ==========================================
[pruva] Auto-confirming in sandbox environment...
[pruva] Running reproduction script...
--- REPRODUCTION OUTPUT ---
[09:39:29] ensuring container images are present
[09:39:42] vulnerable image digest: sha256:214f4ae63ee78be1e445e58573c88dc7215e72091210852e0df94eaac1a25685
[09:39:42] fixed image digest: sha256:a263a1298e89e0bdf019005ce1927e9aadaa8f1bd2a94a3e66ad94e2a89e19ce
[09:39:42] [vuln-1] starting container (codeberg.org/forgejo/forgejo:16.0.3-rootless)
[09:39:52] [vuln-1] service healthy on 127.0.0.1:4011
[09:39:53] [vuln-1] admin user + token ready
[09:39:55] [vuln-1] malicious template pushed
[09:40:03] [vuln-1] generate API returned 201
[09:40:15] [vuln-1] marker=**** hook_id=**** hostdata=**** readme_ok=**** gen=201
[09:40:15] [vuln-2] starting container (codeberg.org/forgejo/forgejo:16.0.3-rootless)
[09:40:25] [vuln-2] service healthy on 127.0.0.1:4012
[09:40:26] [vuln-2] admin user + token ready
[09:40:28] [vuln-2] malicious template pushed
[09:40:32] [vuln-2] generate API returned 201
[09:40:36] [vuln-2] marker=**** hook_id=**** hostdata=**** readme_ok=**** gen=201
[09:40:36] [fixed-1] starting container (codeberg.org/forgejo/forgejo:16.0.4-rootless)
[09:40:40] [fixed-1] service healthy on 127.0.0.1:4111
[09:40:40] [fixed-1] admin user + token ready
[09:40:41] [fixed-1] malicious template pushed
[09:40:46] [fixed-1] generate API returned 201
[09:40:50] [fixed-1] marker=false hook_id=false hostdata=false readme_ok=**** gen=201
[09:40:50] [fixed-2] starting container (codeberg.org/forgejo/forgejo:16.0.4-rootless)
[09:40:52] [fixed-2] service healthy on 127.0.0.1:4112
[09:40:53] [fixed-2] admin user + token ready
[09:40:54] [fixed-2] malicious template pushed
[09:40:58] [fixed-2] generate API returned 201
[09:41:02] [fixed-2] marker=false hook_id=false hostdata=false readme_ok=**** gen=201
[09:41:02] vuln markers: **** / **** ; hook-id: **** / **** ; hostdata: **** / **** ; gen: 201 / 201
[09:41:02] fixed markers: false / false ; readme-ok: **** / **** ; gen: 201 / 201 runtime_manifest.json written with 44 proof artifacts
[09:41:02] VERDICT: CONFIRMED - remote code execution reproduced on Forgejo 16.0.3 via crafted template repository; fixed 16.0.4 unaffected
--- END REPRODUCTION OUTPUT ---
[pruva] ==========================================
[pruva] VERIFICATION SUCCESSFUL
[pruva] Duration: 93s
[pruva] ==========================================
[pruva] Logs: /workspaces/pruva-sandbox/pruva-results/REPRO- 2026-00345/logs/ - fixed-1 - fixed-2 - reproduction_steps.log - vuln-1 - vuln-2
[pruva] Results saved to: /workspaces/pruva-sandbox/pruva-results/REPRO-2026-00345
[pruva] Keeping work directory: /workspaces/pruva-sandbox/pruva-results/REPRO-2026-00345 Outcome: success User: vscode WorkspaceFolder: /workspaces/pruva-sandbox
Re: Forgejo <=16.0.3 Critical RCE
#75The opex and security fine costs of moving off managed services like GitHub/GitLab are catching up.
The amount of time I need to spend maintaining my Forgejo instance this year, even after accounting for this RCE, has been less than the amount of time GitHub has been degraded or unavailable this year.
That doesn't match my experience at all. I had a Foregjo instance on a Raspberry Pi, and maybe it's typical SD card issues, but the number of times that Forgejo has crashed because it locked its own database and couldn't continue and the number of times repos I mirror from GitHub just mysteriously stop syncing is quite probably the same number of times GitHub has been down this year.
Re: Forgejo <=16.0.3 Critical RCE
#76Earlier quoted context omitted.
Very interested in knowing too, since the issues seems to not be related at all, or similar, so now this must mean a Gitea "project leader" would only say this if they have some sort of layer that doesn't require them to manually patch issues individually. Meaning, firewall? Would be weird if that's built-in into Gitea though... Hmm.
It looks like Gitea made the same fix (rm -r .git after template processing) back in February: https://github.com/go-gitea/gitea/commit/2176e84ab977011ff2b... PR: https://github.com/go-gitea/gitea/pull/36734 So likely Gitea < 1.25.5 was vulnerable.
So not "Gitea is protected against both of these issues" but "Gitea fixed these issues earlier", which kind of feels like a less marketing-friendly version of what the Gitea employee said above.
Why people can't just talk clearly and not try to oversell whatever they're doing? It's a disease at this point.
Re: Forgejo <=16.0.3 Critical RCE
#77Trying to open any codeberg.org page from my main Helium browser results in a 403 just saying "Bye". Opening in Chrome or Firefox works fine. Very confusing.
Update: I raised this issue on their platform issue tracker, and was informed that it is, in fact, intentional. Sigh...
Re: Forgejo <=16.0.3 Critical RCE
#78Only posting here because I've been asked about it. Gitea is protected against both of these issues. (bias note: part of project leadership of Gitea) Edit: As a note, security incidents happen to everyone and we shouldn't shame anyone for reporting them, especially as that'd otherwise cause less issues to be reported overall.
If you upgraded from < 1.25.5
Re: Forgejo <=16.0.3 Critical RCE
#79Earlier quoted context omitted.
It looks like Gitea made the same fix (rm -r .git after template processing) back in February: https://github.com/go-gitea/gitea/commit/2176e84ab977011ff2b... PR: https://github.com/go-gitea/gitea/pull/36734 So likely Gitea < 1.25.5 was vulnerable.
It is unfortunate nobody tipped anyone off downstream.
CVE AND release note not enough tipping off for you?
it is absolutely not on maintainers of projects to proactively notify those who've forked the project. clear and transparent notices are exactly the right approach
Re: Forgejo <=16.0.3 Critical RCE
#80Earlier quoted context omitted.
It looks like Gitea made the same fix (rm -r .git after template processing) back in February: https://github.com/go-gitea/gitea/commit/2176e84ab977011ff2b... PR: https://github.com/go-gitea/gitea/pull/36734 So likely Gitea < 1.25.5 was vulnerable.
i like how this is a side effect of a bunch of assorted changes in a commit and PR solely described as "Fix path resolving" making it hard for anyone running Gitea to even know this is a security fix
I'm not completely sure if this is supposed to be sincere, but it should be.
It's not uncommon practice to omit the security implications on public facing commit messages when fixing secirity issues, so as to not to draw attention until it's ready for distribution.