Self-hosted GitLab: critical RCE flaw targeted in attack on Alpine Linux

What happened

On October 20 and 21, attackers tried to exploit a critical remote code execution flaw in GitLab on the development infrastructure of Alpine Linux. The incident became public on November 1, 2026. Out of concern for a possible compromise, the Alpine Linux project rebuilt its GitLab server and reset all passwords.

The report does not name the specific vulnerability or the affected GitLab versions. What it does show is that a critical GitLab flaw is being actively used against internet-facing GitLab servers.

Who is affected

Anyone operating a self-hosted GitLab instance, in particular instances reachable from the internet. This includes GitLab servers used by agencies for customer projects, CI/CD pipelines and deployments. A compromised GitLab server can expose source code, stored secrets, CI/CD variables, deploy keys and access to the systems it deploys to.

GitLab.com (the hosted service) is operated by GitLab itself; this alert concerns servers you run yourself.

What to do now

1. Check which GitLab version your instance runs (Admin Area > Overview, or gitlab-rake gitlab:env:info on Omnibus installations).
2. Compare it with the latest GitLab security release. The fixed versions are not in our source data, so check the vendor advisory and the GitLab security release notes for the versions that close the critical flaw.
3. Back up your GitLab configuration and secrets (for Omnibus: /etc/gitlab/gitlab.rb and /etc/gitlab/gitlab-secrets.json) and create a regular backup.
4. Update GitLab to the latest patch release of your version line using your package manager or Docker image, then run gitlab-ctl reconfigure if your setup requires it.
5. Confirm all services run with gitlab-ctl status and check that login, repositories and CI pipelines work.
6. If you cannot update immediately, restrict access to the instance, for example by limiting it to VPN or known IP addresses, until the update is applied.
7. If you find any signs of compromise (see below), follow the example of Alpine Linux: treat the server as compromised, rebuild it from a clean state, and reset passwords, personal access tokens, deploy keys, runner tokens and CI/CD secrets.

How to check whether you were hit

• Review the GitLab logs (for Omnibus under /var/log/gitlab/, for example gitlab-rails/production_json.log, api_json.log and nginx access logs) for unusual requests, errors or access from unknown IP addresses, especially around and after October 20.
• Look in the Admin Area for new or unexpected users, administrators, personal access tokens, SSH keys, deploy keys, webhooks and runners.
• Check audit events for changes to permissions, project settings or CI/CD variables you did not make.
• On the server itself, look for unknown processes, new cron jobs, unexpected files in the GitLab directories and outgoing connections to unfamiliar hosts.
• Check recent commits and pipeline definitions (.gitlab-ci.yml) for changes nobody on your team made.

Sources

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://www.bleepingcomputer.com/news/security/alpine-linux-rebuilds-gitlab-after-attempted-rce-attack/