Công ty bạn tự dựng một máy chủ GitLab trong phòng máy từ nhiều năm trước. Toàn bộ mã nguồn, pipeline build, cả những file cấu hình chứa mật khẩu đều nằm ở đó. Hôm 12/10, bạn vừa cẩn thận cập nhật bản vá bảo mật mới nhất, yên tâm đánh dấu "xong". Chín ngày sau, GitLab lại phát hành bản vá khẩn, và lần này máy chủ bạn vừa vá vẫn nằm trong danh sách có nguy cơ.
Ngày 21/10/2026, GitLab công bố bản sửa cho một lỗ hổng cho phép kẻ tấn công chạy mã trên máy chủ mà không cần đăng nhập, và nó có mặt trong mọi phiên bản từ 7.0, ra đời năm 2014. Bài này giải thích lỗi nằm ở đâu, vì sao nó "sống" được suốt 12 năm, ai cần hành động và cần nâng lên bản nào.
Điểm 10.0 nghĩa là nguy hiểm đến mức nào?
Lỗ hổng mang mã CVE-2026-110264 và được chấm 10.0 trên thang CVSS (hệ thống chấm điểm mức nghiêm trọng của lỗ hổng). 10.0 là mức tối đa, không thể cao hơn.
Lý do nằm ở hai chữ "không cần đăng nhập". Phần lớn lỗ hổng đòi hỏi kẻ tấn công phải có sẵn một tài khoản, dù chỉ là tài khoản thường. Lỗi này thì không. Theo GitLab, trong một số điều kiện nhất định, người dùng chưa xác thực có thể chạy mã tùy ý (arbitrary code) trên máy chủ. Chạy được mã trên máy chủ GitLab gần như đồng nghĩa với việc cầm chìa khoá kho mã nguồn của cả công ty.
Hình dung thế này: máy chủ GitLab giống một toà nhà văn phòng có bảo vệ ở cửa. Lỗ hổng thường là khi một nhân viên có thẻ ra vào lén mở cửa phòng khác. Lỗ hổng này là khi một người lạ ngoài đường, không có thẻ, vẫn đi thẳng vào phòng máy chủ.
Có hai điểm khiến tình hình bớt căng một chút:
- Chưa thấy bị khai thác: GitLab cho biết chưa có dấu hiệu lỗi bị dùng trong tấn công thực tế.
- Chưa vào danh mục KEV: tính tới ngày 22/10, lỗi chưa có tên trong danh mục các lỗ hổng đã bị khai thác của CISA (cơ quan an ninh mạng Mỹ).
Hãng không công bố kẻ tấn công cần điều kiện gì để chạm tới chỗ lỗi. Vì vậy bạn chưa thể tự loại mình ra chỉ bằng cách xem lại cấu hình. Theo GitLab, cập nhật là cách bảo vệ chắc chắn duy nhất, và thông báo của hãng không đưa ra biện pháp tạm thời nào.
Một biểu thức chính quy thì nguy hiểm ở chỗ nào?
Gốc rễ là lỗi integer overflow (tràn số nguyên) xảy ra khi GitLab biên dịch một biểu thức chính quy (regular expression, hay regex) được tạo đặc biệt.
Regex là kiểu "công thức tìm kiếm" dùng để dò chuỗi ký tự, ví dụ tìm mọi địa chỉ email trong một đoạn văn. Trước khi dùng, regex phải được "biên dịch" thành dạng máy hiểu được, và trong lúc đó chương trình phải tính xem cần bao nhiêu bộ nhớ.
Tràn số nguyên giống như đồng hồ công-tơ-mét xe máy chỉ có 5 chữ số: chạy quá 99.999 km thì nó quay về 00.000. Khi một phép tính bên trong chương trình bị "quay vòng" như vậy, con số nó dựa vào để làm việc tiếp theo đã sai hoàn toàn mà nó không hề hay biết. Với lỗi này, GitLab cho biết hậu quả là kẻ tấn công có thể chạy mã tùy ý trên máy chủ.
Vì sao lỗi tồn tại suốt 12 năm phiên bản?
Câu trả lời nằm ở thành phần bị lỗi. Bộ biên dịch regex ở đây không phải code GitLab tự viết, mà là Onigmo, engine regex có sẵn trong ngôn ngữ Ruby. GitLab đóng gói Onigmo vào trong các gói cài đặt của mình và tự vá nó trong bản build riêng.
Điều đó có nghĩa: ở đâu GitLab mang theo Onigmo, ở đó có điểm yếu này. Và GitLab đã mang theo nó trong mọi bản phát hành kể từ 7.0. Nó giống một viên gạch lỗi nằm ngay trong móng nhà: bạn sửa sang, xây thêm bao nhiêu tầng thì viên gạch ấy vẫn ở dưới cùng.
Bạn có phải làm gì không, và nâng lên bản nào?
Trước hết, xem bạn đang dùng GitLab kiểu nào:
| Kiểu dùng | Có cần làm gì? |
|---|---|
| GitLab.com (bản dịch vụ của hãng) | Không, đã chạy bản vá |
| GitLab Dedicated | Không, nếu đang ở bản nội bộ 19.3.5-internal0, 19.4.2-internal0 hoặc mới hơn |
| Self-managed (tự cài trên máy chủ riêng) | Có, phải cập nhật |
Nếu bạn tự cài GitLab, đây là bảng nhánh phiên bản và bản vá tương ứng. GitLab vá cùng lúc 7 phiên bản:
| Đang chạy | Nâng lên |
|---|---|
| 19.5 trước 19.5.1 | 19.5.1 |
| 19.4 trước 19.4.3 | 19.4.3 |
| 19.3 trước 19.3.6 | 19.3.6 |
| 19.2 trước 19.2.9 | 19.2.9 |
| 19.1 trước 19.1.9 | 19.1.9 |
| 19.0 trước 19.0.10 | 19.0.10 |
| 7.0 tới 18.11, trước 18.11.13 | 18.11.13 |
Bản vá ngày 12/10 chỉ áp dụng cho các phiên bản từ 19.2 trở lên. Các bản sửa mới cao hơn nó đúng một bậc patch, nên máy chủ đã cập nhật hôm 12/10 lại nằm trong vùng ảnh hưởng. Đừng dừng lại vì nghĩ mình vừa vá xong.
Vì sao cả bản cũ cũng được vá?
Bình thường, chính sách của GitLab chỉ vá bản hiện hành và hai bản hằng tháng liền trước, tức hiện tại là 19.5, 19.4 và 19.3. Lần này, hãng backport (đưa bản sửa ngược về bản cũ) cho thêm bốn phiên bản là 18.11.13, 19.0.10, 19.1.9 và 19.2.9. Theo GitLab, đây là bước chỉ dành cho những sự cố nghiêm trọng. Nói cách khác, chính việc hãng phá lệ đã cho thấy mức độ của lỗi này.
Nhà nghiên cứu nào đứng sau chuỗi lỗi regex này?
Đây không phải lần đầu engine regex của GitLab gặp chuyện. Lỗi này là lỗi chạy mã thứ tư trong engine regex mà cùng một nhà nghiên cứu, dùng biệt danh joaxcar, báo cáo trong vòng một tháng. Và nó là lỗi đầu tiên chạm tới các phiên bản cũ hơn 19.2.
| Ngày vá | Mã lỗi | Điểm | Cần đăng nhập? | Phạm vi |
|---|---|---|---|---|
| 23/9 | CVE-2026-93577 | 9.9 | Có | Từ 19.2 |
| 23/9 | CVE-2026-89078 | 9.9 | Có | Từ 19.2 |
| 12/10 | CVE-2026-97229 | 10.0 | Không | Từ 19.2, vá trong 19.2.8, 19.3.5, 19.4.2 |
| 21/10 | CVE-2026-110264 | 10.0 | Không | Từ 7.0 |
Lỗi ngày 12/10 cũng là lỗi tràn trong bộ biên dịch regex, không cần đăng nhập, điểm 10.0. Ba lỗi trước đều dừng ở phiên bản 19.2. Lỗi mới thì không, nó đi ngược về tận 2014.
Bản cập nhật 21/10 còn vá những gì?
Tổng cộng bản phát hành 21/10 sửa 11 lỗi bảo mật: một lỗi nghiêm trọng (critical) như trên, còn lại thuộc mức cao, trung bình hoặc thấp. Hai lỗi đáng chú ý liên quan tới xác thực:
- CVE-2026-15723 (mức cao, 8.2): người dùng đã đăng nhập có thể chiếm tài khoản của người khác, nhưng chỉ khi quản trị viên bật cả hai tính năng tự liên kết tài khoản SAML và LDAP (hai cách đăng nhập tập trung phổ biến trong doanh nghiệp).
- CVE-2026-112212 (mức cao, 7.5): lỗi cache poisoning (đầu độc bộ nhớ đệm) ở các endpoint OAuth và OpenID Connect. Trong hệ thống dùng cache chung, kẻ tấn công có thể chuyển hướng một số luồng đăng nhập tới máy chủ do họ kiểm soát.
Cache poisoning giống như ai đó dán đè một tờ chỉ đường giả lên tấm biển ở ngã tư. Mọi người đi qua đều tin vào tấm biển, nên cứ thế rẽ vào con đường kẻ gian muốn.
Làm sao biết đã có ai thử tấn công chưa?
GitLab công bố thêm hai luật phát hiện (detection rule) để quản trị viên tự cài GitLab dò tìm dấu hiệu khai thác:
- "Onigmo native worker crash"
- "Org mode render error burst"
Hai luật này thuộc TLDR, framework mã nguồn mở của GitLab. Mỗi luật được viết theo định dạng Sigma (một chuẩn chung để mô tả quy tắc phát hiện tấn công) và chạy trên chính log ứng dụng của GitLab.
Luật phát hiện chỉ giúp bạn biết đã có ai "gõ cửa" hay chưa, nó không chặn được tấn công. Hãy cập nhật bản vá trước, rồi dùng hai luật này soát lại log để chắc chắn máy chủ chưa bị đụng tới.
Cập nhật có làm gián đoạn hệ thống không?
Có, và bạn nên lên kế hoạch trước. Hai bản 19.4.3 và 19.3.6 có các thay đổi cơ sở dữ liệu chạy ngay trong lúc nâng cấp. Với máy chủ một node (single-node), điều đó nghĩa là hệ thống sẽ ngừng hoạt động cho tới khi các thay đổi chạy xong.
Nếu bạn chạy hệ thống nhiều node (multi-node), GitLab cho biết có thể áp bản vá mà không gián đoạn bằng quy trình zero-downtime (nâng cấp không ngừng dịch vụ) của hãng.
Một checklist ngắn cho người quản trị:
- [ ]Xác định đang dùng GitLab.com, Dedicated hay self-managed
- [ ]Đối chiếu phiên bản hiện tại với bảng ở trên, kể cả khi vừa vá hôm 12/10
- [ ]Báo trước cho team nếu là máy chủ single-node ở nhánh 19.4 hoặc 19.3
- [ ]Nâng cấp lên bản sửa tương ứng
- [ ]Bật hai luật phát hiện để rà log
Với một lỗ hổng điểm 10.0 chưa có biện pháp tạm thời, vài phút downtime có kế hoạch luôn rẻ hơn một kho mã nguồn bị lộ.
Tóm tắt nhanh
- CVE-2026-110264 (CVSS 10.0) cho phép chạy mã trên máy chủ GitLab self-managed không cần đăng nhập, ảnh hưởng mọi bản từ 7.0 (2014).
- Gốc lỗi là tràn số nguyên khi biên dịch regex trong Onigmo, engine regex của Ruby mà GitLab đóng gói sẵn.
- GitLab vá 7 phiên bản cùng lúc, kể cả 4 bản ngoài chính sách hỗ trợ; máy chủ vá hôm 12/10 vẫn phải cập nhật tiếp.
- GitLab.com và Dedicated (từ 19.3.5-internal0, 19.4.2-internal0) đã an toàn; chưa có dấu hiệu bị khai thác.
- Bản 19.4.3 và 19.3.6 gây downtime trên máy chủ single-node do thay đổi cơ sở dữ liệu.
Câu hỏi thường gặp
Tôi dùng GitLab.com thì có cần làm gì không?
Không. GitLab.com đã chạy phiên bản có bản sửa. Chỉ các bản cài đặt self-managed mới cần tự cập nhật.
Tôi đã cập nhật bản vá ngày 12/10, vậy đã an toàn chưa?
Chưa. Bản vá 12/10 chỉ phủ phiên bản 19.2 trở lên và các bản sửa mới cao hơn nó một bậc patch, nên máy chủ cập nhật hôm đó vẫn nằm trong vùng ảnh hưởng.
Có cách tạm thời nào nếu chưa thể nâng cấp ngay?
Thông báo của GitLab không đưa ra biện pháp tạm thời. Do hãng chưa công bố điều kiện để khai thác, bạn cũng không thể tự loại trừ rủi ro bằng cấu hình. Cập nhật là cách bảo vệ chắc chắn duy nhất.
Lỗi này đã bị hacker khai thác chưa?
Theo GitLab, chưa có dấu hiệu lỗi bị dùng trong tấn công, và tính tới ngày 22/10 nó chưa có trong danh mục lỗ hổng bị khai thác của CISA.
