Lỗ hổng GitLab CVE-2026-97229 (CVSS 10): cần cập nhật ngay

Ngày đăng31/10/2026
9 phút đọc

Mục lục8

Ngày 29/10/2026, cơ quan an ninh mạng Hoa Kỳ (CISA) đưa lỗ hổng GitLab CVE-2026-97229 vào danh sách "lỗ hổng đã bị khai thác trong thực tế". Mức độ nghiêm trọng là 10.0, mức cao nhất. Bản vá đã có từ ngày 12/10, nhưng các máy chủ chưa cập nhật đang bị nhắm tới.

Bài viết này dành cho cả doanh nghiệp tự vận hành GitLab lẫn doanh nghiệp đang gửi mã nguồn trên GitLab của bên phát triển: cần kiểm tra gì, và xử lý theo thứ tự nào.

Tóm tắt nhanh

Bạn tự cài GitLab trên máy chủ của mình → Cập nhật ngay lên bản mới nhất của nhánh đang dùng (tính đến 29/10/2026: 19.5.3 / 19.4.5 / 19.3.7 / 19.2.10…).
Bạn chỉ dùng GitLab.com (bản đám mây) → GitLab đã tự vá, bạn không cần làm gì.
Nguyên nhân gốc nằm trong ngôn ngữ lập trình Ruby mà GitLab sử dụng. GitLab cài không qua gói chính thức thì còn phải cập nhật cả Ruby.
Ngày 21/10, GitLab còn vá thêm một lỗ hổng 10.0 khác (CVE-2026-110264). Lên bản mới nhất là vá được cả hai.

10.0

Điểm CVSS (cao nhất)

Đã bị khai thác

CISA xác nhận ngày 29/10

~26.000

Máy chủ chạy bản chưa vá (toàn cầu, ngày 13/10)

Giải thích thuật ngữ

GitLab = hệ thống lưu trữ mã nguồn, giúp đội phát triển làm việc chung và tự động kiểm thử, triển khai. Có thể tự cài trên máy chủ riêng (self-managed) hoặc dùng bản đám mây GitLab.com.

CI/CD = cơ chế tự động kiểm thử và đưa chương trình lên môi trường thật.

Lỗ hổng = điểm yếu của hệ thống mà kẻ xấu có thể lợi dụng để tấn công.

Lỗ hổng này là gì, nguy hiểm ra sao?

Theo thông báo của GitLab, chỉ cần đưa một "biểu thức chính quy" (regex, cách viết để tìm chuỗi ký tự) được chế tác đặc biệt vào file cấu hình CI/CD, kẻ tấn công không cần đăng nhập vẫn có thể chạy lệnh tùy ý trên máy chủ GitLab.

Máy chủ GitLab thường chứa những thứ sau. Nếu máy chủ bị chiếm quyền, tất cả có thể bị đánh cắp hoặc sửa đổi cùng lúc.

Mã nguồn

Toàn bộ chương trình của dịch vụ và hệ thống nghiệp vụ.

Mật khẩu, khóa của môi trường thật

Để tự động triển khai, thông tin đăng nhập máy chủ và đám mây thường được lưu ngay trong GitLab.

Tài khoản nhân viên, đối tác

Email, và mật khẩu của những người dùng chung mật khẩu với dịch vụ khác.

Thật sự "không cần đăng nhập"?

GitLab và CISA đều ghi là không cần xác thực. Tuy nhiên, khi Rapid7 tái hiện, kẻ tấn công trước đó cần có quyền ghi vào một dự án công khai. Vấn đề là nếu GitLab cho phép ai cũng tự đăng ký tài khoản, điều kiện này rất dễ đáp ứng. Trong vụ tấn công GitLab của Alpine Linux, kẻ tấn công cũng bắt đầu bằng việc đăng ký một tài khoản mới.

Phiên bản bị ảnh hưởng và bản cần lên

Ảnh hưởng tới GitLab tự cài (cả Community Edition và Enterprise Edition). GitLab.com và GitLab Dedicated đã được GitLab vá sẵn.

