Cảnh báo PHP2Shell: hai lỗ hổng nghiêm trọng trong PHP, cần cập nhật ngay

Ngày 21/10/2026, nhóm phát triển PHP phát hành bản vá khẩn cho hai lỗ hổng nghiêm trọng trong lõi PHP: CVE-2026-109618 và CVE-2026-109619, giới bảo mật gọi chung là PHP2Shell. Cả hai đều cho phép thực thi mã từ xa mà không cần đăng nhập, điểm CVSS 4.0 là 9,2.

Hệ thống máy chủ do Cloudzone quản trị đã được cập nhật bản vá cần thiết. Bài này dành cho quý Khách hàng đang tự quản trị máy chủ của mình, và cho những ai cần nắm tình hình để rà soát hệ thống khác trong đơn vị.

1. Hai lỗi bảo mật PHP2Shell

CVE-2026-109618 nằm ở khâu cấp phát bộ nhớ lúc PHP khởi tạo một yêu cầu. Khi lượng bộ nhớ cần dùng vượt ngưỡng memory_limit đúng vào thời điểm nhất định, PHP để lại một ô dữ liệu được đếm nhưng chưa khởi tạo. Lúc dọn dẹp cuối yêu cầu, PHP xử lý ô đó như dữ liệu hợp lệ, và kẻ tấn công điều khiển được lời gọi hàm từ đây.

CVE-2026-109619 là lỗi dùng lại vùng nhớ đã giải phóng, do trạng thái của tiến trình xử lý còn sót lại từ yêu cầu trước. Hai đường khai thác đã được xác nhận: phần ghi vết khi gặp lỗi nghiêm trọng (chỉ PHP 8.5), và phần xử lý tải tệp lên. Đường thứ hai đáng lo hơn vì tính năng theo dõi tiến độ tải tệp bật sẵn trong cấu hình mặc định.

2. Vì sao hai lỗi này nguy hiểm hơn bình thường

• Lỗi nằm ở lõi PHP, không phải ở ứng dụng. PHP phân tích yêu cầu trước khi mã ứng dụng chạy, nên màn đăng nhập, khoá IP hay phân quyền trong ứng dụng đều không chặn được.
• Cấu hình mặc định cũng dính. Không cần quý Khách hàng bật thêm tuỳ chọn lạ nào.
• Mọi cách chạy PHP phục vụ web đều ảnh hưởng: Apache kèm mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed.
• Đã bị khai thác thật. AWS ghi nhận các lần thử khai thác từ 17/10, bốn ngày trước khi lỗ hổng được công bố. Mã khai thác công khai nay đã có, và nhiều hãng bảo mật báo đang có quét diện rộng.
• Quy mô phơi nhiễm rất lớn. Đơn vị Cortex Xpanse của Palo Alto Networks đếm được hơn 22,6 triệu máy đang phơi ra Internet có khả năng dính lỗi.

Tới ngày 21/10, CISA cho biết chưa ghi nhận vụ xâm nhập thành công nào. Nhưng ngày 23/10, nhóm Unit 42 của Palo Alto Networks ghi nhận một cơ quan chính phủ tại châu Âu bị khai thác thật: trong vòng hai giờ kể từ lúc xâm nhập, kẻ tấn công đã lấy được mã băm mật khẩu và khoá xác thực hai lớp, rồi mở đường vào hệ thống quản lý tài khoản nội bộ. Một cơ quan chính phủ khác ở châu Âu đã chủ động tắt website để phòng ngừa.

3. Dịch vụ Cloudzone: phần nào đã vá, phần nào quý Khách hàng phải tự làm

Đây là phần quan trọng nhất của bài, vì câu trả lời khác nhau theo từng loại dịch vụ.

Vì sao VPS và máy chủ vật lý lại khác. Hai dịch vụ này là máy riêng của quý Khách hàng, toàn quyền quản trị thuộc về quý Khách hàng. PHP cài trên đó do quý Khách hàng cài và nâng cấp; Cloudzone không vào trong máy để vá lỗi/nâng cấp thay cho khách hàng. Nếu máy chủ có chạy PHP phục vụ web, dù là website, API hay một bảng quản trị nội bộ, thì đây là việc cần làm trong hôm nay.

4. Kiểm tra phiên bản PHP đang chạy

Trên Linux, chạy một trong các lệnh sau:

php -v
php-fpm -v
/usr/local/php82/bin/php -v

Trên Windows Server, mở thư mục cài PHP rồi chạy php.exe -v.

Ba chỗ hay bỏ sót:

• Nhiều phiên bản PHP cùng tồn tại trên một máy. Bản chạy ở dòng lệnh thường khác bản đang phục vụ web. Hãy kiểm cả php-fpm và cấu hình của web server.
• PHP nằm bên trong phần mềm khác. Bảng quản trị hosting, công cụ giám sát, ứng dụng đóng gói sẵn, ảnh Docker đều có thể mang theo PHP riêng.
• Số hiệu phiên bản không phải lúc nào cũng nói lên tình trạng vá. Nhà cung cấp hệ điều hành thường ghép bản vá vào mà không đổi số hiệu. Thấy số cũ chưa chắc là chưa vá, nhưng cũng đừng cho là đã vá: phải đọc thông báo bảo mật của chính nhà cung cấp hệ điều hành đó.

5. Cập nhật như thế nào

Đích cần đạt là một trong bốn phiên bản đã vá, hoặc bản do nhà cung cấp hệ điều hành phát hành có kèm bản vá cho hai CVE này.

