It's very much "I know better, do what I told you despise not thinking a second about any second order effects the change might cause" attitude that is so common with security people
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.
A cryptographer friend tells the story of an amateur who kept bothering him with the cipher he invented. The cryptographer would break the cipher, the amateur would make a change to “fix” it, and the cryptographer would break it again. This exchange went on a few times until the cryptographer became fed up. When the amateur visited him to hear what the cryptographer thought, the cryptographer put three envelopes face down on the table. “In each of these envelopes is an attack against your cipher. Take one and read it. Don’t come back until you’ve discovered the other two attacks.” The amateur was never heard from again.
The author quite clearly outlines their reasoning for this in the article:
> Carrot Disclosure, dangling a metaphorical carrot in front of the vendor to incentivise change. The main idea is to only publish the (redacted) output of the exploit for a critical vulnerability, to showcase that the software is exploitable. Now the vendor has two choices: either perform a holistic audit of its software, fixing as many issues as possible in the hope of fixing the showcased vulnerability; or losing users who might not be happy running a known-vulnerable software. Users of this disclosure model are of course called Bugs Bunnies.
In the age of AI, carrot disclosure is potentially a full disclosure with extra steps. I'm no security expert, but with the context provided, the forgejo codebase and the outline of the redacted script, I think there is a good chance I could use codex to crunch through the vuln chain and reproduce the script.
> Failure to comply with these rules will be criticized publicly, and we reserve the right to no longer coordinate with you or your project in the future.
From a linked PR (related to this RCE?), from a maintainer who closed it:
>Just thinking something not being used is not enough, even if it's a security sensitive topic
Linux kernel seems to disagree. This is a dangerously naive way to think of networked software in the AI age.
---
edit: I got hit with the "posting too fast" block again, so I'll reply to dangus here:
>While a remote host would further prove the claim, the person clearly claims it is RCE, not just CE. It would be quite the pie in the face if the author wrote a python script to take in an IP address but modified system files on the backend to create a stunt.
It would definitely be a bit silly for the author to make a fake carrot disclosure, but I thought of it just because of how reading this article made me feel distrust toward the author. IDK, they just seem like kind of a jerk!
Now, I don't think the PRs with the Forgejo folks show a lot of warm collaborative energy on their side, either, but I can see how soft skills from the author would likely have taken their PRs a lot further in getting what they want.
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.
> 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.
> It sounds like it has some security vulnerabilities that the maintainers aren't taking seriously
It may, and they may or may not, but the author hasn't actually reported any. They're explicitly ignoring the security policy and vagueposting instead.
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!
The author's attitude is so off-putting. What gives? Did Forgejo hurt you?
The Forgejo disclosure process looked pretty simple and straightforward to me. The bold and all-caps words that bothered the author are just making sure you know how to disclose vulnerabilities safely without leaking zero-day exploits to a wider audience than necessary.
I'm also not impressed with a carrot disclosure that looks like this. Running a python script to compromise a locally hosted instance? Bruh, you have physical hardware and host shell access. That python script could be doing anything including running as root.
> I'm also not impressed with a carrot disclosure that looks like this. Running a python script to compromise a locally hosted instance? Bruh, you have physical hardware and host shell access. That python script could be doing anything including running as root.
> Show us the exploit hitting a remote server.
Watch out, their script works on HN too, as a proof here's me logging in to YOUR computer's root account (a bit more redacted for obvious reasons):
$ python3 ./poc/chain_alpha.py --target dangus > out.txt
$ grep Backdoor out.txt | sed -r 's@[^:]+$@ [REDACTED]@g'
[+] Backdoor admin created: [REDACTED]
$ grep IP out.txt | sed -r 's@[^:]+$@ [REDACTED]@g'
[+] IPv4 address for dangus: [REDACTED]
$ grep 'debug2: shell' out.txt
[+] debug2: shell request accepted on channel 0
$ tail -n12 out.txt
================================================================
[+] COMMAND EXECUTION CONFIRMED!
================================================================
Server-side output (received via SSH, with `set -x`):
+ id -u
0
+ id -g
0
================================================================
$ sha256 ./poc/chain_alpha.py
c10d28a5ff74646683953874b035ca6ba56742db2f95198b54e561523e1880d7 ./poc/chain_alpha.py
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.
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.
This is a weird post to be honest. You've found a whole bunch of serious security issues, filed two PRs, one of which is adding some quotes because
> Those aren't exploitable XSS, but it doesn't hurt to have a second layer of defense.
The other suggests breaking clients that aren't using the more secure version of an OAuth method because
> I can't think of any OAuth client that would like to [use it]
That second one is a good idea, but the maintainer is also right to ask for some discussion before introducing a breaking change.
But crucially: neither of these are the kind of significant security issues you've found. Maybe lead with an actual bug?
> That second one is a good idea, but the maintainer is also right to ask for some discussion before introducing a breaking change.
The discussion seems to be already happening https://codeberg.org/forgejo/forgejo/issues/8634, author of the blog just did drive-by PR rather than looking at issue tracker
It's very much "I know better, do what I told you despise not thinking a second about any second order effects the change might cause" attitude that is so common with security people
I believe the discussion in #8634 is for a different change, but one of a similar nature.
Closing the PR without providing feedback beyond "needs further discussion" does not engender said further discussion.
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.
There’s an old cryptography story.
A cryptographer friend tells the story of an amateur who kept bothering him with the cipher he invented. The cryptographer would break the cipher, the amateur would make a change to “fix” it, and the cryptographer would break it again. This exchange went on a few times until the cryptographer became fed up. When the amateur visited him to hear what the cryptographer thought, the cryptographer put three envelopes face down on the table. “In each of these envelopes is an attack against your cipher. Take one and read it. Don’t come back until you’ve discovered the other two attacks.” The amateur was never heard from again.
https://www.schneier.com/crypto-gram/archives/1998/1015.html
And if you are a dishonest cryptographer, you only need to find one attack to pull this off.
This entire post reads as rage bait. They’re mad because Forgejo has … a process? And what are these vulnerabilities, concretely?
> But given the sorry state of the codebase
I honesty want a refund on the 10 minutes I wasted reading this.
Did the author actually disclose this RCE or just open random PRs and claim there's an issue?
It doesn't appear like the author is acting in good faith, instead grandstanding in public because they feel superior.
The author quite clearly outlines their reasoning for this in the article:
> Carrot Disclosure, dangling a metaphorical carrot in front of the vendor to incentivise change. The main idea is to only publish the (redacted) output of the exploit for a critical vulnerability, to showcase that the software is exploitable. Now the vendor has two choices: either perform a holistic audit of its software, fixing as many issues as possible in the hope of fixing the showcased vulnerability; or losing users who might not be happy running a known-vulnerable software. Users of this disclosure model are of course called Bugs Bunnies.
In the age of AI, carrot disclosure is potentially a full disclosure with extra steps. I'm no security expert, but with the context provided, the forgejo codebase and the outline of the redacted script, I think there is a good chance I could use codex to crunch through the vuln chain and reproduce the script.
Where's the vuln chain? Is it even obvious which APIs have been called?
Hopefully someone a little more.. pragmatic gets eyes on that linked PR.
https://codeberg.org/forgejo/governance/src/commit/5c07b3801...
> Failure to comply with these rules will be criticized publicly, and we reserve the right to no longer coordinate with you or your project in the future.
lol
I could totally imagine this kind of thing being added due to AI-slop security report overload, like curl was experiencing[1].
[1]: https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s...
From a linked PR (related to this RCE?), from a maintainer who closed it:
>Just thinking something not being used is not enough, even if it's a security sensitive topic
Linux kernel seems to disagree. This is a dangerously naive way to think of networked software in the AI age.
---
edit: I got hit with the "posting too fast" block again, so I'll reply to dangus here:
>While a remote host would further prove the claim, the person clearly claims it is RCE, not just CE. It would be quite the pie in the face if the author wrote a python script to take in an IP address but modified system files on the backend to create a stunt.
It would definitely be a bit silly for the author to make a fake carrot disclosure, but I thought of it just because of how reading this article made me feel distrust toward the author. IDK, they just seem like kind of a jerk!
Now, I don't think the PRs with the Forgejo folks show a lot of warm collaborative energy on their side, either, but I can see how soft skills from the author would likely have taken their PRs a lot further in getting what they want.
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.
> 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.
> It sounds like it has some security vulnerabilities that the maintainers aren't taking seriously
It may, and they may or may not, but the author hasn't actually reported any. They're explicitly ignoring the security policy and vagueposting instead.
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!
Don’t forget, repeatedly ignoring the requirements for including tests, and instead offering up a “have tested it locally, trust me” as a substitute.
The worry here is that they need to leave the security hole open because they're using it?
The author's attitude is so off-putting. What gives? Did Forgejo hurt you?
The Forgejo disclosure process looked pretty simple and straightforward to me. The bold and all-caps words that bothered the author are just making sure you know how to disclose vulnerabilities safely without leaking zero-day exploits to a wider audience than necessary.
I'm also not impressed with a carrot disclosure that looks like this. Running a python script to compromise a locally hosted instance? Bruh, you have physical hardware and host shell access. That python script could be doing anything including running as root.
Show us the exploit hitting a remote server.
> I'm also not impressed with a carrot disclosure that looks like this. Running a python script to compromise a locally hosted instance? Bruh, you have physical hardware and host shell access. That python script could be doing anything including running as root.
> Show us the exploit hitting a remote server.
Watch out, their script works on HN too, as a proof here's me logging in to YOUR computer's root account (a bit more redacted for obvious reasons):
Seriously, this author comes across as an absolute sore loser if this is the PR they are referring too:
https://codeberg.org/forgejo/forgejo/pulls/12283
Someone asking you to write a test for new code and then making this blog in response is just so pathetic.
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.
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.
> 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"
That totally justifies the very normal extortion like blog post in response.