31–40 of 97 posts
Woah I wonder if they can tell if this has been exploited or not
edit: I didn't mean it as a put-down of either the article or how they found the vulnerability, but it wasn't a constructive comment either way.
> April 28, 2026 > GitHub Enterprise Server customers should upgrade immediately - at the time of this writing, our data indicates that 88% of instances are still vulnerable > Upgrade to GHES version 3.19.3 or later https://docs.github.com/en/enterprise-server@3.19/admin/rele... : > Enterprise Server 3.19.3 - March 10, 2026 88% of on-prem customers haven't applied a critical security fix from 7 weeks ago, that seems…
They are constantly telling all their GHES customers who complain about the severe flaws with the self-hosted appliance product to move to GitHub Enterprise Cloud, which is just regular GitHub.com, but who in their right mind would make that move nowadays??? At least GHES stays up during the daily github.com outages.
This is just such an amateur hour vulnerability. Gluing strings together with no regard to what might be in them and then parsing them later... edit: I didn't mean it as a put-down of either the article or how they found the vulnerability, but it wasn't a constructive comment either way.
> April 28, 2026 > GitHub Enterprise Server customers should upgrade immediately - at the time of this writing, our data indicates that 88% of instances are still vulnerable > Upgrade to GHES version 3.19.3 or later https://docs.github.com/en/enterprise-server@3.19/admin/rele... : > Enterprise Server 3.19.3 - March 10, 2026 88% of on-prem customers haven't applied a critical security fix from 7 weeks ago, that seems…
GHES is essentially unmaintained (perhaps “on life support” would be more charitable since they are certainly accepting payment for it) and has been so for about a decade. It requires a multi-hour downtime to apply even a patch-level release. They do not have any supported mechanism for HA upgrades. So even the most conscientious GHES customers lag the latest version because they can’t afford the downtime. They are c…
It's still a pretty annoying process, though.
Earlier quoted context omitted.
GHES is essentially unmaintained (perhaps “on life support” would be more charitable since they are certainly accepting payment for it) and has been so for about a decade. It requires a multi-hour downtime to apply even a patch-level release. They do not have any supported mechanism for HA upgrades. So even the most conscientious GHES customers lag the latest version because they can’t afford the downtime. They are c…
You can at least schedule the updates. It's still a pretty annoying process, though.
Earlier quoted context omitted.
GitLab ?
The people who suggest gitlab, haven't used it. But I guess I could be tempted to try again... https://status.gitlab.com/pages/history/5b36dc6502d06804c083...
Security research historically has two difficult components that build on one another: 1. Understanding complex system internals: uncovering the inner workings hidden by abstractions or interfaces 2. Finding vulnerabilities in these uncovered mechanisms
Sometimes both steps are equally hard. But often, finding the vulnerability is trivial once the real mechanisms are uncovered, rather than relying on assumptions about inner workings.
CVE-2026-3854 is a case where the vulnerability is not plainly obvious after understanding the internals. Still, I am confident that this command injection would have been found quickly had it been exposed to a more traditional or accessible attack surface.
Earlier quoted context omitted.
A "reasonable" answer is probably a primary self-hosted Forgejo instance as the canonical forge, while using GitHub as a mirror solely to take advantage of its free CI, while that lasts, while hosting secrets with a dedicated secret-hosting provider (I don't know what the provider du jour for this is these days).
> solely to take advantage of its free CI, while that lasts Eh, if you want to be able to continue working, deploy and what not as normal during weekdays, I'd suggest also moving to Forgejo Actions if you're moving anyways. Not 100% compatible, but more or less the same, and even paying the same but with dedicated hardware you'd get way faster runners.
For OSS, the unlimited free minutes of multiplatform CI offered by GitHub are literally impossible to replace. Maintaining runners yourself to do the same things would be somewhere between a part- and full-time job.
> April 28, 2026 > GitHub Enterprise Server customers should upgrade immediately - at the time of this writing, our data indicates that 88% of instances are still vulnerable > Upgrade to GHES version 3.19.3 or later https://docs.github.com/en/enterprise-server@3.19/admin/rele... : > Enterprise Server 3.19.3 - March 10, 2026 88% of on-prem customers haven't applied a critical security fix from 7 weeks ago, that seems…
GHES is essentially unmaintained (perhaps “on life support” would be more charitable since they are certainly accepting payment for it) and has been so for about a decade. It requires a multi-hour downtime to apply even a patch-level release. They do not have any supported mechanism for HA upgrades. So even the most conscientious GHES customers lag the latest version because they can’t afford the downtime. They are c…