CẢNH BÁO KHẨN CẤP: Lỗi hổng bảo mật PHP2Shell

20 giờ ago
Long Vân
10 minutes

1. PHP2Shell là gì?

PHP2Shell là tên gọi chung của hai lỗ hổng rất nghiêm trọng nằm trong lõi PHP: CVE-2026-109618 và CVE-2026-109619. Cả hai đều đạt 9.2 trên thang CVSS v4.0. Chỉ cần một trong hai lỗi là kẻ tấn công không cần đăng nhập vẫn có thể chạy mã trên máy chủ, với quyền của tài khoản chạy PHP, bằng các yêu cầu HTTP được chế tạo đặc biệt.

Nói đơn giản: kẻ tấn công có thể điều khiển máy chủ của bạn từ xa mà không cần biết bất kỳ mật khẩu nào.

Hai lỗi hoạt động theo hai cơ chế khác nhau:

  • CVE-2026-109618: khi PHP hết bộ nhớ (out-of-memory), một yêu cầu có thể bị ngắt giữa chừng lúc dữ liệu nội bộ mới khởi tạo dở dang. Bước dọn dẹp cuối yêu cầu sau đó coi dữ liệu hỏng này là hợp lệ.
  • CVE-2026-109619: một yêu cầu bị chết do lỗi nghiêm trọng hoặc hết bộ nhớ sẽ để lại các con trỏ trỏ vào vùng nhớ đã giải phóng, và yêu cầu kế tiếp trên cùng worker sẽ chạm vào chúng.

2. Vì sao lần này đặc biệt nguy hiểm?

Lỗi nằm ở PHP, không phải ở code của bạn. Magento, Shopware và WooCommerce vẫn bị ảnh hưởng dù mã nguồn của chúng không có lỗi. Code sạch cũng không giúp gì nếu PHP bên dưới chưa được vá.

Phạm vi ảnh hưởng rất rộng. Mọi máy chủ chạy PHP từ 5.4 trở lên đều bị ảnh hưởng. Các nhà nghiên cứu đã xác nhận khai thác thành công không cần đăng nhập trên Magento 2.4.9 và mười ứng dụng PHP khác.

Việc khai thác đã bắt đầu. Chi tiết kỹ thuật bị rò rỉ trước thời điểm công bố phối hợp và phát hành bản vá chính thức. Theo watchTowr, hai lỗi đã bị khai thác ngoài thực tế. Đây là sự cố đang diễn ra, không còn là rủi ro lý thuyết.

Lỗi tồn tại rất lâu. Nhóm nghiên cứu Wiz cho biết các lỗi gốc đã có hàng chục năm, nhưng việc khai thác đòi hỏi chuỗi bước cực kỳ phức tạp. Các mô hình AI tiên tiến đã hạ thấp rào cản đó. Nói cách khác, những lỗi mà trước đây hầu như không ai khai thác nổi nay có thể bị tận dụng nhanh hơn rất nhiều.

3. Rủi ro đối với website và máy chủ

Nếu bị khai thác thành công, kẻ tấn công có thể:

  • Cài web shell (cửa hậu) để quay lại bất cứ lúc nào, kể cả sau khi bạn đã vá lỗi.
  • Đánh cắp dữ liệu nhạy cảm: thông tin khách hàng, tệp cấu hình, mật khẩu cơ sở dữ liệu, khóa API, khóa thanh toán. Ngoài RCE, lỗi còn cho phép đọc tệp tùy ý và làm lộ bộ nhớ máy chủ.
  • Chèn mã độc vào website: trang lừa đảo, mã đánh cắp thẻ thanh toán, chuyển hướng quảng cáo, SEO spam.
  • Sử dụng máy chủ của bạn để đào tiền ảo, gửi thư rác, tấn công DDoS hoặc xâm nhập tiếp các hệ thống trong mạng nội bộ.
  • Làm gián đoạn dịch vụ: lỗi có thể làm worker bị crash.

Nếu một máy chủ chứa nhiều website (shared hosting, VPS dùng chung), một website bị chiếm có thể kéo theo các website còn lại.

4. Giải pháp triệt để: nâng cấp PHP ngay

Đây là cách duy nhất khắc phục hoàn toàn. Các biện pháp tạm thời ở phần sau chỉ giảm rủi ro, không loại bỏ nó.

Các phiên bản đã có bản vá

PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Hãy nâng cấp lên bản vá mới nhất trong nhánh bạn đang dùng.

