Lỗ hổng nghiêm trọng trong PHP: bài học từ CVE-2026-109618 và CVE-2026-109619

PHP vừa tung ra các bản cập nhật 8.5.12, 8.4.27, 8.3.36 và 8.2.35 nhằm vá hai lỗ hổng nghiêm trọng, cho phép kẻ tấn công chưa xác thực thực thi mã trên máy chủ trong những điều kiện nhất định. Nếu bạn đang vận hành hệ thống dùng PHP, việc nâng cấp ngay lúc này là bắt buộc.

Nhưng câu chuyện đáng chú ý hơn nằm ở phía sau bản vá: cách hai lỗ hổng được phát hiện, vì sao việc sửa chữa bị trì hoãn hàng tháng trời, và những sự cố rò rỉ thông tin đáng tiếc ngay trước ngày công bố.

Lỗ hổng nằm ở đâu và vì sao nguy hiểm?

Cả hai lỗ hổng đều nằm trong những thành phần mà gần như mọi request đều đi qua: quản lý bộ nhớ và xử lý lỗi. Chính vị trí trung tâm này khiến chúng trở nên nguy hiểm, đồng thời cũng khiến việc vá trở nên cực kỳ khó khăn nếu không muốn phá vỡ khả năng tương thích, giảm hiệu năng hoặc buộc hàng loạt extension bên thứ ba phải thay đổi.

Theo đánh giá chính thức, điểm CVSS của lỗ hổng là 9.2 — mức nghiêm trọng, dù từng có tin đồn lan truyền sai lệch rằng đó là 10.0.

Hành trình phát hiện: từ một cuộc kiểm toán đến lỗi OOM

Năm 2024, PHP trải qua cuộc kiểm toán bảo mật độc lập đầu tiên sau nhiều năm, do Sovereign Tech Agency tài trợ và Quarkslab thực hiện thông qua OSTIF. Trong lúc sửa một vấn đề do Quarkslab báo cáo, một lập trình viên core của PHP đã phát hiện những dấu hiệu đầu tiên của lỗi OOM (out-of-memory) — gốc rễ của CVE-2026-109618.

Thời điểm đó, một kịch bản khai thác tiềm năng đã được đặt ra nhưng chưa tìm thấy vector cụ thể, nên vấn đề bị gác lại.

Vì sao bản vá bị trì hoãn nhiều tháng?

Đây là phần thẳng thắn nhất trong bài viết của PHP Foundation. Để xử lý lỗi OOM, nhóm bảo mật đã phát triển nhiều phương án cạnh tranh, mỗi phương án đều có cái giá riêng:

• Phá vỡ khả năng tương thích ngược
• Tạo ra nguy cơ tấn công từ chối dịch vụ (DoS) mới
• Buộc phải thay đổi nhiều extension bên thứ ba — điều gần như không thể điều phối

Nhóm bảo mật hoạt động theo cơ chế đồng thuận, nên việc chọn giữa các phương án trở nên bế tắc. Cộng thêm số lượng nhỏ các lập trình viên core có kiến thức sâu về engine, và việc chưa có con đường rõ ràng dẫn đến thực thi mã từ xa, công việc cứ dừng rồi khởi động lại trong nhiều tháng.

"Chúng tôi sẽ không tô hồng: sự chậm trễ này là một thất bại mang tính cấu trúc, xuất phát từ cả quy trình ra quyết định của nhóm bảo mật lẫn việc thiếu nguồn lực."

Từ đó, nhóm đã bắt đầu chuyển sang cơ chế biểu quyết đa số và khuyến khích thỏa hiệp để việc ra quyết định nhanh hơn.

Tái cấu trúc công tác bảo mật của PHP

Thời gian qua, cách tổ chức công việc bảo mật của PHP đã thay đổi đáng kể:

• Tháng 5/2026: PHP Foundation thành lập Ecosystem Security Team, phối hợp với nhóm bảo mật PHP trong phân loại, điều phối và tăng cường bảo mật.
• Tháng 7/2026: Alexandre Daubois gia nhập để hỗ trợ xử lý báo cáo bảo mật.
• Tháng 9/2026: Daniel Scherzer gia nhập, đảm nhận công việc hardening.
• Công việc của Volker Dusch với vai trò AI Security Engineer in Residence đã cải thiện đáng kể giao tiếp giữa nhóm bảo mật và Foundation.

Bên cạnh đó, PHP cũng được đưa vào chương trình Patch the Planet, qua đó hãng bảo mật Calif bắt đầu kiểm toán PHP từ ngày 30/7/2026.

