Thứ Ba vừa rồi, bạn thức khuya cập nhật PHP trên máy chủ công ty vì bản vá khẩn cho hai lỗi PHP2Shell. Sáng thứ Tư, bạn thở phào báo với sếp là "xong rồi". Đến thứ Sáu, PHP lại phát đi một cảnh báo mới: thêm một cách nữa để kẻ tấn công chạy mã trên web server, và bản vá vừa cài không xử lý được nó.
Tin tốt là lần này không đáng sợ bằng lần trước. Lỗi mới chỉ chạm tới một kiểu cấu hình khá hiếm, và cách chặn chỉ là một dòng trong php.ini. Bài này giải thích lỗi mới khác PHP2Shell ở chỗ nào, máy chủ của bạn có nằm trong vùng nguy hiểm không, và nên làm gì ngay.
Hai ngày sau bản vá khẩn, PHP lại cảnh báo chuyện gì?
Ngày 23/10/2026, nhóm phát triển PHP đăng một thông báo ngắn, dạng informational advisory (thông báo để biết, chưa phải bản tin bảo mật đầy đủ). Nội dung: có thêm một con đường cho phép thực thi mã từ xa (Remote Code Execution, RCE) trên web server. Lỗi mới mang mã CVE-2026-115560.
Để hiểu vì sao tin này gây chú ý, cần nhìn lại hai ngày trước đó. Ngày 21/10, PHP tung bản phát hành khẩn để vá hai lỗi nghiêm trọng được gọi chung là PHP2Shell, mã CVE-2026-109618 và CVE-2026-109619. Hai lỗi này cho phép người không có tài khoản chạy mã trên máy chủ. Bản vá nằm trong các phiên bản:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Điểm mấu chốt: CVE-2026-115560 là lỗi riêng, các bản 8.5.12, 8.4.27, 8.3.36 và 8.2.35 không sửa nó. Nhưng khác với PHP2Shell, PHP đánh giá lỗi mới là rủi ro khó xảy ra và không phát hành bản vá khẩn.
| PHP2Shell (CVE-2026-109618, CVE-2026-109619) | CVE-2026-115560 | |
|---|---|---|
| Ngày công bố | 21/10 | 23/10 |
| Phạm vi | Lỗi nghiêm trọng, người không có tài khoản chạy được mã | Chỉ ứng dụng cấu hình bất thường |
| Cách PHP xử lý | Bản phát hành khẩn | Chờ bản sửa lỗi định kỳ kế tiếp |
| Biện pháp tạm thời | Cập nhật bản vá | Tắt session upload progress |
| Bị tấn công thực tế? | Có, đang bị dò quét ồ ạt | Chưa ghi nhận |
Máy chủ nào thật sự nằm trong vùng nguy hiểm?
Theo PHP, chỉ một kiểu thiết lập rất hẹp mới bị ảnh hưởng. Ứng dụng web phải làm đủ tất cả các bước sau:
- Trong file cấu hình, đặt tuỳ chọn
session.serialize_handlerthànhphp_binaryhoặcphp_serialize. - Trong lúc chạy, gọi
ini_set()để đổi tuỳ chọn đó sangphp. - Việc đổi này diễn ra trước khi gọi
session_start(). - Tính năng session upload progress vẫn đang bật.
session.serialize_handler quyết định cách PHP "đóng gói" dữ liệu session thành chuỗi để cất đi, rồi "mở gói" ra khi người dùng quay lại. Hãy hình dung bạn gửi đồ ở quầy giữ hành lý: lúc gửi, nhân viên gói theo kiểu A, nhưng lúc lấy lại thì đổi quy trình sang mở theo kiểu B. Phần lớn thời gian chẳng sao, nhưng cái khe hở giữa hai cách gói chính là chỗ kẻ xấu có thể nhét thứ không nên có vào.
Nhìn bằng code, kiểu thiết lập rủi ro trông giống thế này:
; php.ini
session.serialize_handler = php_serialize
session.upload_progress.enabled = 1
<?php
// Đổi handler lúc đang chạy, trước khi mở session
ini_set('session.serialize_handler', 'php');
session_start();
Ngược lại, nếu ứng dụng không bao giờ đổi serialize handler trong lúc chạy, bạn có thể để nguyên session upload progress mà không bị lộ qua con đường này. PHP cho rằng kiểu thiết lập trên khó gặp trong thực tế.
Cách dễ nhất để biết ứng dụng của bạn có rơi vào trường hợp này không là tìm trong mã nguồn những chỗ gọi ini_set với session.serialize_handler. Không có chỗ nào như vậy thì con đường tấn công này không áp dụng cho bạn.
Session upload progress là gì mà phải tắt?
Session upload progress (theo dõi tiến trình upload qua session) là tính năng giúp ứng dụng biết một file đang được tải lên tới đâu, kiểu thanh phần trăm chạy dần khi bạn upload ảnh hay tài liệu. Tính năng này bật sẵn theo mặc định.
Cách chặn mà PHP khuyến nghị chỉ là một dòng: đặt
session.upload_progress.enabled = 0
và giữ như vậy cho tới bản sửa lỗi định kỳ tiếp theo. Tắt tính năng này giống như tạm khoá một cửa phụ ít người dùng trong lúc chờ thợ tới sửa ổ khoá: nhà vẫn sinh hoạt bình thường, chỉ mất một lối đi.
Điều thú vị là đây chính là biện pháp giảm thiểu PHP đã nêu trong thông báo ngày 21/10 cho CVE-2026-109619. Vì thế:
- Đã tắt từ 21/10 và vẫn để tắt: bạn không cần làm gì thêm cho lỗi mới.
- Chưa từng tắt: nên tắt ngay nếu ứng dụng không cần hiển thị tiến trình upload.
Sửa php.ini xong, hãy khởi động lại PHP-FPM hoặc web server để thay đổi có hiệu lực. Nhiều người sửa file cấu hình rồi quên bước này, tưởng đã an toàn nhưng tiến trình cũ vẫn chạy với cấu hình cũ.
Vì sao PHP không vá khẩn lần này?
Lý do PHP đưa ra rất đơn giản: kiểu thiết lập bị ảnh hưởng không phổ biến, nên bản sửa sẽ đi theo chu kỳ phát hành thường lệ thay vì một bản khẩn như hôm 21/10. Khi bản sửa ra mắt, PHP sẽ công bố kèm bản tin bảo mật đầy đủ cho CVE-2026-115560.
Cho tới lúc đó, vẫn còn khá nhiều câu hỏi chưa có lời đáp. PHP chưa cho biết:
- Những phiên bản nào bị ảnh hưởng.
- Bản phát hành nào sẽ chứa bản sửa.
- Điểm mức độ nghiêm trọng của lỗi.
- Lỗi mới có chung nguyên nhân gốc với CVE-2026-109619 hay không.
Cũng chưa có báo cáo nào về việc CVE-2026-115560 bị khai thác. Mọi cuộc tấn công ghi nhận từ 21/10 tới nay đều nhắm vào hai lỗi PHP2Shell trước đó.
Lỗi mới chưa bị ai đụng tới, nhưng "chưa biết phiên bản nào bị ảnh hưởng" cũng có nghĩa là bạn không nên tự loại mình ra chỉ vì đang chạy bản mới nhất.
Ngoài kia, PHP2Shell đang bị tấn công dữ dội ra sao?
Dù lỗi mới khá "hiền", bối cảnh xung quanh thì không. Hai lỗi PHP2Shell đang bị săn lùng ráo riết:
- Bị nhắm từ trước khi công bố: Amazon cho biết các honeypot (máy chủ mồi nhử, dựng lên để dụ và ghi lại hành vi tấn công) của họ đã ghi nhận một lần thử khai thác CVE-2026-109618 và CVE-2026-109619 vào 17/10, tức bốn ngày trước khi hai lỗi được công bố.
- Bùng nổ sau công bố: theo Cloudflare, số lần thử khai thác tăng từ hàng chục nghìn trong vòng 45 phút sau khi công bố ngày 21/10 lên hàng triệu vào sáng sớm 22/10.
Honeypot giống như một căn nhà mẫu không người ở, cửa cố ý để hé, gắn đầy camera. Kẻ trộm nào mò vào cũng bị ghi hình, và chủ nhà biết được kẻ trộm đang thử những chiêu gì, kể cả những chiêu chưa ai công bố.
Mục tiêu: biến máy chủ thành lính botnet
Theo Sophos và Arctic Wolf, kẻ tấn công đã thử dùng PHP2Shell để cài một biến thể của Mirai, dòng mã độc nổi tiếng chuyên gom các thiết bị bị chiếm quyền thành botnet (mạng máy "zombie" chịu điều khiển từ xa).
Tin vui là các nỗ lực này tới giờ vẫn thất bại. Previdian, Wordfence và một số đơn vị khác chỉ thấy hoạt động dò quét, thăm dò, chưa có trường hợp nào được xác nhận là chạy mã thành công. Theo các nhà nghiên cứu, viết một bản khai thác ổn định khó hơn dự kiến. Nhưng "chưa thành công" không có nghĩa là sẽ mãi như vậy, và toàn bộ làn sóng này nhắm vào hai lỗi đã vá ngày 21/10, chứ không phải CVE-2026-115560.
Tắt session upload progress là để chặn lỗi mới. Nó không thay thế việc cập nhật lên 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35 để vá PHP2Shell, thứ đang bị dò quét với số lượng hàng triệu lần.
Vậy bạn cần làm gì ngay hôm nay?
Tóm lại thành một danh sách ngắn cho người quản trị máy chủ và lập trình viên PHP:
- [ ]Kiểm tra phiên bản PHP đang chạy, nếu chưa thì cập nhật lên 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35 để vá PHP2Shell.
- [ ]Đặt
session.upload_progress.enabled = 0trongphp.ini, rồi khởi động lại PHP-FPM hoặc web server. - [ ]Nếu đã tắt từ 21/10, xác nhận nó vẫn đang tắt, không bị ghi đè khi cập nhật.
- [ ]Rà mã nguồn tìm chỗ gọi
ini_set('session.serialize_handler', ...)trướcsession_start(). - [ ]Theo dõi bản sửa lỗi định kỳ tiếp theo của PHP và bản tin đầy đủ cho CVE-2026-115560.
Ưu tiên rõ ràng: PHP2Shell là mối nguy đang hiện hữu, nên cập nhật trước. Lỗi mới thì chặn bằng một dòng cấu hình, tốn chưa tới một phút.
Tóm tắt nhanh
- Ngày 23/10/2026, PHP cảnh báo lỗi chạy mã từ xa mới CVE-2026-115560, tách biệt với hai lỗi PHP2Shell vá ngày 21/10.
- Lỗi chỉ ảnh hưởng ứng dụng đổi
session.serialize_handlertừphp_binary/php_serializesangphpbằngini_set()trướcsession_start(), khi session upload progress đang bật. - Cách chặn: đặt
session.upload_progress.enabled = 0; ai đã làm từ 21/10 thì không cần làm gì thêm. - PHP chưa công bố phiên bản bị ảnh hưởng, điểm nghiêm trọng hay bản chứa bản sửa; lỗi mới chưa bị khai thác.
- PHP2Shell đang bị dò quét hàng triệu lần, kẻ tấn công nhắm cài Mirai nhưng chưa ghi nhận ca chạy mã thành công.
Câu hỏi thường gặp
Tôi đã cập nhật lên PHP 8.4.27 rồi, vậy đã an toàn với lỗi mới chưa?
Chưa chắc. Các bản 8.5.12, 8.4.27, 8.3.36 và 8.2.35 chỉ vá PHP2Shell, không sửa CVE-2026-115560. Nếu ứng dụng có kiểu cấu hình rủi ro, hãy tắt session upload progress cho tới bản sửa lỗi định kỳ tiếp theo.
Tắt session upload progress có làm hỏng website không?
Tính năng này chỉ dùng để theo dõi tiến trình tải file lên. Tắt đi, việc upload vẫn hoạt động; chỉ những ứng dụng dựa vào nó để hiển thị tiến trình upload mới mất phần hiển thị đó.
Ứng dụng của tôi không bao giờ đổi serialize handler, có cần làm gì không?
Theo PHP, ứng dụng không đổi serialize handler trong lúc chạy có thể để session upload progress bật mà không bị lộ qua con đường này. Dù vậy, bạn vẫn cần cập nhật bản vá PHP2Shell.
CVE-2026-115560 có đang bị tấn công không?
Chưa có báo cáo nào. Các cuộc tấn công ghi nhận từ ngày 21/10 đều nhắm vào hai lỗi PHP2Shell CVE-2026-109618 và CVE-2026-109619.
