Khi AI bắt đầu ghép các CVE cũ thành kỹ thuật tấn công mới
Tổng quan
Một chiếc laptop thông thường với đường truyền Internet 100 Mbps có thể khiến một máy chủ web sở hữu 32 GB RAM rơi vào trạng thái cạn kiệt tài nguyên chỉ trong vài giây. Nghe có vẻ giống một cuộc tấn công DDoS quy mô lớn, nhưng thực tế kẻ tấn công chỉ cần duy trì một số ít kết nối HTTP/2 được thiết kế đặc biệt.
Đó chính là điều mà kỹ thuật mới mang tên HTTP/2 Bomb đã chứng minh. Không khai thác một zero-day phức tạp, không cần vượt qua cơ chế xác thực hay sử dụng hạ tầng botnet khổng lồ, HTTP/2 Bomb tận dụng các tính năng hoàn toàn hợp lệ của giao thức HTTP/2 để buộc máy chủ liên tục cấp phát và giữ lại lượng lớn bộ nhớ. Kết quả là các nền tảng phổ biến như Apache httpd, NGINX, Microsoft IIS và Envoy có thể bị suy giảm hiệu năng nghiêm trọng hoặc ngừng cung cấp dịch vụ trong thời gian rất ngắn.
Điều khiến cộng đồng an toàn thông tin đặc biệt chú ý không chỉ nằm ở mức độ ảnh hưởng của lỗ hổng mà còn ở cách nó được phát hiện. Theo các nhà nghiên cứu của Calif, kỹ thuật này được khám phá với sự hỗ trợ của AI khi kết hợp nhiều cơ chế và lỗ hổng đã được biết đến từ nhiều năm trước thành một chuỗi tấn công hoàn chỉnh. HTTP/2 Bomb cho thấy rằng ngay cả những đặc tính tưởng chừng vô hại của một giao thức phổ biến cũng có thể trở thành vũ khí nguy hiểm khi được kết hợp đúng cách.
Bối cảnh kỹ thuật
Tấn công HTTP/2 Bomb được phát hiện bởi công ty bảo mật Calif thông qua việc sử dụng công cụ OpenAI Codex để chuỗi hóa hai kỹ thuật tấn công cũ. Lỗ hổng đã được gán các mã định danh sau:
CVE-2026-49975 (Apache httpd mod_http2): Điểm CVSS v3 đạt 7.5 (High). Ảnh hưởng đến mod_http2 trên Apache httpd phiên bản từ 2.4.17 đến 2.4.67.
CVE-2026-47774 (Envoy): Điểm CVSS v3 đạt 7.5 (High). Ảnh hưởng đến cơ chế xử lý downstream request.
CVE-2026-49160 (Microsoft IIS): Điểm CVSS v3 đạt 7.8 (High). Được Microsoft vá trong bản cập nhật tháng 6/2026.
NGINX: Không có mã CVE riêng nhưng bị ảnh hưởng ở tất cả các phiên bản trước 1.29.8.
CWE liên quan: CWE-400 (Uncontrolled Resource Consumption) - Cạn kiệt tài nguyên hệ thống ngoài tầm kiểm soát.
Kẻ tấn công sử dụng vectơ mạng (Network) để gửi các frame HTTP/2 độc hại qua cổng HTTPS (thường là port 443). Tấn công không yêu cầu đặc quyền (pre-auth) và không cần tương tác từ phía người dùng cuối.
Cơ chế khai thác
Để hiểu rõ HTTP/2 Bomb, chúng ta cần phân tích hai thành phần cốt lõi của giao thức HTTP/2: nén HPACK và kiểm soát luồng (flow control).
HPACK (RFC 7541): Là cơ chế nén header có trạng thái. Cả máy chủ và máy khách đều duy trì một bảng động (dynamic table) lưu trữ các header đã thấy gần đây. Máy khách có thể chèn một header vào bảng này một lần, sau đó chỉ cần tham chiếu bằng index (thường chỉ tốn 1 byte) trong các request tiếp theo.
Flow Control (RFC 9113): Hỗ trợ kiểm soát luồng dữ liệu trên từng stream. Máy chủ không được gửi dữ liệu vượt quá kích thước cửa sổ (window size) do máy khách quảng cáo cho đến khi nhận được frame
WINDOW_UPDATE. Kẻ tấn công có thể lợi dụng điều này để giữ kết nối phản hồi từ máy chủ luôn ở trạng thái chờ (stall).
Sự khác biệt giữa HPACK Bomb truyền thống và HTTP/2 Bomb
Trong cuộc tấn công HPACK Bomb cổ điển (như CVE-2016-6581), kẻ tấn công đưa một giá trị header rất lớn vào bảng động và tham chiếu nó liên tục. Các máy chủ hiện đại đã phòng chống điều này bằng cách giới hạn tổng kích thước giải nén tối đa của header field (decoded header size).
Biến thể HTTP/2 Bomb đi theo hướng ngược lại:
Kẻ tấn công gửi các header gần như rỗng để vượt qua các bộ lọc kích thước giải nén.
Sự khuếch đại không đến từ nội dung dữ liệu, mà đến từ chi phí quản lý bộ nhớ (bookkeeping overhead) mà máy chủ phải phân bổ cho mỗi entry được tạo ra. Một byte truyền trên đường truyền có thể tương ứng với hàng ngàn byte được cấp phát trong RAM máy chủ.
Để giữ các tài nguyên này không bị giải phóng, kẻ tấn công quảng cáo một cửa sổ nhận dạng bằng 0 (
zero-byte flow-control window). Máy chủ không thể hoàn tất request và buộc phải giữ các vùng nhớ đã cấp phát trong RAM. Đồng thời, kẻ tấn công định kỳ gửi các frameWINDOW_UPDATEkích thước 1-byte để reset thời gian chờ (timeout) của kết nối.
Bypass qua cơ chế Cookie Crumbs
Đối với các máy chủ giới hạn số lượng header fields (như Apache và Envoy), kẻ tấn công sử dụng kỹ thuật Cookie Crumbs. Theo đặc tả RFC 9113 §8.2.3, Cookie header được phép phân tách thành nhiều trường nhỏ trên các stream khác nhau. Do các máy chủ này không tính các phần nhỏ (crumbs) này vào giới hạn số lượng header tối đa, kẻ tấn công có thể chèn hàng chục ngàn crumbs cookie vào bộ nhớ.
Envoy: Nối toàn bộ crumbs vào một buffer chung. Một cookie 4KB được tham chiếu 32.000 lần sẽ tạo ra tỷ lệ khuếch đại bộ nhớ thực tế (RSS ratio) từ ~3,800:1 đến ~5,700:1 do chi phí phân bổ của bộ cấp phát bộ nhớ.
Apache httpd: Thiết kế của
mod_http2tái xây dựng lại toàn bộ chuỗi cookie gộp mỗi khi nhận thêm một crumb, đồng thời giữ lại bản sao cũ trong suốt vòng đời của stream. Thiết kế này khiến ngay cả một cookie rỗng cũng tạo ra tỷ lệ khuếch đại tài nguyên lên đến ~4,000:1.
| Máy chủ | Tỷ lệ khuếch đại bộ nhớ | Kết quả thử nghiệm thực tế |
|---|---|---|
| Envoy 1.37.2 | ~5,700:1 | Tiêu tốn ~32 GB RAM trong ~10 giây |
| Apache httpd 2.4.67 | ~4,000:1 | Tiêu tốn ~32 GB RAM trong ~18 giây |
| nginx 1.29.7 | ~70:1 | Tiêu tốn ~32 GB RAM trong ~45 giây |
| Microsoft IIS (Windows Server 2025) | ~68:1 | Tiêu tốn ~64 GB RAM trong ~45 giây |
Mã PoC thực tế
publications/MADBugs/http2-bomb at main · califio/publications
Quy trình khai thác chi tiết
Bước 1: Thiết lập kết nối TCP & Thỏa thuận HTTP/2 (Connection & ALPN Negotiation) Kẻ tấn công khởi tạo kết nối TCP thông thường tới cổng HTTPS (443) của máy chủ và thỏa thuận giao thức HTTP/2 thông qua ALPN (Application-Layer Protocol Negotiation). Sau khi bắt tay TLS thành công, bảng nén động HPACK được thiết lập ở trạng thái rỗng trên cả hai đầu kết nối.
Bước 2: Nạp dữ liệu mồi vào bảng động (Dynamic Table Seeding) Kẻ tấn công gửi request đầu tiên chứa các giá trị Cookie hoặc Custom Header kích thước lớn (ví dụ: chuỗi cookie dài 4KB hoặc các chuỗi định dạng đặc biệt) để mồi dữ liệu vào bảng động HPACK của máy chủ. Lúc này, máy chủ phân bổ bộ nhớ tương ứng để lưu trữ các cặp Name-Value này.
Bước 3: Gửi các tham chiếu chỉ mục nén khuếch đại (Indexed Reference Bombing) Sau khi dữ liệu mồi đã nằm trong bảng động, kẻ tấn công liên tục gửi các frame header tiếp theo chứa hàng ngàn tham chiếu chỉ mục (index references) trỏ đến phần tử mồi đã lưu.
Trên đường truyền (wire format), mỗi tham chiếu chỉ tốn 1 byte.
Tuy nhiên, khi giải nén, máy chủ buộc phải phân bổ tài nguyên bộ nhớ cho các cơ chế quản lý nội bộ (bookkeeping) xung quanh mỗi entry (từ 70 byte đến 4.000 byte tùy cấu trúc của web server). Việc gửi cookie crumbs phân mảnh giúp bypass qua các bộ lọc số lượng trường header (
header field count limit).
Bước 4: Đóng băng cửa sổ phản hồi (Flow-Control Window Stall) Trước khi máy chủ hoàn tất xử lý và giải phóng tài nguyên, kẻ tấn công gửi một cấu hình cài đặt hoặc frame điều khiển luồng quảng cáo kích thước cửa sổ nhận dạng bằng 0 (zero-byte flow-control window). Máy chủ nhận thấy bộ đệm nhận của client đã đầy, do đó bị dừng luồng phản hồi dữ liệu (stalled) nhưng vẫn phải giữ toàn bộ vùng nhớ RAM đã cấp phát ở Bước 3.
Bước 5: Duy trì trạng thái ghim bộ nhớ (Session Pinning / Heartbeat Stall) Để ngăn máy chủ đóng kết nối do timeout (inactivity timeout), kẻ tấn công liên tục gửi "nhỏ giọt" các frame WINDOW_UPDATE kích thước 1-byte hoặc các frame ping nhỏ để reset các bộ đếm thời gian chờ của socket. Bộ nhớ đã phân bổ của máy chủ bị ghim (pinned) liên tục trong RAM và không thể giải phóng.
Bước 6: Cạn kiệt tài nguyên (Memory Exhaustion & DoS) Bằng cách chạy song song nhiều luồng (streams) như trên trong cùng một kết nối hoặc trên nhiều kết nối đồng thời từ một đường truyền băng thông nhỏ, tài nguyên RAM của hệ thống nhanh chóng bị cạn kiệt, đẩy máy chủ vào trạng thái Swap hoặc bị hệ điều hành OOM-killed.
Ghi nhận khai thác thực tế
Điểm đặc biệt của HTTP/2 Bomb là việc sử dụng mô hình trí tuệ nhân tạo (OpenAI Codex) để kết hợp các mẫu thiết kế lỗi bảo mật vốn đã xuất hiện từ lâu.
Vào tháng 4/2026, nhóm nghiên cứu tại Calif dẫn đầu bởi Quang Luong đã báo cáo lỗ hổng cho NGINX, tiếp đó là Apache httpd vào ngày 27/05/2026. Lỗ hổng đã được điều phối vá lỗi nhanh chóng bởi các nhà phát triển.
Cho đến nay, chưa có báo cáo xác thực về việc lỗ hổng này bị các nhóm APT khai thác ngoài thực tế trước thời điểm công bố. Tuy nhiên, do mã khai thác PoC đã được công khai và các thay đổi sửa lỗi (commits) trên các kho mã nguồn mở của NGINX/Apache đều hiển thị rõ bản chất lỗi, nguy cơ weaponize lỗ hổng này của các nhóm tấn công là cực kỳ cao.
MITRE ATT&CK Mapping
Dưới đây là sơ đồ ánh xạ hành vi tấn công của HTTP/2 Bomb vào ma trận MITRE ATT&CK:
| Tactic | Technique | Mô tả |
|---|---|---|
| Impact (TA0040) | T1499 - Endpoint Denial of Service | Làm tê liệt hệ thống máy chủ cung cấp dịch vụ công cộng. |
| Impact (TA0040) | T1499.003 - Application Exhaustion Flood | Sử dụng các request HTTP/2 hợp lệ nhưng độc hại để làm cạn kiệt tài nguyên RAM. |
Phát hiện & Phản ứng
Logic phát hiện (SIEM/IDS)
Để phát hiện cuộc tấn công HTTP/2 Bomb, đội ngũ SOC cần giám sát các dấu hiệu bất thường sau:
Giám sát các kết nối HTTP/2 duy trì trong thời gian dài nhưng băng thông truyền tải dữ liệu cực thấp (Slowloris-style).
Sự gia tăng đột biến của các frame
WINDOW_UPDATEkích thước tối thiểu (1 byte) trên một kết nối duy nhất.Số lượng header cookie phân mảnh (crumbs) lớn bất thường trên một stream.
Đoạn Splunk query dưới đây hỗ trợ xác định lưu lượng HTTP/2 đáng ngờ dựa trên dấu hiệu phân mảnh cookie:
Quy trình phản ứng sự cố (Incident Response)
Nếu hệ thống giám sát cảnh báo tài nguyên RAM của Web Server bị cạn kiệt liên tục:
Cô lập nguồn tấn công: Thực hiện chặn IP nguồn gửi lượng lớn request HTTP/2 thông qua WAF hoặc tường lửa biên.
Giới hạn tài nguyên khẩn cấp: Cấu hình cgroups hoặc ulimit trên máy chủ để giới hạn lượng RAM tối đa của mỗi worker process, ngăn không cho một worker bị bomb kéo sập toàn bộ hệ điều hành vào trạng thái swap.
Chuyển đổi tạm thời: Nếu chưa thể cập nhật phần mềm, chuyển hướng cấu hình máy chủ tắt giao thức HTTP/2, chỉ chấp nhận kết nối HTTP/1.1.
Nhận định chuyên gia
Đội ngũ phân tích của chúng tôi nhận thấy các đặc tả giao thức thường là nguồn gốc của các lỗ hổng logic nghiêm trọng. RFC 7541 khi đặc tả HPACK đã thiết kế rất kỹ để giới hạn bảng động nhằm tránh cạn kiệt bộ nhớ, nhưng các nhà thiết kế giao thức lại bỏ quên chi phí quản lý các cấu trúc dữ liệu phát sinh xung quanh các entry này.
Việc bỏ sót yếu tố thời gian duy trì bộ nhớ (connection duration) cũng là một điểm yếu thiết kế lớn. Một bộ khuếch đại nén nhỏ (như 70:1 của NGINX) sẽ vô hại nếu bộ nhớ được giải phóng ngay khi request hoàn tất. Nhưng nếu giao thức cho phép kẻ tấn công duy trì kết nối gần như miễn phí bằng Window Stall, lượng bộ nhớ đó sẽ bị ghim lại vô thời hạn, tạo nên một cuộc tấn công từ chối dịch vụ hoàn hảo.
Tại thị trường Việt Nam, chúng tôi nhận thấy rất nhiều hệ thống của doanh nghiệp vừa và nhỏ sử dụng các bản phân phối Linux cũ hoặc cài đặt Web Server thủ công và không có cơ chế tự động cập nhật bản vá định kỳ. Những hệ thống này sẽ là mục tiêu dễ bị ảnh hưởng nhất khi các công cụ quét lỗ hổng tự động tích hợp mã khai thác HTTP/2 Bomb.
Một điểm đáng chú ý khác là vai trò của AI. Việc OpenAI Codex tự động phát hiện ra lỗ hổng bằng cách kết hợp hai kỹ thuật độc lập cho thấy các mô hình ngôn ngữ lớn (LLM) đã vượt ra khỏi vai trò hỗ trợ viết code thông thường. Chúng đã bắt đầu có khả năng phân tích logic luồng nghiệp vụ phức tạp để tự động sinh ra các chuỗi khai thác liên hoàn (exploit chains). Điều này đặt ra thách thức lớn cho các đội ngũ phòng thủ khi tốc độ tìm kiếm lỗ hổng của kẻ tấn công được đẩy nhanh gấp nhiều lần nhờ AI.
Khuyến nghị hành động
Tức thời (0-24 giờ)
NGINX: Cập nhật lên phiên bản 1.29.8 hoặc mới hơn. Nếu chưa thể cập nhật, cấu hình tắt HTTP/2 bằng cách loại bỏ từ khóa
http2trong cấu hìnhlistenhoặc thiết lậphttp2 off;.Apache httpd: Cập nhật module
mod_http2lên phiên bản v2.0.41+. Nếu không thể cập nhật, loại bỏ cấu hình HTTP/2 bằng cách đặt:Protocols http/1.1Envoy: Áp dụng ngay bản vá trong các phiên bản 1.35.11, 1.36.7, 1.37.3, 1.38.1.
Microsoft IIS: Tiến hành cài đặt bản vá Patch Tuesday tháng 6/2026 (CVE-2026-49160) trên hệ điều hành Windows Server bị ảnh hưởng.
Ngắn hạn (1-7 ngày)
Cấu hình giới hạn bộ nhớ của worker process ở mức hệ điều hành sử dụng cgroups (đối với Linux) hoặc
ulimit -v. Đảm bảo rằng khi một tiến trình tiêu tốn quá giới hạn RAM cho phép, hệ điều hành sẽ tự động giải phóng tiến trình đó thông qua OOM-killer và khởi động lại tiến trình mới thay vì kéo toàn bộ hệ thống vào trạng thái treo.Cấu hình các thiết bị WAF/Reverse Proxy phía trước để áp dụng chính sách giới hạn nghiêm ngặt số lượng header tối đa trên mỗi request (bao gồm cả các phần cookie rời rạc).
Dài hạn
Xây dựng quy trình tự động cập nhật bản vá hệ điều hành và các phần mềm máy chủ biên (edge servers) theo định kỳ tối thiểu hàng tháng.
Thiết lập hệ thống giám sát hiệu năng tài nguyên (RAM, CPU, Swap) và cảnh báo tự động khi các chỉ số này vượt ngưỡng an toàn trong thời gian ngắn để kích hoạt sớm quy trình ứng phó sự cố.
Tham khảo
New HTTP/2 Bomb Vulnerability Allows Remote DoS on NGINX, Apache, IIS, Envoy & Cloudflare
New 'HTTP/2 Bomb' DoS attack crashes web servers in under a minute
Codex Discovered a Hidden HTTP/2 Bomb - Calif
publications/MADBugs/http2-bomb at main · califio/publications
