Bản vá bảo mật nay cần... bản vá: Lỗ hổng từ chính những bản sửa lỗi gia tăng khi tin tặc dùng AI

Việc cập nhật phần mềm lâu nay vẫn được xem là biện pháp phòng thủ cơ bản nhất, nhưng theo nghiên cứu mới của Terra Security, chính những bản vá bảo mật đang ngày càng dễ bị vượt qua. Tỷ lệ bản sửa lỗi bị qua mặt trên GitHub đã tăng từ khoảng 0,2% lên 2,3% chỉ trong năm 2026, và đây không phải sự trùng hợp khi AI đang thay đổi cách cả kẻ tấn công lẫn nhà phát triển làm việc.

Khi bản vá trở thành rủi ro mới

Terra Security — một startup chuyên kiểm thử xâm nhập bằng AI — đã rà soát toàn bộ các bản ghi CVE được công bố cùng các advisory được kiểm duyệt trên GitHub để tìm ra những bản sửa lỗi "hỏng". Kết quả cho thấy một mô hình đáng lo ngại: sau sáu năm tỷ lệ vượt bản vá tương đối thấp, năm 2026 chứng kiến sự gia tăng rõ rệt của vòng lặp "một bản vá được tung ra, một cách vượt qua bị phát hiện, và một bản vá khác lại được phát hành."

Một ví dụ điển hình là trường hợp nhóm gián điệp mạng của chính phủ Nga khai thác lỗ hổng zero-day trong Windows Shell (CVE-2026-21510) trước khi Microsoft vá vào tháng 2/2026 ít nhất một tháng. Tuy nhiên, bản vá của Redmond chưa đầy đủ và để lộ một lỗ hổng thứ hai — lỗ hổng cưỡng chế xác thực zero-click (CVE-2026-32202) — cũng bị khai thác trước khi được sửa vào tháng 4.

Những con số đáng báo động

Theo số liệu của Terra, tỷ lệ bản sửa lỗi bảo mật trên GitHub cần thêm advisory báo cáo thất bại trong vòng 90 ngày đã nhảy vọt:

• Giai đoạn 2019–2025: duy trì ở mức khoảng 0,2%
• Năm 2026: tăng lên 2,3%

Đáng chú ý hơn, những lỗ hổng có bản vá bị vượt qua có xác suất xuất hiện trong danh sách Known Exploited Vulnerabilities (KEV) của CISA cao gấp khoảng bốn lần so với các lỗi khác ảnh hưởng đến cùng nhà cung cấp.

Loại lỗ hổng nào dễ "vá hỏng" nhất?

Nghiên cứu chỉ ra hai nhóm lỗ hổng có bản vá dễ bị bypass nhất:

• Prototype pollution: phổ biến gấp khoảng 11 lần trong nhóm CVE có bản vá hỏng so với tỷ trọng chung
• Server-side request forgery (SSRF): phổ biến gấp 4,6 lần

Lý do nằm ở cách xử lý hai nhóm lỗi này — thường dùng danh sách chặn (blocklist) các đầu vào như tên máy chủ, đường dẫn và khóa đối tượng. Như chuyên gia Terra nhận định:

"Nếu danh sách chặn không lường trước mọi cách mã hóa của một đầu vào xấu, kẻ tấn công chỉ cần tìm ra một cách là đủ."

Ngoài ra, các bản vá cho lỗ hổng nhân Linux cũng có xu hướng tạo ra lỗi mới. Theo ghi nhận của kernel CNA tính đến ngày 8/10, có tới 3,2% CVE của nhân Linux được sinh ra từ chính bản vá cho một CVE khác, và con số này lên tới khoảng 10% ở những phân hệ bận rộn như fs/smb và net/sched.

Vì sao AI khiến mọi thứ thay đổi?

Sự gia tăng này trùng khớp với năm mà việc phát hiện lỗ hổng và tạo bản vá bằng AI đều bùng nổ. Khi các mô hình AI có thể quét mã nguồn, sinh bản vá và tìm cách vượt qua bản vá với tốc độ vượt xa con người, khoảng thời gian "an toàn" sau khi vá bị thu hẹp đáng kể. Kẻ tấn công có công cụ mạnh hơn để đọc bản vá và tìm đường vòng, trong khi nhà phát triển cũng có công cụ nhanh hơn để tạo ra — nhưng đôi khi là những bản vá chưa đủ chắc.

Bài học cho nhà phát triển và quản trị viên

Theo Terra, cần phá bỏ thói quen "vá xong là xong". Trước khi phát hành bản vá, nhà cung cấp phần mềm nên tự đặt ba câu hỏi:

• Bản vá có xử lý tận gốc nguyên nhân không?
• Bản vá có bao phủ toàn bộ nhóm lỗi không?
• Bản vá có vô tình phá vỡ thứ gì khác không?

Với quản trị viên hệ thống và người quản lý bản vá, lời khuyên cũng tương tự trước khi áp dụng bản sửa lỗi. Như các chuyên gia kiểm thử xâm nhập của Terra cảnh báo:

"Nếu nhà cung cấp vá một lỗ hổng đang bị khai thác, hãy giả định rằng đang có ai đó đọc bản vá để tìm cách vòng qua nó."

Góc nhìn cho doanh nghiệp Việt Nam

Với các doanh nghiệp Việt Nam — đặc biệt những đơn vị vận hành hệ thống thương mại điện tử, fintech và hạ tầng cloud — bài học này càng trở nên cấp thiết. Tư duy "cập nhật phần mềm là đủ an toàn" đã không còn đúng trong bối cảnh tấn công có sự hỗ trợ của AI. Việc chủ động đánh giá lại các bản vá đã triển khai, theo dõi các nguồn cảnh báo như KEV của CISA và thực hiện kiểm thử định kỳ nên được đưa vào quy trình vận hành an toàn thông tin, thay vì chỉ dựa vào thông báo vá lỗi từ nhà cung cấp.