Bước ngoặt ngày 11/8/2026

Chuyên gia Ryan A của Calif đã báo cáo một lỗ hổng thực thi mã từ xa không điều kiện, có cùng gốc rễ với lỗi OOM phát hiện năm 2024. Cùng ngày, OpenAI cũng báo cáo độc lập cùng nguyên nhân, sau đó bổ sung thêm các vector tấn công vào ngày 18/9, còn Wiz báo cáo ngày 24/8. Trail of Bits cũng đang kiểm toán PHP.

Từ ngày 11/8, việc sửa lỗi này trở thành ưu tiên hàng đầu của toàn bộ nhân sự bảo mật của PHP Foundation. Nếu không có nguồn tài trợ của Foundation, việc huy động nhiều người làm toàn thời gian — thậm chí xuyên cuối tuần — để phối hợp với các bên liên quan là điều không thể.

Khi AI làm thay đổi dòng báo cáo lỗ hổng

Sự phát triển của nghiên cứu có sự hỗ trợ của AI khiến nhóm bảo mật PHP nhận được nhiều báo cáo hơn hẳn trước đây. Kể từ ngày 1/7, nhóm đã công bố 15 CVE và xử lý hơn 100 báo cáo hóa ra là không hợp lệ, trùng lặp hoặc không tái hiện được.

AI giúp xác thực báo cáo và nhóm các báo cáo cùng nguyên nhân gốc, nhưng mọi quyết định và mọi bản vá vẫn do con người thực hiện.

Các công cụ đang được sử dụng bao gồm:

• Claude Mythos của Anthropic (qua hợp tác với Alpha-Omega)
• Daybreak Red của OpenAI để xác thực báo cáo và exploit
• Các bản build sanitizer và môi trường tái hiện khớp với CI trên mọi nền tảng PHP hỗ trợ

Sự cố rò rỉ trước ngày công bố

Quá trình công bố phối hợp diễn ra suôn sẻ cho đến 2 ngày trước ngày phát hành dự kiến:

• 20/10, khoảng 15:00 UTC: Hai mã CVE bắt đầu lan truyền trên diễn đàn và mạng xã hội, kèm thời điểm phát hành sai và điểm CVSS sai (10.0 thay vì 9.2). Không có chi tiết kỹ thuật nào bị lộ.
• PHP phải công bố trước thông báo lúc 19:30 UTC và dời ngày phát hành từ 22/10 sang 21/10.
• Khoảng 20:00 UTC, Calif vô tình đăng nhầm một video trình diễn proof-of-concept nhắm vào nhiều mục tiêu, tiết lộ thêm một số chi tiết. Video bị xóa nhưng bản sao vẫn lan truyền.
• 21/10 lúc 07:41 UTC, hơn 6 giờ trước giờ phát hành phối hợp, Chainguard đơn phương phá bỏ lệnh cấm công bố (embargo) và tung ra image đã chứa bản vá.

Việc Chainguard công bố sớm cho phép bất kỳ kẻ tấn công nào nghiên cứu bản vá dưới dạng nhị phân, trong khi người dùng PHP khác vẫn đang chờ bản phát hành chính thức — phá vỡ nhiều tuần nỗ lực phối hợp của nhiều bên.

Ý nghĩa với cộng đồng PHP tại Việt Nam

PHP vẫn là nền tảng của một tỷ lệ lớn các website, bao gồm cổng dịch vụ công, cửa hàng trực tuyến, ngân hàng và nhiều phần mềm doanh nghiệp. Với các đơn vị tại Việt Nam đang vận hành hệ thống PHP — từ WordPress, Laravel đến các hệ thống nội bộ — bài học rõ ràng là:

• Cập nhật ngay lên các phiên bản 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35.
• Theo dõi kênh thông tin chính thức của PHP thay vì tin vào các đồn đoán trên mạng xã hội về điểm CVSS hay thời điểm phát hành.
• Kiểm tra các image container đang dùng, đặc biệt nếu phụ thuộc vào các nhà phân phối có thể công bố sớm.

Công tác bảo mật của PHP vẫn phụ thuộc vào một nhóm nhỏ lập trình viên do Foundation tài trợ cùng một ít tình nguyện viên. Các công cụ AI có thể tìm bug nhanh hơn bao giờ hết, nhưng chúng không thể quyết định bản vá đúng đắn, cân nhắc đánh đổi về tương thích hay review patch. Những việc đó cần kỹ sư giàu kinh nghiệm am hiểu toàn bộ codebase PHP — và hiện nay số người như vậy là quá ít.