Bạn vừa thở phào nhẹ nhõm sau khi cập nhật PHP lên bản vá khẩn cấp cho hai lỗ hổng PHP2Shell nguy hiểm chết người. Bạn nghĩ mình đã an toàn. Nhưng chỉ hai ngày sau, một cảnh báo mới lại xuất hiện, và lần này, nó mang theo một sự thật khó chịu: vẫn còn một lỗ hổng khác chưa được vá.
Trong bài viết này, tôi sẽ cùng bạn mổ xẻ CVE-2026-115560 – lỗ hổng thực thi mã từ xa (RCE) mới được PHP công bố – từ góc nhìn của một người đã chứng kiến không ít lần các lỗ hổng tưởng chừng nhỏ bé lại trở thành thảm họa. Chúng ta sẽ cùng trả lời câu hỏi: Đây có phải là mối đe dọa thực sự, hay chỉ là một cảnh báo thừa?
Bối cảnh: Khi PHP2Shell vừa được vá, một lỗ hổng mới lại xuất hiện
Để hiểu rõ câu chuyện, hãy tua lại vài ngày trước. Vào ngày 21 tháng 10 năm 2026, cộng đồng PHP trên toàn thế giới đã trải qua một trong những ngày căng thẳng nhất trong nhiều năm.
Hai lỗ hổng nghiêm trọng mang tên CVE-2026-109618 và CVE-2026-109619, được giới nghiên cứu gọi là PHP2Shell, đã được vá khẩn cấp. Cả hai đều được đánh giá 9,2 điểm trên thang CVSS v4.0 – mức "nghiêm trọng" – và cho phép kẻ tấn công thực thi mã từ xa mà không cần xác thực. Nói cách khác, kẻ tấn công có thể chiếm quyền điều khiển máy chủ web của bạn mà không cần bất kỳ tài khoản nào.
Bản vá đã được phát hành cho các nhánh PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Hàng triệu quản trị viên trên toàn cầu đã thở phào, cập nhật hệ thống và tiếp tục công việc thường nhật.
Nhưng rồi, vào ngày 23 tháng 10, chỉ hai ngày sau đó, PHP lại đưa ra một thông báo ngắn. Lần này, họ không phát hành bản vá khẩn cấp. Họ chỉ đơn giản là cảnh báo về một lỗ hổng khác: CVE-2026-115560.
CVE-2026-115560 là gì và tại sao PHP lại cho rằng nó "khó xảy ra"?
Điều đầu tiên cần khẳng định: CVE-2026-115560 không phải là một lỗ hổng có thể khai thác hàng loạt. Đây là điểm khác biệt căn bản so với PHP2Shell.
Theo thông báo từ chính PHP, lỗ hổng này chỉ ảnh hưởng đến các ứng dụng web được cấu hình theo một cách rất cụ thể và không phổ biến. Để một hệ thống trở nên dễ bị tổn thương, ứng dụng đó phải đáp ứng đồng thời tất cả các điều kiện sau:
- Thiết lập session.serialize_handler thành php_binary hoặc php_serialize trong file cấu hình.
- Thay đổi giá trị đó thành "php" trong khi ứng dụng đang chạy, thông qua hàm ini_set().
- Thực hiện thay đổi này trước khi gọi hàm session_start().
- Tính năng session upload progress vẫn đang được bật.
Nếu ứng dụng của bạn không bao giờ thay đổi serialize handler trong khi chạy, bạn có thể để tính năng này bật mà không gặp rủi ro từ con đường tấn công này. Chính vì sự kết hợp hiếm hoi này, PHP đánh giá đây là một rủi ro khó xảy ra và quyết định không phát hành bản vá khẩn cấp. Thay vào đó, họ sẽ xử lý nó trong chu kỳ phát hành thông thường tiếp theo.
Tuy nhiên, đừng vì thế mà chủ quan. "Khó xảy ra" không có nghĩa là "không thể xảy ra". Và trong lĩnh vực an ninh mạng, những lỗ hổng tưởng chừng vô hại lại thường là chìa khóa cho những cuộc tấn công tinh vi nhất.
Biện pháp phòng vệ duy nhất: Tắt session.upload_progress.enabled
Vì chưa có bản vá chính thức, PHP đưa ra một khuyến nghị duy nhất và rõ ràng: đặt session.upload_progress.enabled=0 cho đến khi bản vá tiếp theo được phát hành.
Đây là một thay đổi cấu hình đơn giản nhưng hiệu quả. Bạn có thể thực hiện bằng cách thêm dòng sau vào file php.ini:
session.upload_progress.enabled = Off
Hoặc, nếu bạn đang sử dụng PHP-FPM, bạn có thể thêm vào cấu hình pool:
php_admin_flag session.upload_progress.enabled Off
Sau khi thay đổi, hãy khởi động lại tất cả các tiến trình PHP worker để đảm bảo cấu hình mới có hiệu lực.
Điều đáng chú ý là khuyến nghị này không mới. Nó đã từng được đưa ra như một biện pháp giảm thiểu cho CVE-2026-109619 trong đợt vá PHP2Shell trước đó. Nếu bạn đã áp dụng nó và giữ nguyên, bạn không cần làm gì thêm cho lỗ hổng mới này. Nhưng nếu bạn đã bỏ qua, đây là lúc để xem lại.
Tại sao lỗ hổng này vẫn đáng để tâm, dù PHP nói "khó xảy ra"?
Bạn có thể tự hỏi: "Nếu PHP nói nó khó xảy ra, tại sao tôi phải bận tâm?"
Câu trả lời nằm ở bản chất của hệ sinh thái PHP. PHP không chỉ là một ngôn ngữ. Nó là xương sống của một phần lớn internet. WordPress, Drupal, Joomla, Magento, Laravel – tất cả đều chạy trên PHP. Và trong vô số hệ thống đó, có không ít ứng dụng được cấu hình theo những cách độc đáo, thậm chí kỳ quặc, mà người phát triển ban đầu có thể đã không lường trước được hậu quả.
Hơn nữa, lịch sử đã chứng minh rằng những lỗ hổng "khó xảy ra" thường là mảnh ghép cuối cùng trong một chuỗi tấn công phức tạp. Kẻ tấn công có thể kết hợp một lỗ hổng LFI (Local File Inclusion) với CVE-2026-115560 để đạt được RCE. Hoặc chúng có thể khai thác một lỗ hổng khác để thay đổi cấu hình session trước khi khai thác lỗ hổng này.
Và quan trọng nhất: việc tắt session.upload_progress.enabled không gây hại gì đáng kể. Tính năng này chỉ cho phép theo dõi tiến trình tải lên tệp, và hầu hết các ứng dụng không thực sự cần đến nó. Vậy tại sao lại mạo hiểm?
Những việc bạn cần làm ngay lúc này
Nếu bạn đang quản lý bất kỳ máy chủ PHP nào – dù là website cá nhân, ứng dụng doanh nghiệp hay hệ thống của khách hàng – đây là những bước bạn nên thực hiện ngay từ hôm nay.
1. Kiểm tra phiên bản PHP của bạn
Trước tiên, hãy xác định bạn đang chạy phiên bản PHP nào. Bạn có thể tạo một file phpinfo.php chứa dòng <?php phpinfo(); ?> và truy cập qua trình duyệt, hoặc chạy lệnh php -v từ terminal. Nếu bạn đang dùng PHP 8.2, 8.3, 8.4 hoặc 8.5, hãy đảm bảo bạn đã cập nhật lên các bản vá PHP2Shell mới nhất (8.5.12, 8.4.27, 8.3.36, 8.2.35). Nếu bạn đang dùng PHP 8.1 trở xuống, bạn cần nâng cấp lên phiên bản được hỗ trợ hoặc liên hệ nhà cung cấp dịch vụ để có bản vá backport.
2. Tắt session.upload_progress.enabled ngay lập tức
Dù bạn có nằm trong nhóm "khó xảy ra" hay không, việc tắt tính năng này là một biện pháp phòng vệ đơn giản và không tốn kém. Hãy thực hiện ngay, đừng chờ đợi.
3. Rà soát cấu hình session của ứng dụng
Kiểm tra xem ứng dụng của bạn có sử dụng ini_set('session.serialize_handler', ...) trong mã nguồn hay không. Nếu có, hãy xem xét lại logic và đảm bảo rằng nó không tạo ra điều kiện cho lỗ hổng. Đây cũng là cơ hội để bạn rà soát lại toàn bộ cấu hình session, đảm bảo mọi thứ đang hoạt động theo cách an toàn nhất.
4. Theo dõi các bản phát hành tiếp theo của PHP
PHP cho biết họ sẽ phát hành bản vá cho CVE-2026-115560 trong chu kỳ phát hành thông thường tiếp theo, kèm theo một thông báo đầy đủ. Hãy đăng ký nhận thông báo từ PHP.net hoặc theo dõi các kênh an ninh mạng uy tín để không bỏ lỡ.
Khi sự chủ quan là kẻ thù lớn nhất
Câu chuyện về CVE-2026-115560 không thể tách rời khỏi bối cảnh của PHP2Shell. Chỉ trong vòng vài ngày, cộng đồng PHP đã phải đối mặt với hai làn sóng cảnh báo liên tiếp. Và điều đáng sợ là: các cuộc tấn công khai thác PHP2Shell đã tăng vọt lên hàng triệu lần chỉ trong vòng 45 phút sau khi bản vá được công bố. Kẻ tấn công đã cố gắng cài đặt biến thể Mirai botnet, và dù các nỗ lực đó cho đến nay được cho là chưa thành công trong việc thực thi mã, việc quét và thăm dò vẫn đang diễn ra không ngừng.
Điều này cho thấy một sự thật phũ phàng: kẻ tấn công luôn chờ đợi. Chúng chờ đợi bạn chậm trễ cập nhật. Chúng chờ đợi bạn bỏ qua một cấu hình nhỏ. Và chúng sẽ khai thác bất kỳ kẽ hở nào bạn để lại.
Với CVE-2026-115560, PHP đã đưa ra một cảnh báo sớm. Họ không giấu diếm. Họ không chờ đợi đến khi có bản vá mới công bố. Họ nói rõ: "Đây là một lỗ hổng, nó khó xảy ra, nhưng đây là cách để bảo vệ mình ngay bây giờ."
Việc của bạn là lắng nghe và hành động.
Bạn đã kiểm tra cấu hình PHP trên máy chủ của mình chưa – và bạn có chắc chắn rằng mình không nằm trong nhóm "khó xảy ra" nhưng vẫn có thể bị tổn thương? Nếu bạn là quản trị viên hệ thống, bạn sẽ ưu tiên xử lý CVE-2026-115560 như thế nào so với hàng trăm việc khác đang chờ? Hãy chia sẻ quan điểm của bạn bên dưới, bởi vì trong cuộc chiến không ngừng nghỉ này, sự chủ quan chính là lỗ hổng lớn nhất!
0 Comment
Add your comment to this article