Nhánh	Bị CVE-2026-97229?	Bản vá đầu tiên	Nên lên (tính đến 29/10)
19.5	Không có tên	—	19.5.3 trở lên
19.4	Có	19.4.2 (12/10)	19.4.5 trở lên
19.3	Có	19.3.5 (12/10)	19.3.7 trở lên
19.2	Có	19.2.8 (12/10)	19.2.10 trở lên
19.1 · 19.0 · 18.11	Bị lỗ hổng 10.0 khác	—	19.1.10 / 19.0.11 / 18.11.14 trở lên
18.10 trở về trước	Không có bản vá	—	Nâng cấp lên nhánh còn hỗ trợ

※ Các nhánh từ 19.1 trở về trước không có tên trong danh sách của CVE-2026-97229. Nhưng lỗ hổng CVE-2026-110264 (cũng 10.0) được vá ngày 21/10 ảnh hưởng gần như mọi bản từ GitLab 7.0. Bản càng cũ càng cần cập nhật gấp.

※ Một số tin tức ghi bản vá của nhánh 19.3 là "19.3.4", nhưng theo thông báo chính thức của GitLab là 19.3.5.

Cập nhật GitLab mà vẫn chưa hết lỗi

Nguyên nhân thật sự nằm ở phần xử lý regex của Ruby, ngôn ngữ mà GitLab chạy trên đó. GitLab chỉ đóng gói bản sửa Ruby trong các gói chính thức (Omnibus, Docker image chính thức…).

Nếu bạn tự build GitLab từ mã nguồn hoặc dùng container không chính thức, cần cập nhật cả Ruby lên 3.3.13 / 3.4.12 / 4.0.9 trở lên. Alpine Linux đã cập nhật GitLab nhưng vẫn còn lỗ hổng, và bị tấn công lần nữa vào ngày 25–26/10.

Diễn biến

12/10/2026
GitLab phát hành bản vá (19.4.2 / 19.3.5 / 19.2.8)
13/10/2026
Công ty bảo mật công bố mã tái hiện tấn công (PoC). Lúc này khoảng 26.000 máy chủ đang chạy bản chưa vá
20–21/10/2026
GitLab của Alpine Linux bị tấn công
21/10/2026
Vá thêm lỗ hổng 10.0 khác (CVE-2026-110264), kể cả cho các nhánh cũ 18.11–19.1
23/10/2026
Ruby phát hành bản sửa (3.3.13 / 3.4.12 / 4.0.9)
29/10/2026
CISA đưa vào danh sách lỗ hổng đã bị khai thác. Cùng ngày GitLab phát hành bản mới nhất (19.5.3…)

5 bước kiểm tra và xử lý

Xác định GitLab đang chạy ở đâu
Trên máy chủ của công ty, trên đám mây (AWS…) hay là GitLab.com? Nếu mã nguồn do bên phát triển giữ, có thể nó nằm trên GitLab của họ.
Xem phiên bản
Đăng nhập GitLab, mở "Help" → "Help" ở cuối thanh menu bên trái; phiên bản (ví dụ 19.4.1) hiện ở trên cùng.
Cập nhật lên bản mới nhất của nhánh
Lên tới cột "Nên lên" trong bảng trên. Nếu không cài bằng gói chính thức, kiểm tra cả phiên bản Ruby.
Tìm dấu vết bị tấn công
Xem log trước và sau khi cập nhật: có lỗi "502" ngay sau các truy cập tới chức năng kiểm tra cấu hình CI (lint) không, tiến trình xử lý của GitLab có tự khởi động lại bất thường không, có tài khoản lạ mới đăng ký không.
Có dấu hiệu khả nghi thì thay khóa và mật khẩu
Đổi mật khẩu, token truy cập lưu trong GitLab và thông tin đăng nhập máy chủ thật. Alpine Linux đã dựng lại máy chủ, đổi mật khẩu toàn bộ người dùng và thay các khóa bí mật của GitLab.

Chưa cập nhật ngay được thì làm gì trước?

Tắt chức năng ai cũng tự đăng ký được, không cho người lạ tạo hoặc ghi vào dự án công khai, chặn truy cập giao diện GitLab từ bên ngoài công ty. Những việc này giúp khó bị tấn công hơn nhưng không sửa được lỗ hổng. Chỉ dùng tạm cho tới khi cập nhật.

Nếu mã nguồn đang do bên phát triển giữ