Cài bằng trình quản lý gói của hệ điều hành thì cập nhật gói PHP theo cách thường dùng, rồi khởi động lại toàn bộ tiến trình xử lý. Đây là bước hay bị quên: gói mới đã nằm trên đĩa nhưng tiến trình cũ vẫn đang chạy mã cũ trong bộ nhớ, nên máy vẫn dính lỗi cho tới khi khởi động lại.

systemctl restart php8.2-fpm
systemctl restart httpd

Sau khi khởi động lại, kiểm lại phiên bản một lần nữa để chắc tiến trình đang phục vụ web thật sự là bản mới.

6. Đang dùng PHP 8.1 trở về trước

PHP 8.1 và các nhánh cũ hơn đã hết hạn hỗ trợ, không còn bản vá theo chu kỳ bình thường. Lần này nhóm PHP có phát hành bản vá dạng mã nguồn cho 7.4, 8.0 và 8.1 ngoài chu kỳ hỗ trợ, nhưng áp được bản vá đó đòi hỏi tự biên dịch hoặc chờ nhà cung cấp hệ điều hành đóng gói.

CISA khuyến cáo: nếu đang chạy PHP 8.1 trở về trước mà chưa vá được ngay, hãy tạm ngắt hệ thống khỏi Internet cho tới khi vá xong hoặc nâng lên nhánh còn được hỗ trợ.

Đây cũng là lúc nên tính việc nâng hẳn lên nhánh mới. Chạy một nhánh PHP đã hết hỗ trợ nghĩa là lần sau có lỗ hổng tương tự, quý Khách hàng sẽ không có bản vá nào để áp.

7. Phương án tạm thời nếu chưa vá ngay được

Không có cách nào thay được bản vá. Các biện pháp dưới đây chỉ thu hẹp đường khai thác trong lúc chờ, và phải gỡ bỏ sau khi đã vá xong:

• Tắt theo dõi tiến độ tải tệp: session.upload_progress.enabled=0
• Riêng PHP 8.5, tắt thêm phần ghi vết lỗi nghiêm trọng: fatal_error_backtraces=0
• Đặt hai tuỳ chọn trên vào tệp cấu hình được nạp trước khi PHP phân tích yêu cầu, rồi khởi động lại toàn bộ tiến trình xử lý
• Giới hạn kích thước thân yêu cầu ở tầng máy chủ web hoặc reverse proxy
• Đưa tường lửa ứng dụng web ra trước PHP để chặn bớt yêu cầu trước khi tới nơi phân tích
• Thu hẹp phạm vi truy cập của các ứng dụng nội bộ đang phơi ra Internet

8. Dấu hiệu máy chủ đã bị khai thác

Vá xong vẫn nên rà lại, vì lỗ hổng đã bị thử khai thác từ trước ngày công bố. Những dấu hiệu đáng chú ý:

• Tiến trình PHP sinh ra tiến trình con bất thường, ví dụ sh, bash, curl, wget, python
• Tiến trình xử lý PHP chết hoặc khởi động lại liên tục trong nhật ký. Khai thác lỗi này thường phải thử nhiều lần và làm sập tiến trình
• Tệp lạ mới xuất hiện trong thư mục web, nhất là tệp .php có tên ngẫu nhiên hoặc nội dung mã hoá
• Tác vụ theo lịch, khoá SSH hoặc tài khoản quản trị mới mà không ai trong đơn vị tạo ra
• Kết nối ra ngoài bất thường từ chính máy chủ web

Nghi ngờ máy đã bị xâm nhập thì vá thôi là chưa đủ. Kẻ tấn công thường để lại đường quay lại, nên phải rà toàn bộ, đổi toàn bộ mật khẩu và khoá, rồi mới tính tới việc đưa dịch vụ trở lại.

9. Câu hỏi thường gặp

Website của tôi chạy trên Web Hosting của Cloudzone, tôi có phải làm gì không?
Không. PHP trên hosting do Cloudzone quản trị và đã được cập nhật bản vá.

Tôi thuê VPS ở Cloudzone, vậy Cloudzone vá giúp tôi chứ?
Không. VPS là máy riêng của quý Khách hàng, Cloudzone không truy cập vào trong máy. Phần hạ tầng bên dưới thì Cloudzone lo, còn PHP cài trong VPS thì quý Khách hàng tự cập nhật.

Ứng dụng của tôi có màn đăng nhập, như vậy có an toàn hơn không?
Không. Lỗi nằm ở lõi PHP và được kích hoạt trước khi mã ứng dụng chạy, nên lớp đăng nhập không chặn được.

Website tôi viết bằng ngôn ngữ khác, không dùng PHP, có ảnh hưởng không?
Không ảnh hưởng trực tiếp. Nhưng nên rà cả những phần mềm phụ trợ trên cùng máy chủ, vì nhiều bảng quản trị và công cụ giám sát mang theo PHP riêng.

Vá xong rồi có cần đổi mật khẩu không?
Nếu không có dấu hiệu bất thường thì không bắt buộc. Nhưng nếu máy chủ phơi ra Internet và chạy phiên bản dính lỗi trong khoảng từ ngày 17/10 tới lúc vá, việc đổi mật khẩu quản trị và khoá truy cập là bước phòng ngừa nên làm.

Quý Khách hàng cần Cloudzone hỗ trợ kiểm tra hoặc cập nhật PHP trên máy chủ của mình, vui lòng chat với Cloudzone.