AWS xếp lỗ hổng RCE nghiêm trọng của PHP ở mức "Important", bản vá Amazon Linux 2023 có thể phải chờ 20 ngày

Cộng đồng quản trị hệ thống đang dậy sóng sau khi PHP phát hành bản vá cho hai lỗ hổng thực thi mã từ xa (RCE) với điểm CVSS 9.2, nhưng Amazon Linux 2023 vẫn chưa có bản cập nhật. Đáng chú ý hơn, AWS phân loại hai lỗ hổng này chỉ ở mức "Important" thay vì "Critical" như các bên khác.

Sự việc bắt đầu từ một issue trên kho GitHub của Amazon Linux 2023, nơi người dùng yêu cầu AWS cập nhật gói PHP sau khi bản vá chính thức ra mắt. Câu chuyện nhanh chóng lan rộng và trở thành tâm điểm tranh luận về quy trình phản ứng bảo mật của "ông lớn" cloud.

Lỗ hổng nghiêm trọng, nhưng mức phân loại gây tranh cãi

PHP đã phát hành bản cập nhật khẩn cấp để vá hai lỗ hổng CVE-2026-109618 và CVE-2026-109619, cả hai đều được đánh giá CVSS v4.0 9.2 — mức gần tối đa. Theo mô tả từ AWS, các lỗ hổng ảnh hưởng đến PHP phiên bản 8.2 đến 8.5 ở cấu hình mặc định, cho phép kẻ tấn công chưa xác thực từ xa có thể làm sập các tiến trình worker của PHP.

Trong khi các bản phân phối Linux lớn khác đã tung bản vá chỉ trong vài giờ, trên trang Amazon Linux Security Center (ALSC), cả hai CVE này lại được xếp ở mức "Important" — thấp hơn một bậc so với mức "Critical" mà cộng đồng PHP và các hệ thống khác áp dụng.

Người dùng có tên scorgn đặt câu hỏi trực tiếp: "Các trang lỗ hổng của Amazon có sai không, và Amazon có công nhận đây là các CVE nghiêm trọng không?"

Việc hạ bậc phân loại này không chỉ mang tính hình thức. Trong quy trình nội bộ của nhiều tổ chức, mức "Important" thường đi kèm khung thời gian xử lý dài hơn đáng kể so với "Critical" — điều mà giới kỹ thuật gọi là SLA vá lỗi.

Cộng đồng phản ứng dữ dội

Các bình luận trên GitHub phản ánh sự thất vọng của những người vận hành hệ thống production. Nhiều người cho rằng thời gian chờ đợi là không thể chấp nhận được với một lỗ hổng RCE nghiêm trọng như vậy.

Một người dùng có tên garretgengler viết thẳng thắn: Amazon Linux đã chứng minh rằng họ không phù hợp cho môi trường production, trong khi các bản phân phối lớn khác đã phát hành bản vá từ nhiều giờ trước.

Trong khi đó, mbuk — người dùng gói hỗ trợ doanh nghiệp — chia sẻ đoạn hội thoại với bộ phận support của AWS. Phản hồi nhận được chỉ là thông báo chung chung về việc "đang xử lý" và không có ETA cụ thể, thậm chí còn nhắc đến Elastic Beanstalk và Lightsail mà không đề cập trực tiếp đến Amazon Linux 2023.

AWS cam kết phát hành bản vá trong ngày 22/10

Sau nhiều giờ chờ đợi, AWS cuối cùng đã đưa ra thông tin chính thức thông qua một bản tin bảo mật.

"Các gói PHP cập nhật cho Amazon Linux được dự kiến phát hành vào ngày 22/10/2026. Khách hàng chạy PHP trên Amazon Linux nên áp dụng bản cập nhật ngay khi có sẵn."

Dù vậy, cộng đồng vẫn không hài lòng với khoảng trễ hơn 24 giờ. Nhiều người chỉ ra rằng đội ngũ PHP đã chia sẻ trước thông tin về lỗ hổng, và thông báo của NSA cũng khuyến nghị vá ngay lập tức hoặc đưa hệ thống ra khỏi mạng.

Bài học về quản trị rủi ro cho người dùng Việt Nam

Đối với các đội DevOps và quản trị hệ thống tại Việt Nam đang chạy PHP trên hạ tầng AWS, sự việc này mang đến vài lưu ý thực tế:

• Không nên phụ thuộc hoàn toàn vào bản vá của nhà cung cấp: Cần có phương án tự build và triển khai bản vá nội bộ khi cần thiết. Một người dùng trên GitHub đã chia sẻ cách tự build SRPM của PHP và phân phối qua Systems Manager.
• Theo dõi mức phân loại CVE của từng nhà cung cấp: Việc AWS hạ bậc từ "Critical" xuống "Important" có thể ảnh hưởng trực tiếp đến thời gian bạn nhận được bản vá.
• Cân nhắc đa dạng hóa nền tảng: Với các hệ thống nhạy cảm về bảo mật, việc phụ thuộc vào một bản phân phối duy nhất có thể tạo ra điểm nghẽn rủi ro.
• Đăng ký hỗ trợ doanh nghiệp không đồng nghĩa với phản hồi nhanh hơn: Như trường hợp của mbuk cho thấy, ngay cả gói business+ cũng không đảm bảo được thông tin rõ ràng về tiến độ.

Sự việc cũng là lời nhắc nhở rằng trong bảo mật, thời gian chính là yếu tố sống còn. Mỗi giờ chậm trễ trong việc vá một lỗ hổng RCE đều là cơ hội cho kẻ tấn công khai thác các hệ thống chưa được bảo vệ.