Số lỗ hổng bảo mật năm 2026 vượt 100.000, nhờ AI

Số lượng lỗ hổng bảo mật được công bố trong năm 2026 đã vượt mốc 100.000, hơn gấp đôi tổng số của cả năm 2025. Theo các chuyên gia, nguyên nhân chính nằm ở hai chữ: AI.

Việc săn lỗ hổng bằng trí tuệ nhân tạo đang làm thay đổi hoàn toàn cách ngành bảo mật vận hành, đồng thời đặt ra yêu cầu cấp bách phải thay đổi cách quản lý và vá lỗi.

AI đẩy số lượng CVE lên mức kỷ lục

Số lượng CVE (Common Vulnerabilities and Exposures – mã định danh chung cho các lỗ hổng bảo mật) được phát hiện và công bố trong năm 2026 đã vượt 100.000 vào thứ Sáu, hơn gấp đôi tổng số của năm 2025.

Theo VulnCheck, tính đến khoảng 16 giờ UTC ngày thứ Sáu, con số này là 100.222 CVE. Chỉ riêng Microsoft đã bổ sung 1.094 lỗ hổng vào hôm thứ Ba, sau 1.474 lỗ hổng của tháng trước.

Ông Josh Bressers, giám đốc bộ phận công bố lỗ hổng phối hợp của VulnCheck, nhận định với The Register:

"Điều khiến tôi gần như sợ hãi là dù 100K nghe có vẻ nhiều, vài năm nữa chúng ta sẽ nói: nhớ hồi đó con số chỉ có 100K thôi không?"

Theo ông, không thể phủ nhận việc săn lỗ hổng bằng AI đang thúc đẩy phần lớn số lượng này. Các CNA (CVE Numbering Authority – tổ chức được chương trình CVE ủy quyền cấp mã định danh cho lỗ hổng) lớn như VulnCheck, Microsoft, Oracle, GitHub và nhiều nhà cung cấp IT doanh nghiệp khác đều đang bùng nổ về số lượng công bố.

Tỷ lệ khai thác ổn định, nhưng quy mô thì không

Tỷ lệ lỗ hổng bị khai thác thực tế ngoài môi trường vẫn khá ổn định. Khoảng 1,4% (1.363) số CVE công bố năm nay đã được thêm vào danh mục KEV (Known Exploited Vulnerabilities – lỗ hổng đã biết bị khai thác) của VulnCheck.

Tuy nhiên, ông Bressers lưu ý: 1% của 1.000 khác rất nhiều so với 1% của 100.000.

Bên cạnh đó, khoảng thời gian từ khi bản vá được công bố đến khi kẻ tấn công phát triển được mã khai thác đang thu hẹp nhanh chóng, cũng nhờ AI. Kẻ tấn công thường đảo ngược (reverse engineering) bản vá trong khi người dùng vẫn đang cài đặt nó.

Từ tháng 1 đến tháng 6, CrowdStrike ghi nhận 88% các vụ khai thác dựa trên mã PoC (proof-of-concept – mã chứng minh khai thác) công khai diễn ra trong vòng 48 giờ sau khi mã được phát hành. Các nhóm được cho là liên quan đến Trung Quốc như Vault Panda và Genesis Panda thậm chí tấn công trong vòng 24 giờ sau khi công bố.

VulnCheck cũng ghi nhận thời gian trung vị từ khi công bố CVE đến khi bị khai thác giảm từ 120 ngày trong năm 2025 xuống 80 ngày trong nửa đầu năm 2026, và tiếp tục rút ngắn trong nửa cuối năm.

"Thường chỉ còn vài giờ", ông Bressers nói.

Ông dẫn ví dụ 14 lỗ hổng cho phép chiếm quyền root mà VulnCheck công bố trong các bộ điều khiển làm lạnh Copeland, trong đó hai lỗ hổng đang bị khai thác tích cực. Đây chính là thiết bị mà các hacker Iran đã lợi dụng để làm hỏng thực phẩm và gây cháy tại các siêu thị khắp châu Âu.

"Chúng tôi công bố các CVE đó, và chỉ vài phút sau đã thấy các dấu hiệu tấn công vào honeypot của mình."

Từ "vá tất cả" sang "ưu tiên theo rủi ro"

