I quickly found CVE-2026-60004, a recently-disclosed RCE vulnerability in Gitea, upon which Forgejo is based
This is a CVE related to gitea, I realize forgejo might be related, but I feel like this should have its own CVE for forgejo as well.
I just put up my own forgejo instance yesterday so seeing this news that their forgejo instance got popped doesn't make me feel great. As a result of this, I subscribed to the rss feed available on https://codeberg.org/forgejo/security-announcements/issues which should at least notify me of when I need to patch something.
MUST assign different CVE IDs if the products do not share affected code.
So I guess it depends on whether a hard fork is considered as sharing affected code. Maybe forgejo still has enough code in common where it's still considered as sharing code?
I couldn't find any clarification by what they mean by "sharing code" in regards to hard forks, so I guess it's open to interpretation.
My lab network is hardwired and has no direct route to the Internet. Anything that wants out has to go through a proxy (and anything that wants in has to go through the reverse proxy or the bastion host).
This seems like a good idea for vintage computers (as you well know!). When you say “proxy” do you mean an HTTP proxy? Or something more generic?
I’d like to hear more, because my current approach is to keep my vintage computers either completely isolated or restricted to my VPN only. But requesting HTML from sites I trust should be fine (and probably even fun!).
HTTP, HTTPS-over-HTTP (Crypto Ancienne), and SOCKS proxies, yes. DNS is also served on the inside with overrides as necessary, and I have my own NTP stratum 1 server inside as well (gets time from GPS). Of course, it also helps that most of them have alien architectures most botnet creeps are probably not old enough to remember, let alone build for.
it also helps that most of them have alien architectures most botnet creeps are probably not old enough to remember, let alone build for.
If someone were to deploy a botnet runner compiled for DOS on i486 on my retro computer, I'd probably consider keeping it running just out of sheer respect.
Nice write-up! This feels like a pretty typical homelab setup, I assume this thing happens a lot. I'd love to read more of them!
I think we all recognise our homelabs aren't that secure, and as the author notes, there's things that could be done, but some at the cost of lots of complexity.
The good news is that it looks like the impact of this was pretty low. Thanks to cryptojacking that "high CPU" alerts are now a low-cost way to be alerted of running vulnerable software. I hear some cryptojackers patch CVEs too. "Friendly gut bacteria".
The author is lucky that this didn't happen at the same time as one of the many recent local root exploits.
Forgejo can store secrets for CI runners and that's often a reason someone chooses to self-host, so I'm curious if the author's CI was privileged in this way.
Unfortunately, Forgejo only offers versioned image tags, meaning no latest tag. I still had mine pinned to v13 which reached EOL 6 months ago in January, 2026.
[...]
I'm trying to K.I.S.S. (Keep It Simple, Stupid) in my homelab.
I think "only expose services that have automated security updates" is a useful KISS invariant. It rejects a lot of software though. https://lobste.rs/s/21lrrw/gitolite discusses lighter git options.
I don't trust applications to not have endpoints that are weakly authenticated, and have exploits, so another invariant I like for exposed services is "all requests are authenticated" by an authenticating proxy. For me that's Caddy (mTLS or basic auth), oauth2-proxy, or OpenSSH, depending on the application.
I make an exception here for "unauthenticated read-only services" like static web servers.
That said, I don't have much on my homelab due to these invariants. There's something to be said for KISS by ignoring all of the above. :)
It's so much easier to set up auth once around your reverse proxy too. That's been our choice for years. It also lets you do things like optionally share a single login session across multiple services; and just gate the access via permissions. Helps be a little less lazy (with passwords or session timeouts, etc) when you're not having to login to 4 different services within 5 minutes.
I think "only expose services that have automated security updates" is a useful KISS invariant.
Funnily enough, I suck at keeping stuff up to date, but the one criteria I look at seems to work: How many security issues have something had historically? Gitea, and by extension, Forgejo, have a bit of a reputation for being lousy with high risk vulnerabilities, which is also why I haven't set it up on my own homelab.
I do still keep an eye on CVEs issued against the stuff I run, but most of the case they either require esoteric configurations, or amount to nothing more than party tricks.
You tend to get comfortable around outdated software in a homelab, given that your hardware is most likely EOL to begin with.
I don't trust applications to not have endpoints that are weakly authenticated, and have exploits, so another invariant I like for exposed services is "all requests are authenticated" by an authenticating proxy.
In a way, I feel that I have to place that minimum amount of trust - that things are adequately guarded against unauthenticated attackers - to not be paranoid. If I don't feel like I can trust some application to handle that, I probably shouldn't run that application in the first place. The exception would be if it's well documented by the authors that it doesn't protect against unauthenticated attackers, obviously.
(I do still end up using OIDC integrations to have SSO.)
thomas0 | a day ago
This is a CVE related to gitea, I realize forgejo might be related, but I feel like this should have its own CVE for forgejo as well.
I just put up my own forgejo instance yesterday so seeing this news that their forgejo instance got popped doesn't make me feel great. As a result of this, I subscribed to the rss feed available on https://codeberg.org/forgejo/security-announcements/issues which should at least notify me of when I need to patch something.
val | 9 hours ago
Shouldn't Forgejo be added to the existing CVE instead of creating a new CVE?
thomas0 | 6 hours ago
Hmm I wasn't sure so I looked up the official guidance for CVEs: https://www.cve.org/Resources/Media/Archives/OldWebsite/cve/cna/rules.html
Under 7.2.4.b:
So I guess it depends on whether a hard fork is considered as sharing affected code. Maybe forgejo still has enough code in common where it's still considered as sharing code?
I couldn't find any clarification by what they mean by "sharing code" in regards to hard forks, so I guess it's open to interpretation.
LeahNeukirchen | 5 hours ago
Even worse, Forgejo HEAD seems not to be patched? Can someone confirm this?
thomas0 | 5 hours ago
I believe forgejo 16 and HEAD aren't affected, see https://codeberg.org/forgejo/forgejo/pulls/13705#issuecomment-20666573 for someone that had the same thought.
oliverpool | 3 hours ago
Hi, that's me 😅
Yes, v16 was not affected because hooks were refactored to be stored globally and not duplicated locally for each bare repo.
classichasclass | 17 hours ago
My lab network is hardwired and has no direct route to the Internet. Anything that wants out has to go through a proxy (and anything that wants in has to go through the reverse proxy or the bastion host).
I may be a bit paranoid.
jaredkrinke | 15 hours ago
This seems like a good idea for vintage computers (as you well know!). When you say “proxy” do you mean an HTTP proxy? Or something more generic?
I’d like to hear more, because my current approach is to keep my vintage computers either completely isolated or restricted to my VPN only. But requesting HTML from sites I trust should be fine (and probably even fun!).
classichasclass | 15 hours ago
HTTP, HTTPS-over-HTTP (Crypto Ancienne), and SOCKS proxies, yes. DNS is also served on the inside with overrides as necessary, and I have my own NTP stratum 1 server inside as well (gets time from GPS). Of course, it also helps that most of them have alien architectures most botnet creeps are probably not old enough to remember, let alone build for.
DustyFuzzy | 6 hours ago
If someone were to deploy a botnet runner compiled for DOS on i486 on my retro computer, I'd probably consider keeping it running just out of sheer respect.
tuxes | 20 hours ago
Nice write-up! This feels like a pretty typical homelab setup, I assume this thing happens a lot. I'd love to read more of them!
I think we all recognise our homelabs aren't that secure, and as the author notes, there's things that could be done, but some at the cost of lots of complexity.
The good news is that it looks like the impact of this was pretty low. Thanks to cryptojacking that "high CPU" alerts are now a low-cost way to be alerted of running vulnerable software. I hear some cryptojackers patch CVEs too. "Friendly gut bacteria".
The author is lucky that this didn't happen at the same time as one of the many recent local root exploits.
Forgejo can store secrets for CI runners and that's often a reason someone chooses to self-host, so I'm curious if the author's CI was privileged in this way.
I think "only expose services that have automated security updates" is a useful KISS invariant. It rejects a lot of software though. https://lobste.rs/s/21lrrw/gitolite discusses lighter git options.
Forgejo v13 received security updates for 4 months. I see the LTS gets updates for ~16 months. Perhaps a safer bet if someone needs Forgejos featureset. https://forgejo.org/docs/latest/admin/release-schedule/
I don't trust applications to not have endpoints that are weakly authenticated, and have exploits, so another invariant I like for exposed services is "all requests are authenticated" by an authenticating proxy. For me that's Caddy (mTLS or basic auth), oauth2-proxy, or OpenSSH, depending on the application.
I make an exception here for "unauthenticated read-only services" like static web servers.
That said, I don't have much on my homelab due to these invariants. There's something to be said for KISS by ignoring all of the above. :)
rileylabrecque | 13 hours ago
It's so much easier to set up auth once around your reverse proxy too. That's been our choice for years. It also lets you do things like optionally share a single login session across multiple services; and just gate the access via permissions. Helps be a little less lazy (with passwords or session timeouts, etc) when you're not having to login to 4 different services within 5 minutes.
oliverpool | 10 hours ago
Yes, if you use the
15tag, you get automatic security updates until EOL in July 2027.https://codeberg.org/forgejo/-/packages/container/forgejo/15
DustyFuzzy | 6 hours ago
Funnily enough, I suck at keeping stuff up to date, but the one criteria I look at seems to work: How many security issues have something had historically? Gitea, and by extension, Forgejo, have a bit of a reputation for being lousy with high risk vulnerabilities, which is also why I haven't set it up on my own homelab.
I do still keep an eye on CVEs issued against the stuff I run, but most of the case they either require esoteric configurations, or amount to nothing more than party tricks.
You tend to get comfortable around outdated software in a homelab, given that your hardware is most likely EOL to begin with.
In a way, I feel that I have to place that minimum amount of trust - that things are adequately guarded against unauthenticated attackers - to not be paranoid. If I don't feel like I can trust some application to handle that, I probably shouldn't run that application in the first place. The exception would be if it's well documented by the authors that it doesn't protect against unauthenticated attackers, obviously.
(I do still end up using OIDC integrations to have SSO.)
drrobotic | 4 hours ago
For my internet facing services i add a prefix to the URL path, to prevent bots finding those, e.g. like https://mydomain.org/xyz/git