ZDNET’s key takeaways
- What happened to Alpine Linux can, and has, happened to other groups and companies.
- Simple patching of just one component isn’t enough for true security.
- In these days of constant AI attacks, securing your developer tools has never been more time-critical.
On Oct. 20 and Oct. 21, an attacker tried to exploit the nasty GitLab security vulnerability CVE-2026-97229 on Alpine Linux‘s GitLab instance. Alpine confessed the attack “came close to working” in the release about the incident.
That said, the maintainers found no evidence that it succeeded. Still, they said, “we cannot rule it out, so we treated the instance as compromised.” I appreciate a group that keeps security as job number one. That’s rare these days.
How a patched server stayed vulnerable
CVE-2026-97229 is a Common Vulnerability Scoring System (CVSS) 10.0, which is as bad as security holes get: a flaw that has already been patched. So what happened?
More from ZDNET
First, you must understand what the bug was. It’s a potentially killer remote-code-execution vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). Under certain conditions, an unauthenticated attacker can execute arbitrary code on a GitLab server by supplying a specially crafted regular expression in a Continuous Integration and Continuous Delivery (CI/CD) pipeline configuration file. As Alpine explained, underlining this bug is another one in Onigmo, the Ruby language regular-expression engine. GitLab fixed it on Oct. 12 in versions 19.4.2, 19.3.5 and 19.2.8.
Also: Linux Mint 27 arrives next month, and I like it already: New features and other upgrades to expect
GitLab’s fix is a set of patches to Ruby that GitLab bundles in its own packages and container images. On Oct. 23, Upstream Ruby shipped the fix. So far, so good.
What happened next was that on Oct. 13, Alpine upgraded to GitLab 19.3.4 instead of 19.3.5 by mistake. After that, on Oct. 22, it upgraded to 19.3.6, which didn’t fix the bug. Alpine’s image used standard Ruby, which lacked the patch.
Meanwhile, a newly registered account sent crafted CI configurations that crashed GitLab workers eight times. In four of those crashes, the attacker got partway through the exploit before failing at the next step. The attacker also downloaded Alpine’s GitLab container image, suggesting they tuned the exploit to its exact build.
Once Alpine figured out what was happening and that their server was still vulnerable on Oct. 26, they closed it on Oct. 27. Then they reopened the server on Oct. 29 on the properly patched GitLab 19.3.7 with Ruby 3.3.13.
Why Alpine rebuilt rather than cleaned up
So everything was good? Right? Maybe. Alpine wasn’t so sure.
Their programmers figured that a successful exploit would leave no crash or trace records in the web logs. Some logs from the attack day were gone, and neither Alpine nor its host logged outbound connections. Therefore, Alpine said, “Because we cannot rule out code execution, and the evidence we would need to confirm it no longer exists, we took the harder route and rebuilt the GitLab instance from scratch.” Makes sense to me.
Also: 10 open-source apps every Windows user should download in 2026 – for free
In the aftermath, Alpine GitLab users must set new passwords, re-enroll two-factor authentication, create new access tokens, and accept new SSH host keys. Project maintainers must re-enter CI/CD variable values and assume the old ones may have been exposed.
Not an isolated case
The flaw is being actively exploited. CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalog on Oct. 30. Additionally, the Shadowserver Foundation, a non-profit security group, found over 1,000 unpatched GitLab servers over the weekend.
GitLab has had a run of maximum-severity bugs. In September, CVE-2026-85706, a repository, committed an Application Programming Interface (API) flaw that can be used to steal credentials and other secrets. Then, last month, CVE-2026-110264 (another regex-compiler bug allowing arbitrary code execution) was discovered. Shadowserver counted over 11,300 vulnerable instances, out of about 39,000 GitLab instances.
Also: I tried LordOS expecting another MacOS clone – then I opened its network monitor
It’s not just GitLab getting hammered, though. For example, the cloud security company Radware reported at least 83 attacks against 61 public GitHub repositories. These smacked several popular open-source projects.
All of these incidents moved very fast. No sooner were the vulnerabilities revealed as patched than they were attacked. The September GitLab bug was probed within about a day of its fix, and Alpine’s attacker arrived eight days after GitLab’s assault.
Most of these attacks sought programmer credentials such as CI/CD variables, runner tokens, SSH keys, and AI assistant data. In particular, hackers are going after CI/CD and developer laptops.
Looking ahead, Alpine said it will apply critical GitLab security releases within a day, check each release for Ruby or other component patches its own build must apply, log outbound connections, and keep logs longer than 14 days. It will also use signed release tags, so releases can be verified independently of GitLab.
Keep your Git servers from becoming the next target
“Keep your software patched” is always a good idea, but now you must keep your programs patched as soon as possible. AI-automated attackers won’t wait until after the weekend to rip into your system. That’s not enough, though, as Alpine’s experience showed. You need to verify that the fix actually reaches the code running on your server, especially if you build your own CI/CD systems and containers.
You must also make sure your software stack from top to bottom is up to date, not just that you’re running the latest application version. GitLab explicitly warns administrators using custom images or their own Ruby runtime that upgrading GitLab alone isn’t enough. Everything — and I mean everything — must be updated. Simply assuming the latest GitLab or GitHub version means the job is done is just asking for trouble.
Also: Maze Linux is the best security-focused distro I’ve ever tested
Beyond patching, administrators should focus on limiting what a compromised account, workflow, or server can reach. You know, or you should know, what that means. For instance, you must require two-factor authentication or passkeys. Patch management and account security are separate jobs, and you need both.
Tempting as it is to give your CI/CD pipelines all the authentication data they need to get work done, it’s a mistake. Don’t give your pipelines the keys to your kingdom. GitHub recommends granting workflow tokens only the permissions they need, making the default GITHUB_TOKEN read-only, and requiring approval before jobs can access environment secrets. That also means you must clean up your systems by removing unused credentials and, when possible, replacing long-lived cloud keys with short-lived credentials obtained through OpenID Connect.
That’s all well and good, but it’s not enough. You must constantly rotate secrets and not just passwords. If an attacker reaches a Git server or CI environment, changing login credentials alone may leave stolen API tokens, certificates, and deployment keys usable. GitLab’s incident guidance calls for rotating stored secrets after relevant compromises. Keep an inventory so you can identify, revoke, and replace them without guessing which projects depend on which credentials.
Also: My 5 favorite Linux distros for security – and how they protect your privacy
You should also keep untrusted builds away from trusted infrastructure. GitLab warns that malicious CI jobs can compromise runner hosts and steal credentials. Use isolated, disposable runners for risky workloads, avoid privileged containers, and keep deployment credentials and SSH keys off shared build machines. GitHub likewise warns that untrusted workflow code can compromise Git instances.
The job’s not done when you’ve locked down your developer pipeline. You must also secure your published releases. GitHub’s immutable releases prevent published binaries and archives from being replaced and lock the associated Git tag to a specific commit.
Finally, prevention needs a recovery plan. Alpine couldn’t rule out successful exploitation because the evidence it needed was no longer available. Its response included longer log retention, outbound-connection logging, and independently verifiable release tags. Armed with this information, you can determine what happened and whether you can patch and move on or need a top-to-bottom rebuild.
Please accept cookies to view the comments powered by Disqus.
