Máy chủ Apache của bạn có bị ảnh hưởng bởi CVE-2026-119618 không? Cách kiểm tra và khắc phục lỗ hổng HTTP/2

CVE-2026-119618 là lỗ hổng gì của Apache và nghiêm trọng đến mức nào?

CVE-2026-119618 là lỗ hổng mức nghiêm trọng (critical) trong mod_http2, mô-đun HTTP/2 của Apache HTTP Server. Lỗi nằm trong hàm assign_headers(). Apache mô tả đây là lỗi xử lý đồng thời thiếu đồng bộ hóa, làm hỏng vùng nhớ heap và có thể dẫn đến thực thi mã từ xa ^[1]. Dự án Apache đã sửa lỗi trong bản 2.4.71, phát hành ngày 11/11/2026 ^[1].

Red Hat chấm lỗ hổng 9,8 điểm theo CVSS phiên bản 3.1 và xếp loại Critical, kẻ tấn công không cần xác thực ^[2]. Với RHEL 9 và RHEL 10, Red Hat hạ xuống mức Important, vì mỗi stream HTTP/2 ở đó dùng bộ cấp phát bộ nhớ riêng nên việc khai thác khó hơn ^[2].

Red Hat giải thích nguyên nhân gốc như sau. HTTP/2 cho phép client gửi nhiều yêu cầu cùng lúc qua một kết nối, và mod_http2 xử lý chúng trên nhiều thread ^[2]. Một thread xử lý ghi vào vùng nhớ thuộc về thread kết nối, thông qua bộ cấp phát dùng chung không có khóa, nên bộ nhớ của máy chủ bị hỏng ^[2]. Kết quả là kẻ tấn công chạy được lệnh từ xa mà không cần đăng nhập ^[2].

Những phiên bản Apache nào bị ảnh hưởng?

Apache HTTP Server từ 2.4.55 đến 2.4.70 bị ảnh hưởng, và 2.4.71 là bản đã sửa ^[1]. Mô-đun mod_h2 độc lập trên GitHub bị ảnh hưởng từ 2.0.8 đến 2.0.42 ^[1]. Red Hat cho biết các bản mod_http2 trước 2.0.8 không chứa đoạn mã lỗi. RHEL 8 trở về trước nên không bị ảnh hưởng ^[2].

Dải phiên bản chỉ là bộ lọc đầu tiên. Bản dựng của từng bản phân phối có thể làm bộ lọc này sai. PrivateDevOps báo rằng Ubuntu 22.04 dùng Apache 2.4.52, thấp hơn dải bị ảnh hưởng, nhưng mô-đun được backport bên trong tự báo là mod_http2 2.0.42, nằm trong dải mô-đun bị ảnh hưởng, nên chỉ kiểm tra số phiên bản sẽ khiến bạn kết luận nhầm là an toàn ^[6]. Thông báo của chính Ubuntu liệt kê 20.04 và 22.04 là bị ảnh hưởng ^[4]. Trên hai bản này, hãy coi máy chủ là có nguy cơ ở mọi nơi HTTP/2 đang bật ^[6].

Số phiên bản cũng chưa đủ để kết luận máy chủ bị lộ. Red Hat nêu rõ: chỉ máy chủ bật HTTP/2 mới bị ảnh hưởng, còn máy chủ chỉ phục vụ HTTP/1.1 thì không có lỗ hổng ^[2].

Máy chủ của bạn có bị ảnh hưởng không?

Máy chủ bị lộ khi đồng thời đúng cả bốn điều kiện sau ^[5]:

• Bạn chạy Apache từ 2.4.55 đến 2.4.70, hoặc bản mod_http2 trên RHEL 9 và 10 cũ hơn bản đã sửa, hoặc bản Ubuntu có mô-đun backport bị ảnh hưởng.
• Mô-đun mod_http2 đã nạp.
• Bạn bật HTTP/2 qua dòng Protocols có h2 (cho TLS) hoặc h2c (cho HTTP thuần).
• Client không đáng tin truy cập được cổng đó, trực tiếp hoặc qua proxy chuyển tiếp HTTP/2 đến Apache.