Lượng lỗ hổng tăng vọt buộc toàn ngành phải thay đổi cách tiếp cận công bố và vá lỗi.

"Chúng ta không còn vấn đề bảo mật nữa. Giờ chúng ta có vấn đề về dữ liệu", ông Bressers nói. "Thay vì ám ảnh với từng lỗ hổng, chúng ta cần bắt đầu nhìn vào những thứ như bản đồ nhiệt cho hạ tầng và xác định lỗ hổng nào thực sự ảnh hưởng đến mình."

Tháng 6, Cơ quan An ninh mạng và Hạ tầng Mỹ (CISA) ban hành chỉ thị thay thế chính sách quản lý lỗ hổng theo hạn chót đồng loạt. Thay vì ưu tiên vá dựa trên điểm CVSS (thang điểm đánh giá mức độ nghiêm trọng), chỉ thị yêu cầu tổ chức ưu tiên theo tiêu chí rủi ro cụ thể: tài sản có phơi ra internet không, có đang bị khai thác tích cực không, và kẻ tấn công có thể tự động hóa khai thác không.

Gánh nặng đè lên mã nguồn mở

Các báo cáo lỗ hổng do AI tạo ra cũng gây áp lực lớn cho các nhà phát triển và người duy trì dự án mã nguồn mở.

"Bạn có những nhà phát triển cá nhân đang chìm trong các báo cáo lỗ hổng. Bạn có các quỹ bị nghiền nát bởi AI agent quét dữ liệu hoặc tải xuống các gói của họ hàng triệu lần mỗi ngày", ông Bressers nói. "Điều chắc chắn duy nhất là: cách chúng ta làm hiện nay phải thay đổi, và phải thay đổi khá sớm."

Các dự án khác nhau có cách xử lý riêng. Eclipse Foundation, đơn vị vận hành Open VSX Registry, đã ra mắt gói "managed tier" cho khách hàng doanh nghiệp vào tháng 4, cam kết SLA (thỏa thuận mức dịch vụ) uptime 99,95%. Khách hàng gồm AWS, IBM, Google, Cursor và Windsurf. Gói trả phí này giúp người dùng thương mại tài trợ cho việc duy trì registry, qua đó bảo vệ cả bảo mật và hiệu năng nền tảng của chính họ.

Trong khi đó, Daniel Stenberg, người duy trì curl, với lý do "bão báo cáo lỗ hổng", đã cập nhật quy định báo lỗi vào tháng trước. Từ ngày 26/10, mọi báo cáo lỗ hổng mức thấp và trung bình được đưa thẳng vào kho GitHub công khai, chỉ các lỗ hổng cao và nghiêm trọng mới được xử lý riêng tư. Stenberg cũng đã đóng chương trình bug bounty của curl trong năm nay vì các bài gửi do AI tạo ra làm quá tải đội ngũ bảo mật.

"Không ai muốn là người đầu tiên nhảy vào cái hồ đầy cá sấu. Đó là một trong những thách thức của chúng ta", ông Bressers nói.

Góc nhìn

Với các đội phát triển và vận hành tại Việt Nam, việc số lượng lỗ hổng tăng theo cấp số nhân trong khi thời gian bị khai thác rút xuống còn vài giờ đã làm thay đổi cách cần ưu tiên công việc. Việc theo đuổi mục tiêu "vá hết các lỗ hổng nghiêm trọng" trở nên bất khả thi khi mà chỉ riêng một nhà cung cấp đã công bố hơn 1.000 lỗ hổng mỗi tháng.

Cách tiếp cận thực tế hơn là lập bản đồ tài sản: hệ thống nào phơi ra internet, đang dùng thành phần mã nguồn mở nào, và lỗ hổng nào thực sự nằm trong đường tấn công. Áp dụng tiêu chí ưu tiên theo rủi ro tương tự chỉ thị của CISA giúp đội ngũ tập trung nguồn lực vào những lỗ hổng có khả năng bị khai thác tự động và đang bị khai thác thực tế.

Bài học từ các dự án mã nguồn mở như curl cũng đáng lưu ý: khi công cụ AI hạ thấp chi phí tạo báo cáo lỗ hổng, quy trình tiếp nhận và xử lý của chính đội ngũ nội bộ cũng cần được thiết kế lại để tránh bị quá tải bởi những báo cáo chất lượng thấp.