Attacker Tried to Exploit Alpine Linux’s GitLab via CVSS 10.0 Flaw Its Ruby Left Open Swati KhandelwalOct 29, 2026Vulnerability / Cyber Attack An attacker tried to exploit a critical GitLab vulnerability on the Alpine Linux project's own GitLab server a week after GitLab released a fix, Alpine Linux said on 28 October. The flaw, CVE-2026-97229 (CVSS score: 10.0), can let an attacker run code on a GitLab server through a crafted regular expression in a CI configuration. Alpine found no evidence that the attack worked but cannot rule it out, so it rebuilt the server from scratch and reset every account's password. GitLab's fix is a set of patches to the Ruby that GitLab ships in its own packages and container images. Alpine's GitLab image used standard Ruby, so upgrading the server to GitLab 19.3.6 on 22 October did not fix the flaw. For anyone running GitLab on their own Ruby, built from source or in their own container image, "upgrading GitLab is not enough," Alpine said. Those servers also need Ruby 3.3.13, 3.4.12, 4.0.9 or later, and users of Alpine's alpinelinux/gitlab image need to pull 19.3.6 again. The server gitlab.alpinelinux.org hosts aports, the repository from which Alpine's packages are built. Packages built from 20 to 24 October, and the 21 October releases, came from aports changes verified against records outside GitLab, according to Alpine. Those releases include the minirootfs files that the official Alpine Docker images are built from. Alpine is extending the checks to 27 October, when it closed the server. The keys that sign its packages and releases have never been on the GitLab server. On 13 October, Alpine upgraded the server to GitLab 19.3.4 instead of 19.3.5, which it calls a mistake. The server was still on that version, without the 12 October fix, when a newly registered account began probing it on 20 October. The account sent crafted CI configurations to the server on 20 and 21 October. They crashed GitLab worker processes 8 times, and the main attack on 21 October also caused 502 errors and caused CI jobs to fail. In 4 of those crashes, the attacker got partway through the exploit and failed at the next step, according to Alpine. The attacker also downloaded Alpine's GitLab container image, which Alpine said: "suggests they were tuning the exploit to our exact build." Alpine blocked the account on 23 October. The attacker came back on 25 and 26 October and tried to get back in, but those attempts failed, Alpine said. On 26 October, Alpine found that the server was still vulnerable after its 22 October upgrade to 19.3.6. The next day, it closed GitLab to everyone except its developers and build servers and started rebuilding it. The rebuild finished on 28 October. Alpine also replaced GitLab's secret keys, and the rebuilt server runs Ruby 3.3.13 or later, which has the fix. Alpine is testing it before reopening it to the public. Alpine found no sign that the attacker's code ran on the server. Timing probes showed no delays;; there were no unexpected files, keys, hooks, or processes; and no private data was sent back to the attacker via any web or API request that Alpine can see. It cannot be sure, though. "A successful exploit would leave no crash and no trace in the web logs," Alpine said. Some logs from the attack day are gone, including background job logs and the old container's filesystem, and neither Alpine nor its hosting provider logged outbound network connections. Because the evidence needed to confirm code execution no longer exists, Alpine treated the server as compromised and rebuilt it to remove any foothold a successful exploit could have left. If the attack succeeded, these could have been exposed: Email addresses, names, and IP addresses of all users 2FA secrets, CI/CD variables and runner tokens Webhook, integration and push mirror credentials Personal access tokens, which are stored as hashes Private repositories, and confidential issues and merge requests Beyond the password reset and the new secret keys, Alpine has not said whether runner tokens, CI/CD variables, access tokens or integration credentials stored on the server have been replaced. To check its packages, Alpine confirmed that every aports change added from 20 to 22 October arrived through a recorded push by a known developer. It checked this against records it says the attacker could not reach: a developer's copy of the repository and all 45 build servers. Every package built from 20 to 24 October came from aports changes as published on git.alpinelinux.org. GitLab compiles the regular expressions in CI configurations with Ruby, and the bug behind CVE-2026-97229 is in Onigmo, the regular expression engine built into Ruby. GitLab's 12 October release fixed it by patching the Ruby inside GitLab's Linux package and container images. Ruby's own fixed versions came out on 22 and 23 October. A GitLab upgrade does not change a server's own Ruby, so a GitLab install on standard Ruby keeps the flaw until Ruby itself is updated to a fixed version, as Alpine found. GitLab's fixed Linux packages and its official container images carry the patched Ruby. A self-compiled install, or a container image that installs Ruby separately as Alpine's did, does not get it. As of 29 October, neither of GitLab's patch release posts for 12 and 21 October tells administrators of self-compiled installs to update Ruby. GitLab's self-compiled installation guide still lists Ruby 3.2 as its minimum version, and Ruby 3.2 reached end of life in April and will get no fix. GitLab's advisory says that, "under certain conditions," the flaw could have allowed an unauthenticated user to run code on the server. GitLab.com and GitLab Dedicated are already patched. Rapid7 built a working exploit in a lab and published proof-of-concept code on 13 October. The exploit ran commands as GitLab's git user on an unpatched official GitLab 19.4.1 image, but the same input did not run on the patched 19.4.2 image. That exploit needs write access first: the attacker must commit a malicious .gitlab-ci.yml file and a file path with UTF-8 characters to a branch of a public project. That requirement does not apply on servers where new users can register themselves and create projects. In Rapid7's tested route, "only the final CI lint request is unauthenticated." GitLab's own detection notes also say the attacker must first create that file path through ordinary repository APIs. Rapid7 does not yet know how the attack in the original report to GitLab, which is still private, avoids the write step. Alpine has not said how its attacker's CI configurations reached GitLab, or whether new accounts could create public projects on its server. CVE-2026-97229 was not in CISA's Known Exploited Vulnerabilities catalog as of the catalog's 28 October update. GitLab's 21 October releases are the newest on each branch listed below, and they also fix CVE-2026-110264, a separate regex flaw. Branch Fixes CVE-2026-97229, per GitLab's advisory Newest release (21 October) 19.1, 19.0 and 18.11 Not listed as affected 19.1.9, 19.0.10 and 18.11.13 Which release fixes a server depends on how GitLab is installed: GitLab's Linux package or official container images: upgrade to the newest release for your branch. Self-compiled installs, or images that install their own Ruby: upgrade GitLab and update Ruby to 3.3.13, 3.4.12, 4.0.9, or later. Ruby 3.2 will not receive the fix, so servers running 3.2 need to upgrade to one of those versions. GitLab's advisory named 19.3.4 as the fixed version for the 19.3 branch when it was published on 12 October. It now names 19.3.5 and lists 19.3.4 as affected, so servers still on 19.3.4 should move to 19.3.6. If a server cannot be upgraded right away, Rapid7 suggests restricting anonymous access to public projects, stopping untrusted users from creating or writing to public projects, or blocking the CI lint route. Those steps cover only Rapid7's exploit route and do not fix the vulnerable regular expression compiler, the company said. GitLab has published six detection rules for exploitation attempts against self-managed servers, written in the Sigma format. Four of them, which GitLab marks as experimental, look for hostile patterns in CI regexp warnings and GraphQL ciLint requests, unusually long file paths with non-ASCII characters, and Ruby crash reports that point to Onigmo. The guidance with those rules warns that a successful exploit can leave no crash, and it gives these further steps: Look for files owned by the git user in /tmp, unexpected child processes of Puma or Sidekiq, outbound connections, and changed crontabs or SSH keys for the git user. If there are signs of code execution, treat the server as compromised and rotate the secrets in gitlab-secrets.json, all CI/CD variables, all runner tokens and all access tokens. Limit who can create accounts and personal access tokens on the server. Account holders will need to set a new password with "Forgot your password?" on the sign-in page when gitlab.alpinelinux.org reopens, Alpine said. It has also seen automated login attempts against its GitLab using passwords leaked from other sites, and anyone who used their gitlab.alpinelinux.org password elsewhere should change it there. Users of the alpinelinux/gitlab image should pull alpinelinux/gitlab:19.3.6 again. The image published on 27 October contains Ruby 3.3.13, while any 19.3.6 image pulled before then, and every older tag, is vulnerable. Alpine's own Ruby packages already have the fix: Ruby 3.4.12 on Alpine 3.22, 3.23, 3.24 and edge, and Ruby 3.3.13 on Alpine 3.21. Running apk upgrade installs it. Ruby's maintainers say the bug matters only for programs that compile a regular expression from text an attacker controls, and that Ruby's Regexp.timeout setting does not protect against it. Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post. Cyber Attack, linux, Software Security, Supply Chain, Vulnerability, Web Security Researchers Demonstrate Node2Shell RCE Exploit on Node.js Build Using Crafted Brotli Data Brotli Decoder Flaw Behind Node.js RCE Also Affects Bun, Python and Other Widely Used Software Hackers Hijack Five OVHcloud CLI Releases to Distribute Secret-Stealing Malware Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH Connections Ruby Fixes Three Regex Engine Bugs Responsible for Four Critical GitLab RCE Flaws PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches Hackers Use Autonomous AI Agents to Breach Company Websites, Target Over 1,200 Sites New QPACK Flaws Can Crash HTTP/3 Servers, Trigger Up to 4,000-Fold Memory Amplification OpenCode Console Breach May Have Exposed OpenAI, Anthropic, and Google API Keys Two CVSS 9.0 Linux KSMBD RCE Flaws Disclosed on Public Mailing Lists Before Kernel Fixes ThreatsDay: AI Secrets Leak, PingCAP Source Theft, Signal Hang-Up Flaw, Laravel Auth Bypass + 21 More Unpatched Broadcom Wi-Fi Flaw Lets Attackers in Range Run Code as Root on Routers Generative AI Is Erasing Behavioral Tells, Weakening Behavior-Only Detection, Proofpoint Reports ⚡ Weekly Recap: 98 Zero-Days, Rogue AI Agents, $100M Crypto Theft, 700 Supermarkets Hit and More Critical GitLab Flaw (CVSS 10.0) Could Allow Unauthenticated RCE Across 12 Years of Releases Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software State Bank of India Confirms Data Leak After 3,897 Customer Records Found on Dark Web Critical FortiSIEM Flaw Gets Public Exploit PoC for Unauthenticated Remote Code Execution WhatsApp Hid Instructions in Help Pages Telling Its AI Chatbot Not to Recommend Privacy Regulators Go Issues Emergency Update Blocking Eight CA Keys Over Undisclosed Security Concerns Hackers Exploit Plex2Shell Flaws to Install Crypto Miners and Linux Proxy Backdoor Critical Flaw in Python’s Popular Pillow Image Library Allows Code Execution via a Crafted Image PHP2Shell: Two Unpatched Critical PHP RCE Flaws (CVSS 9.2) Trigger Emergency Security Alert PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge Download the 2026 Agent Security Report for a Five-Step Risk Reduction Framework No Exploit Yet? Preview the Summit Demo on Validating CVE Exposure Get the Five-Stage Identity Maturity Roadmap for Governing AI Agents Benchmark Your AI Risk Priorities Against 1,600 CISOs—Download the 2026 Report Your SOC Has an Identity Blind Spot. Here's How to Fix It Learn how to close critical identity visibility gaps in your SOC, detect hidden threats, and accelerate incident response across human, machine, and AI identities. Join the Session Roadmap for AI-Ready Security Operations Evaluate Attack Surface Visibility With an AI Threat Readiness Framework Learn how to assess AI threat readiness, strengthen attack surface visibility, and prepare security operations for emerging threats in this practical webinar. Governance Sets the Ceiling on Your AI Security Program See the five moves that raise a Stage 2 Govern score to a defensible Stage 3. 11 Real Stories: How Identity Exposure Unlocks Active Attack Paths Map cross-domain privilege escalation to sever breach routes at key choke points. Accelerate Incident Response: 95% Faster Containment Cut containment time from 48 hours to 3. Read the Orchid IR case study. FBI Cyber Division's Brett Leatherman Keynotes SANS CDI 2026, Dec 15 Join SANS CEO James Lyne and the FBI on ransomware disruption and intel sharing, during SANS training in D.C. Why Root and Jailbreak Detection Alone Cannot Guarantee Mobile App Security Your Backup Isn't Ransomware-Proof Just Because It Exists The Least Trusted Author Sets the AI Agent's Privilege Security Rests on Hard Math Problems. Quantum and AI Are Both Coming for Them