> PR: Critical: fix: prevent template expansion from interfering with git repo initialization. When generating a new repository from a template repository, Forgejo clones the template repository, removes the .git folder, performs variable template expansion on files listed in .forgejo/template, and initializes a new git repository. During this process, variable template expansion could be misused in order to create a new .git folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.
Conciser: User's who can create new repositories, can exploit templates to do variable template expansion leading to being able to read arbitrary data from the Forgejo hosts.
If you have open registrations or otherwise users you don't 100% trust with the ability to create new repository (which is the default I think?), they could potentially exploit this and you probably wanna upgrade ASAP.
If you have only trusted users, or single user, seems it's fine. Of course, wanna upgrade anyway to not add escalation paths, but in the other situation it's graver.
> To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.
What happened to sandboxing the offending git invocation?
Only 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.
> Gitea is protected against both of these issues.
Is Gitea's immunity just incidental because it was written by a different person, or is it due to a deliberate defensive system that prevents such bug/mistake from occurring?
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.
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.
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.
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
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.
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 if you interpret it to mean "no LLMs in any capacity", but I think if that's what they meant they would have said that. In fact they explicitly allow content "made with the help of AI", you just have to disclose it.
>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.
Using AI to find a vulnerability is not a work of authorship. Using the AI generated text as your bug report would be, but if you use AI to find a bug, then write up a report yourself, I think that would be fine.
>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"?
Was this discovered by AI? Is all AI code 100% free of bugs?
You are implying that just by allowing LLM contributions your product is free of bugs, and the LLM won't introduce new bugs. Of course, if the LLM introduces bugs, the solution is to add another layer of LLM looking for bugs, ad infinitum.
Another post from today from Shopify, praising LLM to code their frontend, also stated that their LLM generated code is not ready to deploy, and needs to be reviewed:
> It’s tempting to just point an LLM to the React Native codebase and try to one-shot the same features in native, but it doesn’t work. Even if you ask it to gather as much information as it can up front, freeze that into specs, task files, and then implement it, you end up with a huge amount of unmaintainable code that can’t be shipped. [...] each [build] must prove its behavior with tests, match the running app in a visual review, survive two adversarial code reviewers, and get a human's nod before it's committed and the next one starts.
I really disagree with their acceptable usage policy, but you can't say it with certainity that LLM contributions would be a fix for this. They generate so much noise (as the primary incentive behind an independent LLM scan is often cheap contributor brownie points for your CV) that it also could lead to bogus PRs being approved or helpful PRs being lost in the noise.
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'.
Why can't you use an LLM to find vulnerabilities and then hand-code the fix? You don't even have to clean-room implement it; let the LLM write the code, and then reimplement, doing what you can to de-LLM-ify it.
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 defensive and said things like "you'll know if you've crossed the line" and "stop trying to force consent" and similar pearls of wisdom.
The post-facto rationalization did in fact leave them room to judge "quality" on a purely subjective basis. I didn't stick around to find out how that would shake out.
I assume you are implying that LLM generated projects don't mean bad quality. That's true. At same time we all know what this means. Plausibly looking projects that might even work but have little human oversight. There are so many of them It's really difficult to know. I don't want to depend on such code and I bet neither do most programmers. Why? Because by then you might as well vibe the library yourself and be the one who does the oversight.
I might be wrong but I doubt that people on Codeberg are against use of LLMs that make the projects better. Like finding security leaks. What these rules are aimed at are hosting of endless vibe coded projects that are just copy of each other.
I would encourage you to go back and read what was said at the time. Yes, a significant probably-majority really are against the use of LLMs for anything and the policy was evidently not about a deluge of vibe-slop on the site. Because there was a much simpler answer for that: quotas, specific rules, specific policy, moderation.
Instead a vaguely worded policy was put in around the tools used to write code so that vibe-based judgement could sit and decide without the potential judged having recourse to any appeal. And requests for specificity were not just turned down but mocked. Because the intent was to leave it open so that a process of bullying could be put in place.
Basically, anti-democratic practices masquerading as community/democracy. I used to see this a lot back when I was involved more heavily in left wing activist groups and it was the sign of a declining and degraded community. Sad to see it here.
As for "I assume you are implying that LLM generated projects don't mean bad quality. That's true." I'm specifically saying LLM assisted/generated doesn't mean one way or the other. They're tools.
I love you being heavily involved in left wing activist groups but you are no more because they are anti-democratic. When was that? While you were working at google for 10 years? I think you might be in same situation like atleast third of the people here. Yes Codeberg members did undemocratic poll and they undemocratically voted for this anti LLM policy. I fully agree the left wing of the Codeberg is coopting their project and we should go to support much more democratic Github.
You don't and that's why everyone gets so angry and annoyed when people try to force precise definitions.
There's no team of lawyers verifying the provenance of all code/projects submitted to codeberg. THe policy is just something they can point to as a general guidelines of what kind of shit they want to support.
Everyone knows exactly what kind of projects they're talking about. The people trying to nitpick definitions are those annoying ass people at the board game night that spend half the time combing through the rule book trying to figure out why whatever they didn't like was against the rules.
What the folks involved were actually saying, and what let slip multiple times through all those threads is: Any use of the tool is Wrong(tm). They never meant anything by the "majority" or "vibe-coded" or whatever because they didn't need to or want to; Multiple people let slip in all sorts of forums what the intent was: define a policy ambiguous enough that it could be used for frankly vibe-based exclusion. Defining the terms of exclusion was deliberately avoided because a) if-you-know-you-know b) they wanted to reserve the freedom to sit in judgement.
That's fine for new projects. Their sandbox and they can decide who plays in it. But the people who were using codeberg for months or even years and relying on it, and had to move... deserved better treatment.
Fomr my eyes the questions about what defines "majority" were well-intention-ed queries with the motive of trying to ferret out what the criterion for was in the eyes of the people who proposed the vote. That they refused to answer, and cast aspersions on the people who asked... is both a damning judgement on their personal character but also their community management.
What we have is a community defining an in-group and an out-group. And just like middle school, "you'll just know" if you're in one or the other.,
Good grief. What a bizarre cultish echo chamber. The tools make you dirty. Don't touch the tools.
Why put words in their mouth? They clearly mean a majority. They don't want projects that are majority written by LLMs. If they didn't want projects that an LLM had ever been anywhere near, they would've just said that. They're not under any shareholder pressure to lie.
And now you're literally saying that a "no vibecoded projects" rule is a slippery slope to actual fascism. Good grief! What nonsense!
*Critical:* fix: prevent template expansion from interfering with git repo initialization. When generating a new repository from a template repository, Forgejo clones the template repository, removes the `.git` folder, performs variable template expansion on files listed in `.forgejo/template`, and initializes a new git repository. During this process, variable template expansion could be misused in order to create a new `.git` folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing `.git` folder is removed from the directory before the git repository is initialized.
ensure authorization reducer is accessed when checking editable PRs in APIs. When editing a git repo contents through Forgejo's API, a specialized security control is used to permit repository maintainers to edit branches that they do not own when an open pull request with the "allow maintainer edit" option is present. This specialized security control did not take into account API-specific security restrictions, such as repo-specific access tokens. As a result, it was possible for an API access token with restricted permission to make modifications outside of that restricted permission. The specialized security control has been updated to take into account API authentication security restrictions.
---
So if like me you run a private forgejo instance with closed signups and limited repository creation, you can wait for the update. Otherwise maybe take it off the public internet for a bit?
Our forgejo instance got affected by this. I saw the news and thought we don't need to upgrade (yet), as registration is closed for new users, and users having access is only those we control.
As it turns out, when in app.ini we have DISABLE_REGISTRATION = true, it doesn't actually disable registration...
Even though no sign in or sign up form was rendered, the attacker used openid registration
attacker created a fake openid server, registered this way, created like 100+ repositories, was able to create a superadmin account on forgejo, mint tokens, execute commands from the runner trying to escalate permissions - either via git hooks, or in runner itself. Luckily our runner was running on a separate isolated server, but potential damage could have been much worse.
So yeah, everyone update ASAP if you don't want to spend half a day fixing the consequences (:
Security bug fixes
PR: Critical: fix: prevent template expansion from interfering with git repo initialization. When generating a new repository from a template repository, Forgejo clones the template repository, removes the .git folder, performs variable template expansion on files listed in .forgejo/template, and initializes a new git repository. During this process, variable template expansion could be misused in order to create a new .git folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.
```
This git endpoint is seeing a high influx of requests for this repository, to preserve the availability of Codeberg your search request will not be processed. Sorry for the inconvenience and please try again later.
```
Critical: fix: prevent template expansion from interfering with git repo initialization. When generating a new repository from a template repository, Forgejo clones the template repository, removes the .git folder, performs variable template expansion on files listed in .forgejo/template, and initializes a new git repository. During this process, variable template expansion could be misused in order to create a new .git folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.
// 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")
}
Why the `err` isn't carried by the error message? For security? Then maybe log it internally?
User/operator can't really fix the problem if you keep giving them information this vague.
Wonder 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
Is that linked submission "your experience" or is there something else you're basing that on? Because that article you linked is kind of strange, read through the comments on what you linked.
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.
Bruh sorry, stop running any RW services off an SD card, it has always been terrible and unfortunately it will remain terrible, you can buy a used SFF with >5x the compute and a sata ssd for the same price as a raspberry pi alternatively put an nvme hat on it
This vulnerability, which doesn’t affect my installation, would take approximately 5 minutes to patch if it did. With that exception, my server will have had approximately 99.999% uptime over the last several years.
It would take a boatload of such events to equal the opex of GitHub hosting. That’s not an excuse to run amok, but it’s far from tipping the scales in GitHub’s cost favor.
Wouldn't most users considering or using Forgejo also have considered (or used) self-hosted Gitlab which would have the same opex / security costs (and much higher hardware requirements)?
Quick note that this is not an RCE in the typical sense that I can rock up to a Forgejo installation and execute code on the server. The attack vector here is via a template repo specified when initializing a new repo. The template repo could contain malicious code that then executes on the host server. So if you don't create new repos from mystery meat template repos, you should be ok.
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 that says that it must be sent from unauthenticated connection.
>So if you don't create new repos from mystery meat template repos, you should be ok.
You should be OK, but if attacker takes over your user (or any user in your forgejo instance) they can execute code on the host server - as you said yourself. In other words, it allows them to achieve remote code execution, so it's a RCE.
They also have a releases RSS feed. I have those in my mail client (Thunderbird) directly for the projects that I must closely follow critical updates of.
What does the error message mean by "Your search request"? Why is viewing a single file in a repository considered a search request? That smells like poor caching somewhere
This is why I prefer simpler setups for personal use/hosting. Something like cgit that has no accounts has much less surface area for this kind of issue.
As I said before for patching vulnerabilities in the age of AI [0], attackers are going to build exploits around this RCE with AI or even find more flaws with AI.
This means you have no choice but to use AI to defend, find and patch these flaws before attackers quickly build and use these exploits to target users.
You cannot afford to disallow or have a 100% ban on LLM contributions while attackers do not care and will use AI to find the flaws and attack you faster than you can triage it.
Trying 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.
You should change the URL to https://codeberg.org/forgejo/forgejo/milestone/139655
> PR: Critical: fix: prevent template expansion from interfering with git repo initialization. When generating a new repository from a template repository, Forgejo clones the template repository, removes the .git folder, performs variable template expansion on files listed in .forgejo/template, and initializes a new git repository. During this process, variable template expansion could be misused in order to create a new .git folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.
Conciser: User's who can create new repositories, can exploit templates to do variable template expansion leading to being able to read arbitrary data from the Forgejo hosts.
If you have open registrations or otherwise users you don't 100% trust with the ability to create new repository (which is the default I think?), they could potentially exploit this and you probably wanna upgrade ASAP.
If you have only trusted users, or single user, seems it's fine. Of course, wanna upgrade anyway to not add escalation paths, but in the other situation it's graver.
> To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.
What happened to sandboxing the offending git invocation?
Only 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.
> Gitea is protected against both of these issues.
Is Gitea's immunity just incidental because it was written by a different person, or is it due to a deliberate defensive system that prevents such bug/mistake from occurring?
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.
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/
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.
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
Apologies I didn't see there had been a CVE. I completely retract my statement.
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.
Agreed, I didn't realise there had been a CVE.
Forgejo is a fork of gitea.
Hence the question...
Your note is really important! Thanks for adding it. None of us are perfect.
If you upgraded from < 1.25.5
This 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.
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...
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 if you interpret it to mean "no LLMs in any capacity", but I think if that's what they meant they would have said that. In fact they explicitly allow content "made with the help of AI", you just have to disclose it.
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.
> Forgejo disallows LLM contributions
You're misreading the rule.
>> 5. Using general AI for review is forbidden.
The second sentence makes it even clearer, as it would have been unnecessary under a blanket ban scenario
>> ... If the change contains changes to the UX it has to be approved by a human reviewer.
This looks unambiguous to me:
Using AI to find a vulnerability is not a work of authorship. Using the AI generated text as your bug report would be, but if you use AI to find a bug, then write up a report yourself, I think that would be fine.
>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"?
Was this discovered by AI? Is all AI code 100% free of bugs?
You are implying that just by allowing LLM contributions your product is free of bugs, and the LLM won't introduce new bugs. Of course, if the LLM introduces bugs, the solution is to add another layer of LLM looking for bugs, ad infinitum.
Another post from today from Shopify, praising LLM to code their frontend, also stated that their LLM generated code is not ready to deploy, and needs to be reviewed:
> It’s tempting to just point an LLM to the React Native codebase and try to one-shot the same features in native, but it doesn’t work. Even if you ask it to gather as much information as it can up front, freeze that into specs, task files, and then implement it, you end up with a huge amount of unmaintainable code that can’t be shipped. [...] each [build] must prove its behavior with tests, match the running app in a visual review, survive two adversarial code reviewers, and get a human's nod before it's committed and the next one starts.
> You are implying that just by allowing LLM contributions your product is free of bugs
That... is not the implication of the comment you're replying to.
You don't need to make it all fundamentalist.
> They may not use AI to *check for vulnerabilities*
you didn't read the comment, did you?
I really disagree with their acceptable usage policy, but you can't say it with certainity that LLM contributions would be a fix for this. They generate so much noise (as the primary incentive behind an independent LLM scan is often cheap contributor brownie points for your CV) that it also could lead to bogus PRs being approved or helpful PRs being lost in the noise.
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'.
Why can't you use an LLM to find vulnerabilities and then hand-code the fix? You don't even have to clean-room implement it; let the LLM write the code, and then reimplement, doing what you can to de-LLM-ify it.
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 defensive and said things like "you'll know if you've crossed the line" and "stop trying to force consent" and similar pearls of wisdom.
The post-facto rationalization did in fact leave them room to judge "quality" on a purely subjective basis. I didn't stick around to find out how that would shake out.
I assume you are implying that LLM generated projects don't mean bad quality. That's true. At same time we all know what this means. Plausibly looking projects that might even work but have little human oversight. There are so many of them It's really difficult to know. I don't want to depend on such code and I bet neither do most programmers. Why? Because by then you might as well vibe the library yourself and be the one who does the oversight.
I might be wrong but I doubt that people on Codeberg are against use of LLMs that make the projects better. Like finding security leaks. What these rules are aimed at are hosting of endless vibe coded projects that are just copy of each other.
I would encourage you to go back and read what was said at the time. Yes, a significant probably-majority really are against the use of LLMs for anything and the policy was evidently not about a deluge of vibe-slop on the site. Because there was a much simpler answer for that: quotas, specific rules, specific policy, moderation.
Instead a vaguely worded policy was put in around the tools used to write code so that vibe-based judgement could sit and decide without the potential judged having recourse to any appeal. And requests for specificity were not just turned down but mocked. Because the intent was to leave it open so that a process of bullying could be put in place.
Basically, anti-democratic practices masquerading as community/democracy. I used to see this a lot back when I was involved more heavily in left wing activist groups and it was the sign of a declining and degraded community. Sad to see it here.
As for "I assume you are implying that LLM generated projects don't mean bad quality. That's true." I'm specifically saying LLM assisted/generated doesn't mean one way or the other. They're tools.
I love you being heavily involved in left wing activist groups but you are no more because they are anti-democratic. When was that? While you were working at google for 10 years? I think you might be in same situation like atleast third of the people here. Yes Codeberg members did undemocratic poll and they undemocratically voted for this anti LLM policy. I fully agree the left wing of the Codeberg is coopting their project and we should go to support much more democratic Github.
Do you expect it to be enforced by a machine? Why would you need a precise definition of "majority"?
You don't and that's why everyone gets so angry and annoyed when people try to force precise definitions.
There's no team of lawyers verifying the provenance of all code/projects submitted to codeberg. THe policy is just something they can point to as a general guidelines of what kind of shit they want to support.
Everyone knows exactly what kind of projects they're talking about. The people trying to nitpick definitions are those annoying ass people at the board game night that spend half the time combing through the rule book trying to figure out why whatever they didn't like was against the rules.
That's why they say they don't need an AI detector and that anyone who complains about the rule is guilty.
Ordinarily that's a bad way to run a rule. But not this time!
What the folks involved were actually saying, and what let slip multiple times through all those threads is: Any use of the tool is Wrong(tm). They never meant anything by the "majority" or "vibe-coded" or whatever because they didn't need to or want to; Multiple people let slip in all sorts of forums what the intent was: define a policy ambiguous enough that it could be used for frankly vibe-based exclusion. Defining the terms of exclusion was deliberately avoided because a) if-you-know-you-know b) they wanted to reserve the freedom to sit in judgement.
That's fine for new projects. Their sandbox and they can decide who plays in it. But the people who were using codeberg for months or even years and relying on it, and had to move... deserved better treatment.
Fomr my eyes the questions about what defines "majority" were well-intention-ed queries with the motive of trying to ferret out what the criterion for was in the eyes of the people who proposed the vote. That they refused to answer, and cast aspersions on the people who asked... is both a damning judgement on their personal character but also their community management.
What we have is a community defining an in-group and an out-group. And just like middle school, "you'll just know" if you're in one or the other.,
Good grief. What a bizarre cultish echo chamber. The tools make you dirty. Don't touch the tools.
Why put words in their mouth? They clearly mean a majority. They don't want projects that are majority written by LLMs. If they didn't want projects that an LLM had ever been anywhere near, they would've just said that. They're not under any shareholder pressure to lie.
And now you're literally saying that a "no vibecoded projects" rule is a slippery slope to actual fascism. Good grief! What nonsense!
You can, though some people are going to be annoyed by it and just publish a zero day out of spite.
Since the release notes is currently unreadable due to codeberg rate limits, the two fixes in the release notes are:
https://codeberg.org/forgejo/forgejo/pulls/14301:
*Critical:* fix: prevent template expansion from interfering with git repo initialization. When generating a new repository from a template repository, Forgejo clones the template repository, removes the `.git` folder, performs variable template expansion on files listed in `.forgejo/template`, and initializes a new git repository. During this process, variable template expansion could be misused in order to create a new `.git` folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing `.git` folder is removed from the directory before the git repository is initialized.
https://codeberg.org/forgejo/forgejo/pulls/14301:
ensure authorization reducer is accessed when checking editable PRs in APIs. When editing a git repo contents through Forgejo's API, a specialized security control is used to permit repository maintainers to edit branches that they do not own when an open pull request with the "allow maintainer edit" option is present. This specialized security control did not take into account API-specific security restrictions, such as repo-specific access tokens. As a result, it was possible for an API access token with restricted permission to make modifications outside of that restricted permission. The specialized security control has been updated to take into account API authentication security restrictions.
---
So if like me you run a private forgejo instance with closed signups and limited repository creation, you can wait for the update. Otherwise maybe take it off the public internet for a bit?
Our forgejo instance got affected by this. I saw the news and thought we don't need to upgrade (yet), as registration is closed for new users, and users having access is only those we control. As it turns out, when in app.ini we have DISABLE_REGISTRATION = true, it doesn't actually disable registration... Even though no sign in or sign up form was rendered, the attacker used openid registration
as in our config I had
[openid] ENABLE_OPENID_SIGNIN = true ENABLE_OPENID_SIGNUP = true
attacker created a fake openid server, registered this way, created like 100+ repositories, was able to create a superadmin account on forgejo, mint tokens, execute commands from the runner trying to escalate permissions - either via git hooks, or in runner itself. Luckily our runner was running on a separate isolated server, but potential damage could have been much worse.
So yeah, everyone update ASAP if you don't want to spend half a day fixing the consequences (:
Relevant change:
It looks like this is a bit less concerning if you have turned off open account registration.
``` This git endpoint is seeing a high influx of requests for this repository, to preserve the availability of Codeberg your search request will not be processed. Sorry for the inconvenience and please try again later. ```
Any mirror?
The PR is still accessible https://codeberg.org/forgejo/forgejo/pulls/14300
I'm just reading the code here:
Why the `err` isn't carried by the error message? For security? Then maybe log it internally?User/operator can't really fix the problem if you keep giving them information this vague.
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...
Wonder 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!)
Is that linked submission "your experience" or is there something else you're basing that on? Because that article you linked is kind of strange, read through the comments on what you linked.
The 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.
Bruh sorry, stop running any RW services off an SD card, it has always been terrible and unfortunately it will remain terrible, you can buy a used SFF with >5x the compute and a sata ssd for the same price as a raspberry pi alternatively put an nvme hat on it
This vulnerability, which doesn’t affect my installation, would take approximately 5 minutes to patch if it did. With that exception, my server will have had approximately 99.999% uptime over the last several years.
It would take a boatload of such events to equal the opex of GitHub hosting. That’s not an excuse to run amok, but it’s far from tipping the scales in GitHub’s cost favor.
Yep. I have one hanging off an openbsd machine on a tailnet, took me like... 5 minutes to update it, and it's not exactly a common setup...
Wouldn't most users considering or using Forgejo also have considered (or used) self-hosted Gitlab which would have the same opex / security costs (and much higher hardware requirements)?
Checkout Gisia https://github.com/gisiahq/gisia
I alluded to business needs, not homelabs. Even-so, GitLab has a helmchart while Forgejo doesn't and is seemingly more secure so idk.
Quick note that this is not an RCE in the typical sense that I can rock up to a Forgejo installation and execute code on the server. The attack vector here is via a template repo specified when initializing a new repo. The template repo could contain malicious code that then executes on the host server. So if you don't create new repos from mystery meat template repos, you should be ok.
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 that says that it must be sent from unauthenticated connection.
Would be good to label it "authenticated RCE" to make this clear
>So if you don't create new repos from mystery meat template repos, you should be ok.
You should be OK, but if attacker takes over your user (or any user in your forgejo instance) they can execute code on the host server - as you said yourself. In other words, it allows them to achieve remote code execution, so it's a RCE.
If you are self-hosting Forgejo and haven't done it yet, consider creating a Codeberg account and following https://codeberg.org/forgejo/security-announcements/issues
Updates also posted to #forgejo-chat:matrix.org channel.
They also have a releases RSS feed. I have those in my mail client (Thunderbird) directly for the projects that I must closely follow critical updates of.
What does the error message mean by "Your search request"? Why is viewing a single file in a repository considered a search request? That smells like poor caching somewhere
This is why I prefer simpler setups for personal use/hosting. Something like cgit that has no accounts has much less surface area for this kind of issue.
Removing .git after expansion seems fragile. Sandboxing the git step would close the whole class of bugs.
Can't load the page but hopefully it's on an endpoint sitting behind my Tinyauth protection.
Glad I have my Forgejo service set to auto update.
As I said before for patching vulnerabilities in the age of AI [0], attackers are going to build exploits around this RCE with AI or even find more flaws with AI.
This means you have no choice but to use AI to defend, find and patch these flaws before attackers quickly build and use these exploits to target users.
You cannot afford to disallow or have a 100% ban on LLM contributions while attackers do not care and will use AI to find the flaws and attack you faster than you can triage it.
[0] https://news.ycombinator.com/item?id=49262849
If nothing else having AI review anything security related may be a good idea.
I'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 <16.0.4 RCE via crafted template repository (.forgejo/template expansion recreates .git folder adopted by git init)
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
Trying 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...
https://codeberg.org/Codeberg/Community/issues/3084
[dead]
[flagged]