Tuần lễ bảo mật hỗn loạn: Khi AI rút ngắn thời gian từ phát hiện lỗ hổng đến bị khai thác xuống còn vài giờ

Chỉ trong khoảng một tuần cuối tháng 10/2026, giới công nghệ chứng kiến một loạt sự cố bảo mật nghiêm trọng diễn ra gần như đồng thời: lỗ hổng PHP2Shell ảnh hưởng tới hàng chục nghìn website, chứng chỉ số yếu đến khó tin của eMudhra, lỗi RCE mức tối đa trong GitLab và musl libc, gói LiteLLM trên PyPI bị chèn mã độc, và vụ rò rỉ 10,6 TB dữ liệu từ PingCAP.

Điều đáng chú ý nhất không nằm ở từng sự cố riêng lẻ, mà ở tốc độ: các mô hình AI đang biến khoảng thời gian từ lúc một lỗ hổng được công bố đến khi bị khai thác hàng loạt từ vài tuần hoặc vài tháng xuống còn vài giờ, thậm chí vài phút. Đây có thể là "trạng thái bình thường mới" của ngành bảo mật phần mềm.

Minh họa về các lỗ hổng bảo mật phần mềm

PHP2Shell: lỗ hổng "lớn" của tuần

Hai lỗ hổng thực thi mã từ xa (RCE) mang mã CVE-2026-109618 và CVE-2026-109619 được phát hiện bởi hai nhóm bảo mật độc lập: một nhóm thuộc công ty Calif (trong chương trình "Patch the Planet" của OpenAI) và một nhóm thuộc Wiz (trực thuộc Google Cloud). Đáng chú ý là cả hai đều sử dụng các mô hình AI tiên tiến (GPT-5.6 Sol và Gemini 4 Argon) để tìm lỗ hổng và xây dựng mã khai thác.

Trớ trêu thay, một trong hai lỗi này từng được Quỹ PHP phát hiện trong đợt kiểm toán bảo mật năm 2024 nhưng bị bỏ qua vì "không ai hình dung được cách khai thác thực tế". Đây chính là điểm mạnh của AI: biến một mô tả lỗ hổng mơ hồ thành mã khai thác hoàn chỉnh.

Ước tính PHP2Shell ảnh hưởng tới hơn 70% internet, từ Wikimedia Foundation, DeviantArt đến nhiều hệ thống của chính phủ Anh và ngân hàng Nhật Bản. Một bài đăng vô tình trên Hacker News đã làm lộ thông tin trước thời hạn, buộc Quỹ PHP phải đẩy nhanh bản vá. Nhưng trước khi bản vá kịp phát hành, lỗ hổng đã bị khai thác trong thực tế.

Điểm mấu chốt: thời điểm bạn công bố bản vá nên được coi là hạn chót cuối cùng để mã khai thác chưa bị phát tán công khai.

Tranh cãi nổ ra về vai trò của AI. Một số chuyên gia cho rằng AI tạo ra vô số mã khai thác "rác" không hoạt động được. Nhưng như LiveOverflow chỉ ra: 10.000 mã khai thác hỏng cũng không quan trọng nếu có một mã hoạt động thật. Đó là bài học đau đớn của ngành bảo mật hiện nay.

eMudhra: khóa bảo mật "115" và "4"

Cùng ngày 20/10, Mozilla chặn 8 chứng chỉ trung gian do tổ chức phát hành chứng chỉ Ấn Độ eMudhra ký. Nguyên nhân: eMudhra sử dụng khóa riêng có chất lượng thảm hại, với những con số như "115", "56" và thậm chí "4".

Lỗi này không do AI phát hiện, nhưng nhà nghiên cứu Scott Helme ghi nhận chỉ với một câu lệnh, Claude có thể khôi phục khóa riêng của các chứng chỉ trung gian trong vài mili giây. eMudhra sau đó tuyên bố rút khỏi mảng chứng chỉ SSL/TLS toàn cầu.

RFC 1149.5 quy định số 4 là số ngẫu nhiên chuẩn - từ xkcd

GitLab và musl libc: khi regex trở thành lỗ hổng nghiêm trọng

GitLab đã phát hành hai bản vá cho lỗi RCE mức độ nghiêm trọng tối đa (CVSS 10.0) liên quan đến bộ phân tích biểu thức chính quy (regex) trong CI/CD. Cả hai đều do nhà nghiên cứu Johan Carlsson báo cáo qua chương trình bug bounty HackerOne.

Cùng ngày, thư viện musl libc cũng dính lỗi tràn số nguyên trong hàm regcomp, gây từ chối dịch vụ và có thể dẫn tới thực thi mã. Câu hỏi đặt ra: liệu regex có đang trở thành mối nguy bảo mật mới, giống như cách kết xuất font chữ từng gây chấn động trước đây?

Điều đáng nói là nhiều người từng khuyên đóng các chương trình bug bounty vì AI đã khiến chúng trở nên không cần thiết. GitLab có lẽ đang biết ơn vì đã không làm vậy.

