Chia sẻ đam mê công nghệ
Bảo mật

Hai lỗ hổng PHP cho phép chạy mã từ xa: cách vá đúng runtime

PHP đã phát hành bản sửa cho hai lỗ hổng nghiêm trọng có thể cho phép chạy mã từ xa mà không cần đăng nhập. Hãy kiểm tra đúng PHP đang phục vụ website, cập nhật cả các image container và chỉ coi cấu hình giảm thiểu là biện pháp tạm thời.

Tóm tắt nhanh

  • Hai lỗi CVE-2026-109618 và CVE-2026-109619 có thể dẫn tới thực thi mã từ xa không cần xác thực trong một số điều kiện.
  • Các bản PHP upstream đã vá là 8.5.12, 8.4.27, 8.3.36 và 8.2.35; gói của nhà phân phối có thể dùng cách đánh số riêng.
  • Hãy kiểm tra phiên bản của PHP-FPM, mod_php hoặc runtime web thực tế; lệnh PHP CLI không chứng minh máy chủ đã được vá.
  • Cấu hình giảm thiểu không thay thế bản cập nhật. Với container, cần cập nhật image, dựng lại và triển khai lại.

Hai lỗ hổng PHP được công bố ngày 21/10/2026 đều có thể mở đường cho kẻ tấn công chạy mã trên máy chủ mà không cần tài khoản, nếu hệ thống rơi vào các điều kiện khai thác tương ứng. PHP đã phát hành bản sửa cho bốn nhánh còn hỗ trợ; việc đầu tiên của quản trị viên là xác định đúng runtime đang nhận lưu lượng web, thay vì chỉ chạy một lệnh kiểm tra trên máy cá nhân.

Hai lỗi nằm trong xử lý bộ nhớ của PHP

Sơ đồ minh họa lỗi OOM trong PHP và dữ liệu request chưa hoàn chỉnh
Sơ đồ trong video diễn giải vì sao lỗi OOM có thể khiến PHP xử lý dữ liệu request chưa hoàn chỉnh. Ảnh: Mr. Cloud Book

CVE-2026-109618 bắt nguồn từ tình huống PHP hết bộ nhớ khi một phần dữ liệu nội bộ của request chưa được khởi tạo hoàn chỉnh. Đường xử lý kết thúc sớm nhưng quy trình dọn request vẫn có thể đọc trạng thái không hợp lệ. Advisory của PHP ghi nhận đường tấn công đã được xác nhận trên Apache mod_php, trong đó việc xử lý request có thể gặp lỗi trước khi mã ứng dụng bắt đầu chạy. PHP-FPM cũng được đánh giá có khả năng bị ảnh hưởng qua những đường xử lý ở cấp ứng dụng, dù cơ chế cụ thể khác nhau.

CVE-2026-109619 liên quan trạng thái toàn cục còn trỏ tới vùng nhớ thuộc request trước. Khi worker phục vụ request kế tiếp, một thao tác có thể dùng lại trạng thái cũ sau khi vùng nhớ đã được giải phóng. Một số tình huống cần request tạo trạng thái và request sử dụng trạng thái đó đi qua cùng worker; nhiều worker hoặc tái tạo worker không loại bỏ được lỗ hổng.

CISA mô tả cả hai lỗi là có thể dẫn tới thực thi mã từ xa không cần xác thực, đồng thời cho biết chưa quan sát thấy khai thác thành công ngoài thực tế tại thời điểm cảnh báo được phát hành. Điều đó không làm giảm nhu cầu vá: một máy chủ còn dễ bị tổn thương vẫn có thể bị nhắm tới, nhưng không nên diễn giải cảnh báo thành bằng chứng hệ thống đã bị xâm nhập.

Cập nhật bản PHP đã vá và xác minh gói của nhà phân phối

Danh sách phiên bản PHP đã vá CVE-2026-109618 và CVE-2026-109619
Các nhánh PHP đã vá được liệt kê ở đây; gói hệ điều hành có thể mang số phiên bản riêng. Ảnh: Mr. Cloud Book

