TechAtelier
CYBERSECURITY · GITLAB · RUBY

GitLab and Alpine Linux: why upgrading the app was not enough

In October 2026, Alpine Linux faced attempted exploitation of a critical GitLab vulnerability. Its custom container image remained exposed even after GitLab itself was upgraded.

A critical CI configuration vulnerability

CVE-2026-97229 affects how GitLab processes regular expressions in CI/CD configurations and can, under certain conditions, result in remote code execution. GitLab shipped fixes on October 12, 2026. Affected branches include 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2. Administrators should still consult the latest vendor security release for their branch.

What happened at Alpine Linux?

Alpine reported attempted exploitation on October 20–21. A newly created account submitted maliciously crafted CI configurations, triggering crashes in GitLab worker processes. Alpine found no evidence of successful code execution but could not rule it out, partly because relevant logs were missing.

As a precaution, the project rebuilt its GitLab infrastructure, rotated secrets and reset passwords. Its investigations found no evidence of tampering with the Alpine packages and releases it checked.

Why a GitLab upgrade was not enough

The underlying bug was in Onigmo, Ruby’s regular expression engine. GitLab’s official packages and images included patched Ruby components, but Alpine used a custom image with standard Ruby. Upgrading GitLab to 19.3.6 on October 22 therefore left the vulnerable Ruby runtime in place.

Fixed upstream Ruby releases include 3.3.13, 3.4.12 and 4.0.9. Alpine republished its alpinelinux/gitlab:19.3.6 image with a patched Ruby on October 27. Older copies of that same image tag remained vulnerable.

Practical checklist for operators

  1. Identify deployment provenance: determine whether GitLab comes from official packages, official images, community images or a source installation.
  2. Check the actual Ruby runtime: for custom builds, verify the runtime version and relevant security patches separately from the GitLab version.
  3. Rebuild and redeploy: do not trust a container tag alone; use fixed images and prefer immutable digests.
  4. Review CI permissions: limit who can submit untrusted configurations and apply all applicable vendor security releases.
  5. Preserve evidence: if exploitation is suspected, retain logs and follow an incident-response process rather than assuming an upgrade resolves past exposure.
  6. Audit the build chain: inventory runtimes, dependencies and the images actually running in production.

The broader container security lesson

An application version number does not prove that every underlying dependency is fixed. Base images, runtimes, native libraries and locally built artifacts all matter. The same lesson applies to other Dockerized services beyond GitLab.

TechAtelier Software Watch can help track software versions, but does not replace image dependency scanning or incident response.

Official sources

Published October 31, 2026.