Cấu hình mặc định giúp bạn phần nào. Trong image Docker httpd chính thức, dòng LoadModule của mod_http2 bị comment, còn trên Debian và Ubuntu mô-đun được cài nhưng chưa bật ^[6]. Tuy vậy, tệp cấu hình trên Debian và Ubuntu có sẵn dòng Protocols h2 h2c http/1.1, nên chạy a2enmod http2 sẽ bật HTTP/2 cho mọi site ^[6].

Làm thế nào để kiểm tra máy chủ trong năm phút?

Hãy chạy ba bước kiểm tra ngay trên máy chủ. Các lệnh lấy từ bài phân tích của Ostorlab ^[5]. Trước hết, đọc phiên bản và xem mod_http2 có được nạp không. Trên Debian và Ubuntu:

apache2 -v
apache2ctl -M | grep http2

Trên RHEL, Fedora và các bản dùng RPM khác:

httpd -v
httpd -M | grep http2

Sau đó tìm h2 hoặc h2c trong mọi dòng Protocols:

grep -R "Protocols" /etc/apache2 /etc/httpd 2>/dev/null

Nếu lệnh kiểm tra mô-đun không in ra gì, mod_http2 chưa nạp và máy chủ không bị lộ. Nếu có kết quả, hãy đọc từng dòng Protocols tìm được, vì dòng Protocols trong virtual host ghi đè dòng toàn cục ^[6].

Để xem máy chủ thực sự đàm phán giao thức nào, hãy dùng curl. Nếu phía trước có CDN hoặc proxy, hãy chạy dạng lệnh thứ hai ngay trên máy chủ, để bạn kiểm tra Apache chứ không phải proxy ^[6].

curl -sI --http2 https://example.com/ | head -1
curl -sI --http2 --resolve example.com:443:127.0.0.1 https://example.com/ | head -1

Kết quả HTTP/2 200 nghĩa là máy chủ đã đàm phán HTTP/2, còn HTTP/1.1 200 OK nghĩa là chưa ^[6]. Hai lệnh trên chỉ thử HTTP/2 qua TLS. Nếu bạn phục vụ h2c qua HTTP thuần, hãy thử riêng ^[6]:

curl -sI --http2-prior-knowledge http://127.0.0.1/ | head -1

Mỗi tên miền và virtual host có thể khác nhau, nên hãy lặp lại phép thử cho từng cái. Với container, hãy kiểm tra tiến trình đang chạy, không kiểm tra image vừa pull: dùng docker exec <container> apache2 -v trên image nền Debian, hoặc httpd -v trên image httpd chính thức ^[5].

Vì sao số phiên bản có thể gây hiểu lầm?

Các bản phân phối backport bản sửa vào số phiên bản riêng của họ, nên gói Ubuntu hoặc RHEL đã vá có thể không hiện 2.4.71 ^[5]. Trên RHEL, vấn đề rõ hơn: httpd -v vẫn báo bản 2.4 cơ sở sau khi vá, vì bản cập nhật thay đổi gói mod_http2 ^[5]. Vì vậy hãy kiểm tra gói:

rpm -q mod_http2

So kết quả với bảng bên dưới. Trên Ubuntu, so phiên bản apache2 đã cài với phiên bản nêu trong thông báo của bản phát hành bạn dùng ^[5]. Các bản dựng đã sửa của Debian thì mang số phiên bản upstream, 2.4.71-1deb12u1 và 2.4.71-1deb13u1 ^[3].

Bản phân phối nào đã có bản vá tính đến ngày 13/11/2026?

Tình trạng bản vá thay đổi nhanh. Sáng 12/11, PrivateDevOps còn thấy Debian 12 và 13 chưa có bản vá ^[6], còn trang theo dõi của Debian giờ đã liệt kê các bản dựng đã sửa ^[3]. Hai dòng AlmaLinux và cPanel ghi ngày riêng, và có thể đã đổi từ đó.