Dù công ty bạn không dùng GitLab, đơn vị phát triển hoặc bảo trì vẫn thường quản lý mã nguồn của bạn trên GitLab của họ. Nên hỏi họ những điều sau:

Mã nguồn của chúng tôi đang lưu ở đâu (GitLab.com hay máy chủ của anh chị)?
GitLab của anh chị đã vá CVE-2026-97229 và CVE-2026-110264 chưa?
Trong GitLab có lưu mật khẩu, khóa của máy chủ hoặc tài khoản đám mây của chúng tôi không?
Anh chị đã kiểm tra log xem có dấu vết bị tấn công chưa?
Chúng tôi có thể nhận và tự lưu một bản mã nguồn mới nhất không?

Nếu không liên lạc được với bên phát triển, hoặc không có mã nguồn trong tay, hãy xem thêm bài "Tiếp nhận bảo trì hệ thống cũ không có tài liệu".

Để nguyên hay xử lý ngay?

Nếu để nguyên

Lỗ hổng 10.0 đang bị khai thác vẫn còn đó
Mã nguồn và mật khẩu môi trường thật có thể bị lấy cùng lúc
Từ GitLab, thiệt hại có thể lan sang máy chủ thật

Nếu cập nhật và kiểm tra dấu vết

Vá được cả hai lỗ hổng 10.0 lần này
Phát hiện sớm nếu đã có xâm nhập
Có thể trả lời đối tác rằng "đã xử lý xong"

Digi Dinos có thể giúp gì?

Digi Dinos là công ty phần mềm có văn phòng tại Việt Nam và Nhật Bản. Trong 8 năm, chúng tôi đã thực hiện hơn 150 dự án. Chính chúng tôi cũng phát triển hằng ngày trên GitLab, với đội ngũ làm việc được bằng tiếng Nhật.

Cập nhật và rà soát GitLab: kiểm tra phiên bản, cập nhật, đọc log, thay khóa và mật khẩu.
Tiếp nhận bảo trì hệ thống có sẵn: Ruby, PHP, Java, Node.js, Python, .NET…
Xử lý lỗ hổng mới công bố: khi có bản vá như lần này, chúng tôi đánh giá ảnh hưởng và áp dụng bản sửa.
Không có tài liệu cũng không sao: kể cả khi nhà cung cấp cũ đã không còn và không ai hiểu hệ thống, chúng tôi tự đọc mã nguồn, dựng lại tài liệu và đề xuất kế hoạch hoàn chỉnh.
Bảo hành vĩnh viễn: nếu phát hiện lỗi ở phần chúng tôi đã sửa, chúng tôi chịu trách nhiệm sửa, không giới hạn thời gian chừng nào hợp đồng bảo trì còn tiếp tục.

Chưa chắc GitLab của bạn đã an toàn? Tư vấn miễn phí.

Từ kiểm tra phiên bản, cập nhật đến rà soát dấu vết tấn công. Kể cả khi không liên lạc được với bên phát triển cũ.

Dịch vụ tiếp nhận hệ thống Liên hệ với chúng tôi

Câu hỏi thường gặp

Tôi dùng GitLab.com. Có cần làm gì không?

GitLab.com đã được GitLab vá, bạn không cần cập nhật gì cho lỗ hổng này. Tuy vậy vẫn nên duy trì các biện pháp cơ bản như không dùng chung mật khẩu và bật xác thực hai lớp.

GitLab chỉ dùng trong mạng nội bộ thì có nguy hiểm không?

Nếu không truy cập được trực tiếp từ Internet, rủi ro giảm đi nhiều. Nhưng nếu một máy tính trong công ty bị chiếm quyền, GitLab vẫn có thể bị lợi dụng làm bàn đạp. Vẫn nên cập nhật.

Cập nhật có làm GitLab ngừng hoạt động không?

Có thể không dùng được trong vài phút đến vài chục phút. Nên làm vào giờ đội phát triển không làm việc và sao lưu dữ liệu trước.

GitLab của tôi đã nhiều năm không cập nhật.

Từ bản cũ lên bản mới nhất phải đi qua từng mốc theo thứ tự quy định. Việc sao lưu và lập kế hoạch rất quan trọng; nếu chưa tự tin, hãy nhờ đơn vị chuyên môn.

Nguồn tham khảo