PHP phát hành bản vá khẩn cấp cho các lỗ hổng thực thi mã từ xa nghiêm trọng PHP2Shell

Dự án PHP đã phát hành các bản cập nhật bảo mật khẩn cấp vào ngày 21 tháng 10 năm 2026 để giải quyết hai lỗ hổng nghiêm trọng được gọi chung là PHP2Shell. Những lỗ hổng này nằm trong core runtime của PHP chứ không phải ở các ứng dụng riêng lẻ, cho phép kẻ tấn công thực thi mã tùy ý trên máy chủ web mà không cần xác thực. Bản phát hành đã được đẩy sớm hơn một ngày so với kế hoạch sau khi chi tiết về các lỗ hổng bị rò rỉ trực tuyến, buộc đội ngũ bảo mật PHP phải hành động ngay lập tức.

Chuyện gì đã xảy ra

Các lỗ hổng, được định danh là CVE-2026-109618 và CVE-2026-109619, mang mức độ nghiêm trọng CVSS v4.0 là 9.2. Chúng ảnh hưởng đến gần như mọi phiên bản PHP kể từ PHP 5.4 trở đi. Các bản vá có sẵn trong PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Vì những lỗi này tồn tại ngay trong engine ngôn ngữ, nên ngay cả một trang "Hello World" tĩnh được phục vụ bởi một cài đặt PHP dễ bị tổn thương cũng gặp rủi ro. Mối nguy hiểm cao nhất nằm ở các máy chủ sử dụng mod_php của Apache, nơi một yêu cầu đơn lẻ chưa được xác thực có thể kích hoạt cuộc tấn công trước khi bất kỳ đoạn mã ứng dụng nào được thực thi.

Các nhà nghiên cứu từ Wiz, Calif và OpenAI đã phát hiện và báo cáo những lỗ hổng này. Công việc của họ, được hỗ trợ bởi các công cụ AI, đã đẩy nhanh quá trình xác định các exploit hoạt động được đối với đoạn mã đã tồn tại trong PHP hơn một thập kỷ. Trước khi bản vá chính thức được tung ra, Cloudflare đã quan sát thấy các nỗ lực khai thác sớm nhắm vào khách hàng của mình. Vào thời điểm các bản vá được phát hành, công ty an ninh watchTowr xác nhận các nỗ lực khai thác đang diễn ra đối với cả hai CVE, mặc dù chưa có vụ đột nhập thành công cụ thể nào được xác nhận công khai vào thời điểm đó. Các dịch vụ lớn, bao gồm BambooHR và một số nền tảng chính phủ Hà Lan, đã tạm ngừng hệ thống như một biện pháp phòng ngừa.

Cơ chế hoạt động

Những lỗ hổng này cho phép kẻ tấn công đọc bộ nhớ từ tiến trình worker PHP và có khả năng đạt được quyền thực thi mã từ xa. Việc truy cập bộ nhớ này có thể làm lộ dữ liệu nhạy cảm như mật khẩu, khóa API và token xác thực từ các yêu cầu khác mà kẻ tấn công không cần phải có đặc quyền thực thi mã trước. Hồ sơ rủi ro thay đổi tùy theo cấu hình máy chủ. Trong khi mod_php rất dễ bị khai thác ngay lập tức, PHP-FPM cung cấp một số khả năng kháng cự tự nhiên vì nó kết thúc các worker khi yêu cầu thất bại trong quá trình thiết lập. Tuy nhiên, các nhà nghiên cứu đã chứng minh rằng một trong những lỗ hổng vẫn có thể dẫn đến thực thi mã trên PHP-FPM dưới các điều kiện cụ thể liên quan đến các thao tác trong ứng dụng đang chạy.

Quá trình công bố thông tin đã bị gián đoạn khi một công ty nghiên cứu vô tình đăng tải video proof-of-concept (chứng minh khái niệm) và một nhà cung cấp xuất bản các container image đã được vá vài giờ trước bản phát hành chính thức. Sự tiếp xúc sớm này buộc đội ngũ PHP phải đẩy nhanh tiến độ. Các vấn đề cốt lõi bắt nguồn từ cơ chế quản lý bộ nhớ phức tạp và xử lý phiên đã là một phần của PHP trong nhiều năm. Một cuộc kiểm toán bên ngoài năm 2024 ban đầu đã đánh dấu các dấu hiệu của lỗi out-of-memory đứng sau CVE-2026-109618, nhưng một vector tấn công cụ thể chỉ được thiết lập khi nghiên cứu gần đây có sự hỗ trợ của AI làm rõ con đường khai thác.