Bản phân phối	Tình trạng	Nguồn
Debian 12 bookworm	Đã sửa trong kho bảo mật: 2.4.71-1~deb12u1	Trang theo dõi Debian [3]
Debian 13 trixie	Đã sửa trong kho bảo mật: 2.4.71-1~deb13u1	Trang theo dõi Debian [3]
Debian forky (bản thử nghiệm)	Được liệt kê là có lỗ hổng ở 2.4.69-1; sid đã sửa ở 2.4.71-1	Trang theo dõi Debian [3]
Ubuntu 20.04, 22.04, 24.04, 26.04, 26.10	Thông báo cập nhật USN-9090-1 phát hành ngày 12/11	Ubuntu [4]
RHEL 9.9	Đã sửa ở mod_http2 2.0.26-7.el9_9.1	Ostorlab [5]
RHEL 10.3	Đã sửa ở mod_http2 2.0.29-5.el10_3.1	Ostorlab [5]
RHEL 8 trở về trước	Không bị ảnh hưởng	Red Hat [2]
AlmaLinux 9 và 10 (12/11)	Kho chưa có mod_http2 đã sửa	PrivateDevOps [6]
cPanel EasyApache 4 (12/11)	Lên 2.4.70 ngày 11/11, vẫn bị ảnh hưởng	PrivateDevOps [6]

Thông báo của Ubuntu nêu CVE này ảnh hưởng 20.04, 22.04, 24.04, 26.04 và 26.10 ^[4]. Bản lưu không hiện số phiên bản gói. Hãy mở USN-9090-1 để xem phiên bản áp dụng cho bản phát hành của bạn, rồi so với kết quả của dpkg -s apache2. Red Hat dẫn đến bảng gói bị ảnh hưởng cho từng sản phẩm, nên hãy xem bảng đó nếu bạn không dùng 9.9 hoặc 10.3 ^[2].

Làm thế nào để vá lỗi?

Hãy cập nhật gói, rồi khởi động lại Apache để nó nạp mô-đun đã sửa ^[6]. Ostorlab và PrivateDevOps đưa ra các lệnh sau ^[5][6]:

Trên Debian và Ubuntu:

sudo apt update
sudo apt install --only-upgrade apache2 apache2-bin
sudo systemctl restart apache2

Trên RHEL, Fedora và các bản tương thích:

sudo dnf update httpd mod_http2
sudo systemctl restart httpd

Nếu bạn biên dịch từ mã nguồn hoặc dùng tarball gốc, hãy chuyển lên 2.4.71, bản có mô-đun đã sửa ^[5]. Bản mod_h2 độc lập dựng từ GitHub là trường hợp riêng: PrivateDevOps báo ngày 12/11 chưa có bản sửa, bản mới nhất là 2.0.42, và khuyên tắt HTTP/2 ^[6].

Nếu bản phân phối chưa có gói vá thì làm gì?

Hãy tắt HTTP/2 cho đến khi có bản sửa. Ostorlab gọi đây là giải pháp tạm, không phải bản sửa, và nói mô-đun đã vá mới là lời giải lâu dài ^[5].

• Trên Debian và Ubuntu, chạy sudo a2dismod http2, rồi sudo apachectl configtest && sudo systemctl reload apache2 ^[6]. Bạn cũng cần xóa h2 và h2c khỏi mọi virtual host có liệt kê chúng ^[6].
• Trên RHEL và Fedora, comment dòng LoadModule http2_module, đảm bảo Protocols không liệt kê h2 hay h2c, rồi khởi động lại httpd ^[5].
• Trên mọi hệ thống, cách thứ hai là đặt rõ Protocols http/1.1 trong cấu hình chính ^[6].
• Trên mọi hệ thống, xác nhận mô-đun đã tắt bằng apache2ctl -M | grep http2 hoặc httpd -M | grep http2. Không in ra gì nghĩa là HTTP/2 đã tắt ^[5].

Thông báo của Apache không nêu giải pháp tạm nào, nên các bước trên đến từ bài phân tích của Ostorlab, không phải từ Dự án Apache ^[1][5].

CDN hoặc reverse proxy có bảo vệ bạn không?

