6 phút đọc

GitLab tự cài dính lỗi 10 điểm, người lạ chạy được mã trên máy chủ

Lỗ hổng CVE-2026-110264 cho phép người không có tài khoản chạy mã trên GitLab tự cài, có từ bản 7.0 năm 2014. Kiểm tra phiên bản, nâng lên bản vá ngày 21/10, chưa nâng được thì đóng GitLab khỏi internet.

Xem nhanh trong 1 phút

Con VPS chạy GitLab của team nhỏ thường giữ nhiều bí mật hơn cả máy production. Trong biến CI/CD có key cloud, key API AI, mật khẩu database. Có deploy key, token của runner, khóa SSH để đẩy code lên server. Ngày 21/10, GitLab công bố một lỗ hổng cho phép người không cần tài khoản chạy mã trên chính máy chủ đó, điểm CVSS 10, mức cao nhất của thang đo.

Lỗi mang mã CVE-2026-110264 và có mặt từ GitLab 7.0, bản ra năm 2014. Nói cách khác, mọi GitLab tự cài chưa lên bản vá hôm 21/10 đều dính, dù bạn dựng nó từ năm nào.

Linh vật robot giơ khiên chắn trước tủ máy chủ bị nứt, chùm chìa khóa và thẻ bí mật rơi ra từ vết nứt

Lỗi nằm ở đâu

Theo thông báo của GitLab, khi máy chủ biên dịch một biểu thức chính quy (regex) được chế sẵn, một phép tính số nguyên bị tràn. Trong “một số điều kiện”, người chưa đăng nhập lợi dụng được chỗ này để chạy mã tùy ý trên máy chủ GitLab.

Những điều kiện đó là gì thì GitLab chưa nói. Theo thông lệ, chi tiết kỹ thuật của các lỗi bảo mật chỉ được mở ra khoảng 90 ngày sau khi vá. Manh mối duy nhất nằm ở hai quy tắc phát hiện mà GitLab phát hành kèm bản vá: một quy tắc bắt trường hợp worker chết vì Onigmo (bộ máy regex của Ruby, ngôn ngữ GitLab dùng), một quy tắc bắt lỗi dồn dập khi hiển thị file Org mode. Cùng đợt, GitLab cũng cập nhật bản vá lỗi regex cho Ruby 3.3, 3.4 và 4.0 đi kèm. Đường khai thác cụ thể thì chưa nguồn nào xác nhận.

Người báo lỗi là nhà nghiên cứu joaxcar, qua chương trình săn lỗi của GitLab trên HackerOne.

Lỗi 10 điểm thứ hai trong tháng

Hôm 12/10, GitLab đã vá CVE-2026-97229, cũng 10 điểm, cũng tràn số nguyên lúc biên dịch regex, nhưng nằm ở phần đọc cấu hình CI/CD và chỉ ảnh hưởng ba nhánh 19.2, 19.3, 19.4 (bản vá 19.2.8, 19.3.5, 19.4.2).

Rapid7 đã dựng được mã khai thác cho lỗi ngày 12/10. Trên image Docker chính thức gitlab-ce 19.4.1, họ chạy được lệnh dưới quyền user git của GitLab, còn với bản 19.4.2 thì không. Điều kiện của họ là đẩy được một file .gitlab-ci.yml độc vào một dự án công khai, việc rất dễ nếu GitLab của bạn cho người lạ tự đăng ký và tạo dự án.

Cần tách bạch hai chuyện. Bản khai thác của Rapid7 là cho lỗi ngày 12/10, không phải CVE-2026-110264. Với lỗi mới, tới sáng 22/10:

  • chưa có mã khai thác công khai
  • GitLab chưa ghi nhận vụ khai thác thật nào
  • lỗi chưa có trong danh sách KEV (lỗ hổng đang bị khai thác) của CISA, bản cập nhật ngày 21/10

Có điều hai lỗi cùng nằm ở khâu biên dịch regex, và lỗi trước đã bị dựng mã khai thác chỉ trong vài ngày. Mình không nghĩ lỗi mới sẽ yên lâu. Đây là nhận định của mình, không phải thông tin từ nguồn.

Còn một điểm dễ nhầm: ai đã lên 19.4.2 hồi 12/10 vẫn phải lên tiếp 19.4.3.

Ai bị ảnh hưởng

GitLab CE và EE tự cài, dù cài bằng gói Omnibus, Docker hay Helm, mọi bản từ 7.0 chưa tới bản vá. GitLab.com đã được vá từ trước khi công bố. GitLab Dedicated chạy từ 19.3.5-internal0 hoặc 19.4.2-internal0 trở lên cũng không phải làm gì.

Bản vá theo từng nhánh, theo thông báo chính thức ngày 21/10:

