Ngày 21/10/2026, chúng tôi phải khẩn cấp vá hai lỗ hổng nghiêm trọng của PHP trên các máy chủ do chúng tôi vận hành và bảo trì. Bài post-mortem này trình bày những gì đã xảy ra, những gì chúng tôi đã làm, những điểm chưa diễn ra như mong muốn và những việc còn phải làm. Công việc vẫn chưa kết thúc.
Tóm tắt
- Bản vá chính thức của PHP được áp dụng lên các máy chủ production ngay khi phát hành, khoảng 15h45 giờ Paris (20h45 giờ Việt Nam), mỗi máy chủ gián đoạn vài phút.
- Các nỗ lực tấn công đã được phát hiện vào đầu giờ chiều, trước khi có bản vá. Theo phân tích của chúng tôi cho đến nay, các cuộc tấn công này đều không thành công.
- Một phần lỗ hổng dường như vẫn có thể bị khai thác dù đã có bản vá chính thức. Các biện pháp bảo vệ áp dụng từ buổi sáng vẫn được giữ nguyên và việc giám sát vẫn tiếp tục.
- Chúng tôi đã xác định một số điểm cần cải thiện, trước hết là cách đưa ra các quyết định khẩn cấp cùng khách hàng.
Bối cảnh
Ngày 20/10, đội ngũ bảo mật của PHP công bố hai lỗ hổng nghiêm trọng, CVE-2026-109618 và CVE-2026-109619, được đánh giá 9,2/10 (CVSS v4). Chúng cho phép thực thi mã từ xa trên máy chủ mà không cần thông tin đăng nhập. Mọi bản cài đặt PHP xử lý request web đều bị ảnh hưởng (PHP-FPM, mod_php, php-cgi), tức là phần lớn các website Magento, WordPress, Symfony hay Drupal.
Trong những trường hợp như vậy, thông tin chi tiết thường được giữ bí mật cho đến khi có bản vá, để mọi bên có thời gian chuẩn bị. Lần này, thông tin bị rò rỉ trước thời hạn và PHP đã đẩy sớm việc phát hành lên 16h ngày 21/10, giờ Paris. Nguy cơ tấn công hàng loạt rất cao ngay từ lúc phát hành: Matthew Prince, CEO của Cloudflare, cho biết mạng lưới của họ ghi nhận hàng nghìn lượt tấn công trong 10 giờ trước khi công bố, hàng chục nghìn lượt trong 45 phút sau đó và hàng triệu lượt kể từ đó.
Diễn biến ngày 21/10 (giờ Paris)
- Buổi sáng: chúng tôi áp dụng lên toàn bộ các môi trường những biện pháp bảo vệ đầu tiên đang được chia sẻ: tắt tính năng PHP bị nghi là nguyên nhân và áp dụng các quy tắc lọc khẩn cấp của Cloudflare cho các website dùng Cloudflare.
- Từ 13h45 đến 14h51: trên một website do chúng tôi vận hành, đội ngũ quản trị hệ thống phát hiện các request tấn công nhắm vào lỗ hổng. Trong 8 request, 6 request bị chặn bởi quy tắc Cloudflare khẩn cấp; 2 request vượt qua bộ lọc này và bị hủy bỏ bởi chính kẻ tấn công. Đến thời điểm này, mọi dấu hiệu cho thấy không request nào thành công: biện pháp bảo vệ áp dụng trong PHP từ buổi sáng đã ngăn chặn chúng.
- Đầu giờ chiều: chúng tôi gửi thư cho khách hàng để xin phép chuyển website sang chế độ bảo trì phòng ngừa nếu cần. Với một số khách hàng trọng yếu, chúng tôi tăng cường quy tắc Cloudflare và đề xuất tạm dừng hệ thống vài phút trước khi bản vá được phát hành. Các thao tác dự kiến lúc 16h được đẩy sớm hơn.
- Buổi chiều: chúng tôi tạm dừng các môi trường phát triển và staging để giảm số máy chủ phải xử lý gấp, đồng thời chuẩn bị cập nhật cho từng máy chủ production.
- Khoảng 15h45: bản vá được phát hành sớm khoảng 15 phút. Chúng tôi áp dụng lần lượt trên từng máy chủ, mỗi lần gián đoạn vài phút. Vì bản vá đến sớm hơn dự kiến, chúng tôi đã triển khai bản vá thay vì tạm dừng hệ thống của các khách hàng trọng yếu.
- Cuối ngày: chúng tôi kiểm tra trên từng máy chủ rằng phiên bản đã vá thực sự đang chạy.
Những việc chưa kết thúc
- Theo thông tin đã công bố, một số khía cạnh của lỗ hổng vẫn có thể bị khai thác dù đã có bản vá chính thức: phiên bản PHP được vá ngày 21/10 vẫn có thể bị tấn công với cấu hình mặc định. Các biện pháp áp dụng từ buổi sáng, cùng với bộ lọc Cloudflare, dường như đang ngăn chặn điều này; chúng tôi vẫn tiếp tục duy trì các biện pháp đó.
- Các môi trường phát triển và staging đang được khôi phục dần, và một số thao tác vẫn đang tiếp tục.
- Việc giám sát vẫn tiếp tục. Chúng tôi sẽ cập nhật bài viết này nếu tình hình thay đổi.
Những điều chúng tôi cần cải thiện
Ra quyết định nhanh hơn cùng khách hàng
Việc xin phép chuyển website sang chế độ bảo trì cần thời gian, đúng vào lúc thời gian eo hẹp nhất. Chúng tôi muốn thống nhất trước các quyết định này với từng khách hàng.
Tăng cường bảo mật cho toàn bộ hệ thống
Hai request tấn công đã vượt qua bộ lọc Cloudflare: hệ thống được bảo vệ nhờ có nhiều lớp phòng thủ, chứ không nhờ một lớp duy nhất. Chúng tôi đã bắt đầu tăng cường bảo mật trên toàn bộ hệ thống thông tin: môi trường phát triển, danh sách truy cập được phép (whitelist), xác thực hai lớp. Công việc này sẽ tiếp tục.
Giảm số phiên bản cũ
Các phiên bản PHP không còn được hỗ trợ đã nhận được bản vá backport, nhưng đó chỉ là giải pháp tạm thời, không có gì bảo đảm cho lỗ hổng tiếp theo. Một phiên bản còn được bảo trì sẽ nhận bản vá trong vài phút; với phiên bản quá cũ, bản vá có thể đến muộn hơn, thậm chí không bao giờ, và đôi khi cách bảo vệ duy nhất còn lại là tạm dừng website.
Bài học cho thời gian tới
Với trí tuệ nhân tạo, lỗ hổng được phát hiện nhanh hơn nhưng cũng bị khai thác nhanh hơn: khoảng thời gian từ khi công bố lỗ hổng đến các đợt tấn công hàng loạt đầu tiên giờ được tính bằng phút, không còn bằng ngày. Ngày 21/10, nhiều cơ quan nhà nước ở châu Âu, trong đó có các tỉnh của Pháp, đã chọn tạm dừng website để phòng ngừa. Việc luôn giữ hệ thống được cập nhật trở thành điều kiện tiên quyết để có thể vá lỗi kịp thời.
Dành cho đội ngũ kỹ thuật
- Lỗ hổng: CVE-2026-109618 (lỗi hỏng bộ nhớ do tràn bộ nhớ) và CVE-2026-109619 (trạng thái nội bộ bị dùng lại giữa các request), CVSS v4 9,2, thực thi mã từ xa không cần xác thực.
- Phiên bản đã vá: PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Với các nhánh 7.x, 8.0 và 8.1, bản vá được backport bởi đơn vị duy trì (maintainer) gói PHP mà chúng tôi sử dụng.
- Biện pháp tạm thời, vẫn giữ sau khi vá:
session.upload_progress.enabled = 0vàsession.use_strict_mode = 1, quy tắc lọc Cloudflare khẩn cấp, tạm dừng các môi trường ngoài production. - Áp dụng bản vá: cập nhật gói, khởi động lại toàn bộ dịch vụ web, kiểm tra không còn tiến trình nào chạy phiên bản cũ. Chỉ cập nhật gói là chưa đủ: PHP-FPM, Apache với mod_php và các tiến trình chạy ngầm dài hạn (hàng đợi Magento, message consumer) vẫn giữ mã cũ cho đến khi được khởi động lại.
- Số phiên bản: bản vá backport không phải lúc nào cũng thay đổi số phiên bản PHP. Công cụ chỉ đọc con số này có thể sai theo cả hai chiều; chỉ phiên bản của gói đã cài đặt mới đáng tin cậy.
Khách hàng của Sutunam: quản lý dự án của bạn luôn sẵn sàng giải đáp mọi câu hỏi về máy chủ.
Nguồn: thông báo bảo mật của PHP, 21/10/2026; Matthew Prince, Cloudflare; SecurityWeek; Reuters, qua Global Banking & Finance.