Thường có, nhưng không phải lúc nào cũng vậy. Cuộc tấn công cần một kết nối HTTP/2 đến chính Apache, nên CDN hoặc bộ cân bằng tải giao tiếp với máy chủ gốc bằng HTTP/1.1 sẽ chặn HTTP/2 của khách truy cập khỏi mod_http2 ^[6]. Hai tình huống làm mất lớp bảo vệ này. Thứ nhất, proxy được đặt dùng HTTP/2 tới máy chủ gốc, như tùy chọn HTTP/2 to Origin của Cloudflare hoặc target group AWS dùng phiên bản giao thức HTTP2 ^[6]. Thứ hai, cổng Apache mở thẳng ra internet ^[6]. Bản thân proxy cũng có thể bị ảnh hưởng nếu nó chạy bản Apache bị lỗi ^[5].

Đã có mã khai thác công khai chưa?

Red Hat nói nghiên cứu công khai đã chứng minh một mã khai thác ổn định chống lại máy chủ cấu hình mặc định có bật mod_http2. Red Hat không nêu tên nghiên cứu đó ^[2]. Ostorlab nói chưa thấy liên kết tới mã khai thác công khai nào và chưa ghi nhận tấn công ngoài thực tế, đồng thời CVE chưa nằm trong danh mục KEV của CISA tính đến ngày 12/11/2026 ^[5]. Hai nhận định này có thể cùng đúng. Hãy giả định lỗ hổng khai thác được.

Apache xếp lỗi ở mức critical và bản sửa đã công khai từ ngày 11/11 ^[1], vì vậy hãy vá hoặc tắt HTTP/2 ngay, đừng chờ có xác nhận về một vụ tấn công.

Làm thế nào để tìm dấu hiệu bị tấn công?

Hãy bắt đầu từ các lần crash. Ostorlab gợi ý tìm trong log lỗi của Apache các lỗi segfault và tiến trình con thoát bất thường, nhất là trên máy chủ từng mở HTTP/2 trước khi vá ^[5]. Đường dẫn log là /var/log/apache2/error.log trên Debian và Ubuntu, và /var/log/httpd/error_log trên RHEL ^[5].

grep -Ei "segfault|signal 11|child pid .* exit|AH00051" /var/log/apache2/error.log
coredumpctl list apache2

Trên hệ dùng RPM, hãy thay apache2 bằng httpd. Ostorlab nói thêm rằng một lần crash chỉ là manh mối, không chứng minh có khai thác, vì lỗi khác và giới hạn tài nguyên cũng có thể làm dừng một tiến trình worker ^[5]. Log sạch không chứng minh máy chủ an toàn, vì một vụ khai thác thành công có thể không để lại dấu vết nào ngoài vùng nhớ bị hỏng ^[5]. Nếu thấy crash lặp lại trên máy chủ bị lộ, hãy sao chép log và các core dump ra khỏi máy trước khi khởi động lại hoặc dựng lại, và xử lý như một sự cố có thể đã xảy ra.

Apache 2.4.71 có vá lỗi nào khác không?

Có. Bản 2.4.71 gồm ba CVE: một critical, một important và một mức thấp ^[1]. Lỗi important là CVE-2026-106023, một lỗi NULL pointer dereference trong mod_md có thể làm tiến trình con bị crash, và lỗi ảnh hưởng 2.4.30 đến 2.4.70 ^[1]. mod_md là mô-đun khác với mod_http2, nên tắt HTTP/2 làm giải pháp tạm không xử lý được lỗi này ^[6]. Thông báo của Ubuntu cho cùng đợt phát hành gộp nhiều bản sửa Apache, nên cập nhật gói sẽ lấy hết chúng trong một lần ^[4].

Ai phát hiện ra lỗ hổng?

Apache ghi nhận hai bên phát hiện. OSS Scanner của Anthropic báo ngày 26/10/2026, còn Anthony Weems và Simon Scannell của Google Cloud Vulnerability Research báo ngày 03/11/2026 ^[1]. Trang của Red Hat cảm ơn hai nhà nghiên cứu của Google và không nhắc đến Anthropic ^[2]. Bản sửa gốc là commit 824beab trên nhánh 2.4.x ^[1].