Chi tiết chính

• Phiên bản bị ảnh hưởng: Tất cả các phiên bản PHP từ 5.4 trở lên đến 8.5.11, 8.4.26, 8.3.35 và 8.2.34 đều dễ bị tổn thương.
• Phiên bản đã sửa lỗi: Hãy cập nhật ngay lập tức lên PHP 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35.
• Rủi ro cao nhất: Các máy chủ sử dụng Apache mod_php dễ bị tổn thương nhất trước việc thực thi mã từ xa không cần xác thực.
• Biện pháp giảm thiểu một phần: Đối với CVE-2026-109619, việc đặt session.upload_progress.enabled=0 sẽ giảm rủi ro nhưng không khắc phục hoàn toàn vấn đề.
• Hỗ trợ phiên bản cũ: PHP 8.1 và các phiên bản cũ hơn đã hết hạn hỗ trợ (end-of-life); các bản backport mã nguồn có sẵn cho PHP 7.4, 8.0 và 8.1 dành cho những ai xây dựng từ mã nguồn.
• Dấu hiệu phát hiện: Tìm kiếm các yêu cầu multipart bất thường, lỗi giới hạn bộ nhớ, phản hồi HTTP 500 lặp lại và các lần khởi động lại PHP worker không mong muốn.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và trưởng nhóm IT, sự cố này nhấn mạnh sự khác biệt quan trọng giữa bảo mật cấp ứng dụng và các lỗ hổng cấp runtime. Việc cập nhật các framework như Laravel hoặc WordPress không bảo vệ bạn khỏi PHP2Shell vì lỗ hổng tồn tại trong interpreter cơ sở. Điều này có nghĩa là ngay cả các ứng dụng đã được kiểm toán kỹ lưỡng cũng bị phơi bày nếu môi trường máy chủ chưa được vá. Tốc độ mà nghiên cứu có hỗ trợ AI biến các lỗi lý thuyết lâu đời thành các exploit hoạt động được cũng nhấn mạnh nhu cầu về chu kỳ vá lỗi nhanh chóng. Chờ đợi cửa sổ bảo trì theo lịch trình không còn là chiến lược khả thi đối với các lỗ hổng runtime nghiêm trọng.

Sự gián đoạn gây ra bởi các vụ rò rỉ sớm và nỗ lực khai thác đang diễn ra cho thấy sự mong manh của quy trình công bố thông tin phối hợp trong bối cảnh mối đe dọa hiện đại. Các tổ chức phải có kế hoạch phản ứng sự cố vững chắc, bao gồm khả năng cập nhật nhanh chóng các thành phần hạ tầng. Chỉ dựa vào các chỉnh sửa cấu hình như một chiến lược giảm thiểu là nguy hiểm, vì các nhà phát triển core PHP đã tuyên bố rõ ràng rằng chỉ có việc cập nhật mới cung cấp sự bảo vệ hoàn toàn. Sự kiện này là lời nhắc nhở rằng các phụ thuộc hạ tầng đòi hỏi mức độ cảnh giác tương đương với mã ứng dụng.

Bạn có thể làm gì

• Xác định tất cả các máy chủ chạy PHP và kiểm tra số phiên bản hiện tại của chúng so với các bản phát hành đã sửa lỗi được liệt kê ở trên.
• Cập nhật gói runtime PHP thông qua trình quản lý gói hệ thống của bạn hoặc xây dựng lại các container image với các phiên bản đã được vá.
• Khởi động lại tất cả các máy chủ web, pool PHP-FPM và các worker PHP chạy dài hạn để đảm bảo binary mới được nạp.
• Nếu không thể cập nhật ngay lập tức, hãy áp dụng các biện pháp giảm thiểu một phần như tắt tính năng upload progress của phiên và áp dụng giới hạn bộ nhớ chặt chẽ, nhưng hãy lên kế hoạch vá lỗi càng sớm càng tốt.
• Giám sát nhật ký để tìm các chỉ báo xâm phạm, bao gồm các gửi biểu mẫu multipart lạ và sự gia tăng đột ngột của các lỗi 500.
• Xác minh rằng changelog của gói phân phối Linux của bạn bao gồm các bản sửa lỗi CVE liên quan, vì chuỗi phiên bản đôi khi không phản ánh đúng trạng thái vá lỗi trong các bản phân phối LTS.