Các bước thực hiện

  1. Kiểm tra phiên bản hiện tại: chạy php -v. Lưu ý rằng CLI có thể khác với PHP-FPM hoặc Apache, nên cần kiểm tra cả phiên bản mà web server thực sự dùng (ví dụ php-fpm8.4 -v).
  2. Cập nhật gói PHP bằng trình quản lý gói của hệ điều hành (apt, dnf, yum…) hoặc kho gói bạn đang dùng. Với AlmaLinux 8, 9 và 10, gói đã vá được đưa lên kho almalinux-testing cho mọi nhánh PHP, kể cả các nhánh đã ngừng hỗ trợ. Các bản phân phối khác nên được kiểm tra theo thông báo bảo mật của nhà cung cấp.
  3. Khởi động lại PHP-FPM hoặc Apache để tiến trình mới nạp bản đã vá. Cập nhật gói mà không khởi động lại thì các worker cũ vẫn chạy mã lỗi.
  4. Docker: đổi image sang tag đã vá, rồi build lại và triển khai lại container. Chỉ cập nhật bên trong container đang chạy là chưa đủ.
  5. Hosting hoặc control panel (cPanel, Plesk, DirectAdmin…): kiểm tra bản vá do nhà cung cấp phát hành và liên hệ để xác nhận đã áp dụng.
  6. Xác nhận lại sau khi nâng cấp: kiểm tra phiên bản PHP thực tế mà website đang chạy, không chỉ phiên bản cài trên đĩa.

Nếu bạn đang dùng PHP 7.x, 5.x hoặc 8.0/8.1

Hiện chưa có bản vá chính thức cho PHP 5 và 7. Với các phiên bản này:

  • Lên kế hoạch chuyển sang nhánh PHP 8 còn được hỗ trợ càng sớm càng tốt, và kiểm thử khả năng tương thích của ứng dụng trước.
  • Kiểm tra xem nhà cung cấp hệ điều hành hoặc dịch vụ hỗ trợ dài hạn của bạn có phát hành bản vá riêng không.
  • Trong lúc chờ, áp dụng toàn bộ các biện pháp tạm thời ở phần 5 và hạn chế truy cập tối đa.
  • Lưu ý rằng PHP 8.2 cũng sẽ hết vòng đời hỗ trợ vào ngày 31/12/2026, nên nếu đang nâng cấp thì nên cân nhắc nhảy thẳng lên nhánh mới hơn.

5. Biện pháp tạm thời khi chưa thể nâng cấp ngay

Dùng các biện pháp này để kéo dài thời gian an toàn trong lúc chuẩn bị nâng cấp, không phải để thay thế. Theo các nhà nghiên cứu, chỉ có bản vá mới là giải pháp giảm thiểu đầy đủ, còn các biện pháp còn lại chỉ mang tính một phần.

Biện pháp 1: Tắt session upload progress (nên làm đầu tiên)

Khuyến nghị an ninh của chính PHP là đặt session.upload_progress.enabled=0. Thêm vào php.ini hoặc cấu hình pool PHP-FPM: 

session.upload_progress.enabled = 0

Với PHP-FPM, có thể đặt trong pool:

php_admin_flag[session.upload_progress.enabled] = off

Sau khi đổi cấu hình phải khởi động lại mọi worker. PHP xác nhận cách này chặn các đường tấn công liên quan đến session, nhưng không chặn mọi biến thể

Biện pháp 2: Điều chỉnh giới hạn bộ nhớ (chỉ trong một số trường hợp)

Các nhà nghiên cứu nêu đây là biện pháp giảm thiểu một phần: với PHP-FPM thì tắt upload progress và đặt memory_limit=-1, còn với mod_php thì đặt memory_limit=-1. Lý do là CVE-2026-109618 dựa vào việc ép PHP chạm giới hạn bộ nhớ, và trên mod_php, các form POST thông thường cũng có thể kích hoạt lỗi này.

Đây là điểm cần cân nhắc kỹ. Bỏ giới hạn bộ nhớ có thể khiến một yêu cầu bất thường ngốn hết RAM của máy chủ. Nếu áp dụng, hãy giám sát tài nguyên chặt chẽ, và chỉ coi đây là biện pháp ngắn hạn trước khi nâng cấp.

Nguồn tham khảo:

Thông tin được tổng hợp ngày 22/10/2026 và có thể thay đổi nhanh. Trước khi triển khai trên môi trường thực tế, hãy đối chiếu với thông báo bảo mật chính thức của PHP và nhà cung cấp hệ điều hành, đồng thời thử các cấu hình chặn trên môi trường kiểm thử nếu có thể.

Post Views: 27