Các phiên bản PHP upstream có bản sửa là 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Nếu hệ thống cài PHP qua Debian, Ubuntu, RHEL hoặc một nhà cung cấp hosting, hãy đối chiếu thông báo bảo mật và số phiên bản gói do chính nhà phân phối công bố. Họ có thể đưa bản vá ngược vào gói cũ mà không đổi số phiên bản upstream theo cách dễ nhận ra.

Ưu tiên máy chủ công khai trên Internet và những hệ thống xử lý dữ liệu quan trọng. CISA khuyến nghị tổ chức chưa thể cập nhật, hoặc vẫn chạy nhánh PHP 8.1 trở về trước không còn được hỗ trợ upstream, đưa các hệ thống PHP liên quan offline cho tới khi có thể cập nhật. WAF có thể hỗ trợ giảm rủi ro trong lúc xử lý, nhưng không phải bản vá.

Kiểm tra PHP đang phục vụ web, không chỉ PHP CLI

Lệnh php -v cho biết phiên bản mà shell hiện tại gọi; nó có thể trỏ tới binary khác với PHP-FPM hoặc module PHP mà web server đang dùng. Xác minh dịch vụ thực tế qua quản lý gói, cấu hình pool và trạng thái tiến trình, rồi kiểm tra gói đã cài theo hướng dẫn của hệ điều hành. Tránh để lộ trang phpinfo công khai; nếu cần dùng trong môi trường kiểm soát, gỡ nó ngay sau khi kiểm tra.

Kiểm kê mọi nơi PHP có thể chạy: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed và các máy hoặc dịch vụ ít được theo dõi. PHP có thể nằm bên trong sản phẩm khác nên danh sách máy chủ ứng dụng không phải lúc nào cũng cho thấy đầy đủ. Với container, cập nhật PHP trên host không sửa nội dung image. Hãy lấy image nền đã vá, kiểm tra runtime bên trong, dựng lại image, triển khai các container mới và rà soát registry cùng môi trường triển khai để tìm image cũ còn được sử dụng.

Cấu hình chỉ giảm rủi ro trong lúc chờ vá

Hai advisory của PHP không đưa ra một nhóm cấu hình chung có thể thay thế cập nhật. Với lỗi stale-state, không có biện pháp cấu hình tổng quát đáng tin cậy vì nhiều đường xử lý của ứng dụng, extension hoặc máy chủ có thể tạo và sử dụng trạng thái cũ. Việc tắt một tính năng cụ thể chỉ chặn một số đường đã biết.

Trong trường hợp buộc phải trì hoãn cập nhật, quản trị viên có thể xem hướng dẫn giảm thiểu trong advisory chính thức: kiểm soát kích thước request tại frontend, giới hạn số lượng và độ sâu các trường gửi lên, rà soát multipart upload và khởi động lại worker sau khi áp dụng cấu hình phù hợp. Những biện pháp này giảm một số điều kiện gây cạn bộ nhớ hoặc hạn chế đường khai thác cụ thể; chúng không bảo đảm máy chủ an toàn. Đừng coi việc chỉnh memory_limit, tắt session upload progress hay thay đổi một thiết lập đơn lẻ là đã vá xong.

Sau khi cập nhật, kiểm tra log và tiến trình bất thường, nhất là PHP worker khởi chạy shell hoặc tải công cụ lạ. CISA khuyến nghị theo dõi các dấu hiệu đó; nếu phát hiện, cần xử lý như một sự cố bảo mật riêng thay vì chỉ nâng phiên bản PHP rồi kết luận đã sạch.

Nguồn tham khảo: PHP advisory CVE-2026-109618; PHP advisory CVE-2026-109619; CISA; OWASP PHP Configuration Cheat Sheet.

Bài này thế nào?

Theo dõi TekCafe: Facebook · YouTube

Bài viết mới nhất