LiteLLM và vụ tấn công chuỗi cung ứng lần thứ hai

LiteLLM lại một lần nữa bị xâm phạm — lần này là phiên bản độc hại 1.107.0 trên PyPI, sử dụng tệp .pth và sitecustomize.py để tự động nạp mã độc ngay khi trình thông dịch Python khởi động.

Theo phân tích từ Wiz, mã độc mang "dấu hiệu mạnh mẽ của việc phát triển có sự hỗ trợ của AI": tên biến dài dòng quá mức, xử lý lỗi phòng thủ quá đà, các góc cạnh dễ vỡ, và những dòng chú thích kỳ lạ kiểu "đây là chỗ thực sự đau". Kẻ tấn công lấy được thông tin đăng nhập GitHub CLI, cho phép chạy các tác vụ CI trái phép.

Đáng lo ngại hơn: Claude Code đôi khi nhúng token OAuth GitHub của người dùng vào nội dung phản hồi, khiến token lộ ra trong log của LiteLLM.

PingCAP: rò rỉ 10,6 TB và khóa AWS nằm trong Jira

Ngày 19/10, công ty PingCAP (phát triển database TiDB) xác nhận bị truy cập trái phép. Nhóm tống tiền mạng FulcrumSec tuyên bố đã lấy 10,6 TB dữ liệu và công bố một phần 200 GB như "đợt phát hành đầu tiên".

Những gì họ tiết lộ về thực tiễn bảo mật của PingCAP thực sự gây sốc: khóa truy cập AWS của khách hàng nằm trong ticket Jira, log chưa được che thông tin chứa đầy API key của OpenAI, Anthropic, Gemini và xAI.

PingCAP khẳng định "không có bằng chứng dữ liệu trong TiDB bị ảnh hưởng". Nhưng xét tới khối lượng dữ liệu bị lấy, tuyên bố này khó tạo được sự yên tâm.

Ngoài lề: Linux kernel lộ lỗ hổng vì gửi nhầm danh sách

Đêm 21-22/10, Zero Day Initiative (thuộc Trend Micro) đã gửi hàng loạt báo cáo CVE nghiêm trọng (trên 9.0) của nhân Linux vào danh sách công khai thay vì danh sách bảo mật riêng tư. Với các công cụ AI hiện nay, bất kỳ ai cũng có thể biến những báo cáo này thành mã khai thác trong vài phút.

Vậy đâu là giải pháp?

Ba hướng tiếp cận đang được bàn luận:

• Đóng mã nguồn tất cả (cách làm của NHS England): mã không còn công khai thì AI không thể quét. Nhưng điều này làm tổn hại cộng đồng mã nguồn mở, không thể áp dụng cho ngôn ngữ lập trình, và chỉ có tác dụng cho đến khi bị rò rỉ.

• Chạy AI của riêng mình trước: dùng mô hình tốt hơn, nhiều tiền hơn để tìm và vá lỗ hổng trước khi kẻ tấn công làm. Vấn đề: sẽ tìm ra rất nhiều lỗi và ai đó phải sửa chúng, tốn kém khủng khiếp.

• Chuẩn hóa quy trình báo cáo và xử lý: ý tưởng đẹp nhưng khó thành hiện thực.

Có một số bài học thực tế đơn giản hơn: không bao giờ công bố chi tiết lỗ hổng nghiêm trọng trước khi bản vá sẵn sàng cài đặt. Nhưng ngay cả điều này cũng khó thực hiện khi thông tin rò rỉ từ nhiều nguồn khác nhau.

Có lẽ chúng ta cần chấp nhận một sự thật: nếu bạn đưa thứ gì đó lên internet, nó sẽ bị tấn công — và hãy lập kế hoạch dựa trên giả định đó.

Kết luận

Câu chuyện về AI và bảo mật là có thật. AI đang thay đổi ngành phần mềm, và chưa rõ là theo hướng tốt hơn hay xấu hơn. Có những người lạc quan cho rằng khi AI viết mã từ đầu, phần mềm sẽ an toàn hơn vì AI viết mã an toàn giỏi hơn con người. Nhưng lập luận này chưa thuyết phục.

Điều chắc chắn là ngành công nghiệp phần mềm sẽ thay đổi, mã nguồn mở sẽ thay đổi. Và trách nhiệm tập thể của cộng đồng công nghệ là đảm bảo sự thay đổi đó mang lại lợi ích cho tất cả mọi người, chứ không chỉ cho các tập đoàn lớn và những lợi ích đặc biệt.

Với các doanh nghiệp và nhà phát triển Việt Nam, bài học rất rõ ràng: cập nhật bản vá ngay khi có thể, không trì hoãn các bản cập nhật bảo mật vì lo ngại ảnh hưởng hệ thống, và đừng bao giờ để thông tin xác thực nhạy cảm trong các công cụ quản lý công việc như Jira hay trong log hệ thống.