For those on version 15 LTS, this fix was released with v15.0.8.
Updated mine now. The release notes[0].
0. https://codeberg.org/forgejo/forgejo/src/branch/forgejo/rele...
Forgejo <=16.0.3 Critical RCE
61–70 of 87 posts
Re: Forgejo <=16.0.3 Critical RCE
#62Earlier 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.
It is unfortunate nobody tipped anyone off downstream.
Re: Forgejo <=16.0.3 Critical RCE
#63Earlier quoted context omitted.
They did not disallow LLM contributions, and they definitely didn't disallow using LLMs to research security vulnerabilities. They only disallowed projects that are majority LLM-written. https://codeberg.org/Codeberg/org/commit/71149c7fc95ccfeae36...
That is about Codeberg, not Forgejo. Forgejo disallows LLM contributions, including using a "general AI" (they include LLMs under "general AI") for reviews[0]: > 5. Using general AI for review is forbidden. If the change contains changes to the UX it has to be approved by a human reviewer. [0] https://codeberg.org/forgejo/governance/src/branch/main/AIAg...
>If the change contains changes to the UX it has to be approved by a human reviewer.
Would that not imply that a change that does not effect the UX does not have to be approved by a human reviewer? Otherwise, why specifically call out "changes to the UX" and not say "all changes"?
Re: Forgejo <=16.0.3 Critical RCE
#64Earlier quoted context omitted.
You can. People on Codeberg use LLMs. They are just against spam of low quality projects generated with LLMs.
That is actually entirely not what they were saying at the time of the vote and its aftermath. At all. Go back and read the threads. On this forum, or on mastodon, or on the vote. It was pretty vociferously ... shall we say ... "principled" It was never stated to be about "low quality" but about use in "large part" or "majority", and when pressed people refused to define what that meant, and in fact got angry and def…
Do you expect it to be enforced by a machine? Why would you need a precise definition of "majority"?
Re: Forgejo <=16.0.3 Critical RCE
#65Earlier quoted context omitted.
Are you sure? The change says "A malicious template repository could be used to read arbitrary data from the Forgejo host " (emphasis added). Couldn't an attacker create a template repo and then immediately create a new repo from their own template, causing the Forgejo process to execute their template code on the server?
They could, and this is definitely a RCE (a Remote Code Execution) vulnerability. GP confusion stems from the fact, that you (the forgejo user) must execute this attack on "your" instance. But of course the problem is that forgejo user can, in fact, be malicious, and use this vulnerability to escalate their priviliges from user to server. It can't be done without authenticating first, but there's nothing about RCE th…
Would be good to label it "authenticated RCE" to make this clear
Re: Forgejo <=16.0.3 Critical RCE
#66Earlier 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.
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
Re: Forgejo <=16.0.3 Critical RCE
#67Earlier 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
It’s explicitly listed as a security fix in the release notes, accompanied by a CVE: https://blog.gitea.com/release-of-1.25.5/
Re: Forgejo <=16.0.3 Critical RCE
#68This was my first thought after they disallowed LLM contributions. They may not use AI to check for vulnerabilities but attackers are going to which puts themselves at the disadvantage.
Disallowing LLM contributions doesn't disqualify the use of LLMs to identify vulnerabilities.
Using LLMs for automated security audit looks like it could fall under the definition of "vibe coding" or "agent mode", which is strictly forbidden
>6. It is not allowed to use AI in an autonomous-looking way to contribute in Forgejo. This also applies when someone engages in 'vibe coding' or uses so-called 'agent mode'.
Re: Forgejo <=16.0.3 Critical RCE
#69Earlier quoted context omitted.
That is about Codeberg, not Forgejo. Forgejo disallows LLM contributions, including using a "general AI" (they include LLMs under "general AI") for reviews[0]: > 5. Using general AI for review is forbidden. If the change contains changes to the UX it has to be approved by a human reviewer. [0] https://codeberg.org/forgejo/governance/src/branch/main/AIAg...
Ah sorry, didn't realize they had their own policy. This is a little stronger, but you can certainly still use an LLM to search for vulnerabilities, you would just need to write fixes yourself and mention if you used an LLM for assistance. The rule you quoted is about code reviews, they don't want you using an LLM to write reviews or leave comments. This is a pretty poorly written policy to be honest, so I understand…
Their definition of vibe coding is pretty whacky.
>Vibe coding is the practice where AI creates a code change (feature, bug fix, tests, refactor) with a human that describes what needs to be implemented.
So if you let an AI prompt another AI without human input, that's not vibe coding? Meanwhile if you prompt the model with pseudo code you've written or code written in another programming language to translate into the target language, that's vibe coding?
>It is not allowed to use AI in an autonomous-looking way to contribute in Forgejo.
They used the word "in", meaning it could refer to organizational membership, their repo or theoretically any instance of Forgejo, including self hosted ones. They failed to specify what part of Forgejo or the definition of Forgejo they meant.
Overall this is a pretty poorly written document and when you think about it, it doesn't really matter how poorly written it is when they are basically 100% against AI.
Re: Forgejo <=16.0.3 Critical RCE
#70Wonder how long it took from report to patch. IME codeberg has one of the rudest security teams in oss (fair enough or not, irrelevant). https://news.ycombinator.com/item?id=47941590 Is quite relevant
Forgejo's security team received disclosure of this issue on September 4th. (source: I am a member of that team)
(Thanks for your work!)