Nhánh đang chạy Lên tối thiểu bản
19.5 19.5.1
19.4 19.4.3
19.3 19.3.6
19.2 19.2.9
19.1 19.1.9
19.0 19.0.10
18.11 18.11.13

Đang chạy bản cũ hơn 18.11 thì không có bản vá riêng, phải nâng lên ít nhất 18.11.13.

Xem GitLab của bạn đang chạy bản nào

Cài bằng gói Omnibus (.deb, .rpm), gõ trên máy chủ:

sudo head -1 /opt/gitlab/version-manifest.txt

Chạy bằng Docker, thay gitlab bằng tên container của bạn:

docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

Hoặc đăng nhập bằng tài khoản quản trị rồi mở trang /help, số phiên bản nằm ở đầu trang.

Nâng cấp

Sao lưu trước bằng sudo gitlab-backup create. Bản sao lưu này không chứa /etc/gitlab/gitlab.rb và /etc/gitlab/gitlab-secrets.json, nên chép riêng hai file đó ra chỗ an toàn. Mất file secrets thì khôi phục xong cũng không giải mã được biến CI/CD.

Omnibus trên Ubuntu, Debian:

sudo apt-get update
sudo apt-get install gitlab-ce   # bản EE thì thay bằng gitlab-ee

Lệnh trên đưa máy lên bản mới nhất. Muốn ở lại nhánh đang dùng thì ghi rõ bản, ví dụ sudo apt-get install gitlab-ce=19.4.3-ce.0.

Docker Compose: sửa dòng image: thành bản vá, ví dụ gitlab/gitlab-ce:19.5.1-ce.0, rồi chạy:

docker compose pull
docker compose up -d

Ba sai lầm thường gặp:

  1. GitLab không cho nhảy cóc. Máy đang ở 15.x, 16.x mà muốn lên 19.x thì phải đi qua các bản dừng bắt buộc (tra bằng công cụ Upgrade Path của GitLab), mỗi bước chờ background migration chạy xong. Máy càng cũ càng mất thời gian, nên làm mục chặn mạng bên dưới trước.
  2. Bản vá có migration database. Cài một máy thì GitLab sẽ ngừng phục vụ trong lúc migrate, báo team trước khi bấm.
  3. Nâng xong, chạy lại lệnh xem phiên bản. Đừng tin vào việc lệnh cài chạy không báo lỗi.

Chưa nâng được thì đóng cửa trước

GitLab không đưa ra cách giảm thiểu tạm thời nào cho lỗi này. Cách chắc nhất là không để người lạ chạm được vào GitLab cho tới khi vá xong.

Chặn cổng web (80, 443) và cổng SSH của git, chỉ mở cho IP văn phòng, IP của runner, hoặc chỉ cho vào qua VPN như WireGuard, Tailscale. Làm việc này ở firewall của nhà cung cấp VPS (security group, cloud firewall) sẽ chắc hơn ufw: GitLab chạy trong Docker thì cổng do Docker mở thường đi vòng qua luật ufw, chặn bằng ufw tưởng đã đóng mà vẫn mở.

Nhớ để runner vẫn gọi được GitLab, không thì pipeline đứng hết.

Thêm hai việc trong Admin Area, Settings, General: tắt tự đăng ký tài khoản (mục Sign-up restrictions) và hạn chế dự án công khai (mục Visibility and access controls). Hai việc này chặn đúng đường mà Rapid7 dùng cho lỗi ngày 12/10. Với lỗi mới, đường khai thác chưa rõ nên chúng chỉ giảm bớt rủi ro, không thay được bản vá.

Nếu nghi máy đã bị vào

GitLab bị chiếm thì coi như mọi thứ nó giữ đều đã lộ. Thu hồi và tạo lại:

  • biến CI/CD ở cả cấp instance, group và project, nhất là key cloud, key API AI, mật khẩu database production
  • deploy key, khóa SSH mà pipeline dùng để vào server
  • personal access token, token của project và group
  • token của runner, và khóa trên chính máy runner nếu runner nằm chung máy với GitLab
  • secret của webhook và các tích hợp như registry, Slack

Dấu hiệu nên xem lại: worker của GitLab chết bất thường trong log (sudo gitlab-ctl tail), lỗi 500 dồn dập khi mở file .org, tài khoản lạ, khóa SSH lạ, dự án hay pipeline mà không ai trong team tạo.

GitLab tự cài hay là kiểu máy dựng một lần rồi để đó cả năm. Lần này đáng để mở nó ra xem lại.

Team bạn đang chạy GitLab bản nào, tự cài hay dùng GitLab.com? Nâng cấp có vướng bản dừng bắt buộc không? Kể trong cộng đồng Vibe Code & Bảo Mật nhé.

Nguồn

Chia sẻ lên Facebook

Bình luận

Đang tải bình luận…