php2shell: hai lỗ hổng PHP nghiêm trọng CVE-2026-109618 và CVE-2026-109619 — doanh nghiệp phải cập nhật ngay

Ngày 21/10/2026, dự án PHP phát hành bản vá khẩn cho hai lỗ hổng mà giới bảo mật gọi chung là php2shell: CVE-2026-109618 và CVE-2026-109619. Cả hai đều được PHP chấm 9,2/10 (Critical) và cho phép kẻ tấn công chạy mã từ xa mà không cần đăng nhập trên máy chủ web dùng PHP. Nếu website, phần mềm quản lý hay cổng thông tin của doanh nghiệp bạn chạy PHP — WordPress, Laravel, Magento, Drupal, Joomla hay mã tự viết — thì câu trả lời ngắn gọn là: cập nhật lên PHP 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35 ngay hôm nay, khởi động lại mọi tiến trình PHP, rồi mới tính tiếp.

Chuyện gì đã xảy ra với PHP?

Đây là đợt vá bảo mật ngoài lịch của dự án PHP, sau khi chi tiết lỗ hổng bị lộ trước ngày công bố. Ngày 20/10/2026, nhóm bảo mật PHP gửi thông báo trước trên danh sách php.announce, hẹn phát hành bản vá lúc 14:00 UTC thứ Tư 21/10/2026 cho hai lỗ hổng "đều được chấm CVSS v4.0 9,2, Critical". Theo Tenable, lịch ban đầu là ngày 22/10 nhưng được kéo lên sớm một ngày vì mã CVE đã lan trên Hacker News và mạng xã hội — kèm một điểm CVSS sai là 10,0.

Huntress kể lại diễn biến: sáng 20/10, một bài trên Hacker News tuyên bố hai lỗ hổng PHP nghiêm trọng sắp được công bố; bài bị gỡ nhưng ảnh chụp màn hình đã kịp lan truyền. VirusTotal ghi nhận tệp lưu trữ được nhắc tới trong bài phân tích bị lộ được tải lên lần đầu lúc 02:29 UTC ngày 21/10, tức vài giờ trước khi có bản vá.

Theo dòng thời gian của Sansec, nhóm nghiên cứu Calif tìm ra nhiều đường thực thi mã từ ngày 01/08/2026 và báo lỗi đầu tiên cho PHP ngày 11/08; Wiz Research báo cáo các lỗ hổng cho PHP ngày 24/08. Advisory trên GitHub ghi nhận bốn người báo cáo và bốn lập trình viên khắc phục. Google Cloud còn viết rằng mô hình Gemini 4 Argon đã đóng góp vào việc tìm lỗ hổng và phát triển mã khai thác — một chi tiết cho thấy AI đang được dùng ở cả hai phía của bài toán bảo mật.

Cái tên "php2shell" không do PHP đặt. Các trang chính thức của PHP chỉ dùng mã CVE và mã advisory; tên này xuất hiện trong cảnh báo của CISA và các bài phân tích của giới nghiên cứu.

Hai lỗ hổng hoạt động thế nào?

Nói ngắn gọn: cả hai đều là lỗi quản lý bộ nhớ bên trong PHP, xảy ra trong lúc PHP đọc và dọn dẹp dữ liệu của một yêu cầu web — tức là trước khi mã ứng dụng của bạn kịp chạy. Vì vậy cơ chế đăng nhập, phân quyền hay tường lửa ở tầng ứng dụng không chặn được.

CVE-2026-109618 — hỏng bộ nhớ khi hết bộ nhớ. Theo advisory GHSA-w8hw-w9fx-j79w, PHP dùng longjmp() để thoát ngay khi một yêu cầu vượt giới hạn bộ nhớ. Nếu việc cấp phát thất bại đúng lúc dữ liệu nội bộ mới khởi tạo dở, PHP không ghi nhận đúng lần thoát sớm đó; bước dọn dẹp sau đó lại coi dữ liệu dở dang là hợp lệ. Kẻ tấn công kích hoạt điều kiện này bằng các yêu cầu multipart (loại yêu cầu dùng cho biểu mẫu và tải tệp) được dựng có chủ đích. Rapid7 lưu ý các yêu cầu này có thể làm cạn bộ nhớ "ngay cả khi kích thước của chúng có vẻ nằm trong giới hạn đã cấu hình". Hậu quả đã được xác nhận là chạy mã từ xa không cần xác thực, dưới quyền tài khoản của tiến trình web.

CVE-2026-109619 — dùng lại vùng nhớ đã giải phóng. Theo advisory GHSA-6wmf-4rv5-p3rp, một yêu cầu có thể để lại trạng thái nội bộ trỏ tới vùng nhớ đã bị giải phóng; yêu cầu kế tiếp do cùng tiến trình xử lý lại dùng trạng thái cũ đó trước khi PHP kịp khởi tạo lại. Hai đường khai thác được xác nhận là thông báo cấu hình phát sinh trước khi khởi tạo yêu cầu, và tính năng theo dõi tiến độ tải tệp của session. Hậu quả: rò rỉ bộ nhớ và chạy mã từ xa. Sansec mô tả thêm: trình xử lý tiến độ tải tệp có thể trả vùng nhớ đã giải phóng về cho trình duyệt ngay trong cookie PHPSESSID, kể cả khi ứng dụng không hề gọi session_start().

Ai bị ảnh hưởng, phiên bản nào an toàn?

Mọi bản PHP từ 5.4 tới trước các bản vá ngày 21/10/2026 đều nằm trong diện ảnh hưởng nếu đang phục vụ yêu cầu web. Thông báo bảo mật trên php.net viết rõ: nhóm có rủi ro là "mọi cài đặt PHP phục vụ yêu cầu web, gồm PHP-FPM, Apache với mod_php, php-cgi, FrankenPHP và LiteSpeed", và rủi ro cao nhất là mod_php, nơi đã có mã khai thác chứng minh rằng một yêu cầu ẩn danh có thể kích hoạt tấn công trước khi bất kỳ dòng mã ứng dụng nào chạy. Google Cloud tóm lại: dính là "mọi phiên bản PHP từ 5.4 tới 8.5.11".

Với các nhánh đã hết hỗ trợ, php.net cho biết nhóm bảo mật đã cung cấp "bản vá mã nguồn tối thiểu cho PHP 7.4, 8.0 và 8.1" dành cho người tự biên dịch hoặc không có nhà cung cấp hỗ trợ dài hạn — đó là các nhánh mã trên GitHub, không phải bản phát hành. CISA đi xa hơn: tổ chức còn dùng PHP 8.1 hoặc cũ hơn "nên đưa các hệ thống dùng PHP ra khỏi mạng cho tới khi vá hoặc nâng cấp".

Một điểm hay gây nhầm: số phiên bản không phải lúc nào cũng nói đúng tình trạng vá. Datadog và Red Hat đều cảnh báo các bản phân phối Linux đôi khi vá ngược (backport) mà không đổi số phiên bản gốc. Ngược lại, Red Hat cho biết RHEL 8, 9 và 10 bị ảnh hưởng, còn RHEL 7 trở về trước đi kèm các bản PHP không dính hai lỗi này. Người dùng kho Remi (rpms.remirepo.net) cần lưu ý: theo Sansec, kho này chưa có bản vá trong ngày 21/10.

Về ứng dụng: Tenable dẫn kết quả của Calif đã xác nhận chạy mã từ xa trước khi đăng nhập trên một số phiên bản cụ thể của WordPress, Drupal, Joomla và Magento. Datadog nói gọn hơn: bất kỳ tệp PHP nào cũng mở ra đường lỗi, kể cả tệp chỉ in ra một dòng chữ.

Mức độ nghiêm trọng thật đến đâu?

Nghiêm trọng, nhưng các bên chấm điểm khác nhau và đánh giá độ khó khai thác cũng khác nhau. PHP chấm 9,2 theo CVSS v4.0, với các thành phần "độ phức tạp cao" và "có điều kiện tiên quyết". Red Hat xếp mức "Important" thay vì Critical, chấm CVSS v3 là 8,1, và viết rằng việc khai thác ổn định "đòi hỏi thao tác heap và căn thời gian chính xác", nên chạy mã từ xa "khó trong thực tế" — đặc biệt với PHP-FPM, cấu hình mặc định trên RHEL.

Phần thực tế mới đáng lo. Datadog viết rằng nhóm của họ đã dựng mã khai thác trước ngày công bố, và giới hạn bộ nhớ mặc định của PHP vẫn bị khai thác được; bản tinh chỉnh trả về HTTP 200 và chạy xong trong 3,10 giây trong phòng thí nghiệm (một tiến trình, tắt OPcache). Rapid7 thì ghi nhận nhiều dấu hiệu cho thấy nghiên cứu đang được tái hiện độc lập và cho rằng một mã khai thác dùng được sẽ sớm công khai. Sansec, sau khi có bản vá và các bài phân tích, viết rằng "các bài phân tích và một công cụ khai thác đã công khai".

Còn chuyện tấn công đã diễn ra hay chưa thì các nguồn chưa thống nhất. Sansec dẫn Cloudflare báo cáo tấn công sớm lúc 07:43 UTC ngày 21/10, trước giờ phát hành bản vá; Datadog viết rằng tính đến 21/10 đã có nhiều báo cáo khai thác thực tế, kèm hoạt động quét diện rộng. Ở chiều ngược lại, CISA chưa ghi nhận khai thác lúc ra cảnh báo, và Huntress cho biết tới 16:30 giờ miền Đông nước Mỹ ngày 21/10 vẫn chưa thấy khai thác trên hệ thống khách hàng của họ. Một vài tổ chức không chờ: Sansec ghi nhận nhiều website ở Hà Lan, gồm Hạ viện và NCSC nước này, chủ động tạm ngừng hoạt động ngày 21/10; Unit 42 cho biết ít nhất một chính phủ châu Âu đã tạm gỡ website để phòng ngừa.

Doanh nghiệp phải làm gì trong 24 giờ?

Việc duy nhất khắc phục trọn vẹn là cập nhật PHP — mọi nguồn đều thống nhất điểm này. Rapid7 khuyến nghị cập nhật "khẩn cấp, ngoài chu kỳ vá thông thường". Thứ tự Namtech đề xuất cho doanh nghiệp:

1. Kiểm kê. Liệt kê mọi website, phần mềm nội bộ, cổng thông tin chạy PHP — kể cả máy chủ cũ ít ai nhớ, container và ứng dụng tự đóng gói PHP riêng. Datadog nhắc: đừng chỉ dựa vào bản PHP dòng lệnh trên máy.
2. Xác định phiên bản đang phục vụ web, không chỉ phiên bản dòng lệnh: xem trong bảng điều khiển hosting, trang thông tin PHP của máy chủ, hoặc hỏi nhà cung cấp. Đối chiếu với Bảng 2.
3. Cập nhật lên 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, rồi khởi động lại hoặc thay mới mọi tiến trình PHP còn chạy bản cũ; container thì phải build lại image và triển khai lại.
4. Chưa vá được thì giảm rủi ro bằng các cấu hình ở Bảng 4, và cân nhắc đặt sau WAF hoặc VPN, hoặc tạm tách khỏi Internet. Sansec khuyên thẳng: nếu tắt được máy chủ PHP, hãy tắt.
5. Rà dấu hiệu bị tấn công (xem mục kế tiếp) và đổi mật khẩu, khoá API, chứng chỉ trên máy chủ nghi ngờ, vì lỗi có thể làm lộ dữ liệu trong bộ nhớ.

Với hosting chia sẻ (cPanel, DirectAdmin…), quyền cập nhật PHP thường nằm ở nhà cung cấp. Hãy hỏi thẳng nhà cung cấp đã lên bản vá chưa và khi nào, thay vì chỉ đổi phiên bản PHP trong bảng điều khiển rồi yên tâm. Trên Google Cloud, Google cho biết App Engine standard (PHP 8.2 trở lên) được cập nhật tự động, còn App Engine flexible thì không; Cloud Run chỉ tự vá nếu đã bật cập nhật base image tự động, và GKE phải tự cập nhật image rồi triển khai lại.

Chính php.net viết rằng các biện pháp này "giảm rủi ro với một số đường tấn công cụ thể nhưng không làm hệ thống an toàn", và advisory còn nói thẳng "không có cách cấu hình chung nào khắc phục trọn vẹn". VirusTotal thêm một lưu ý dễ bị bỏ qua: expose_php = Off chỉ giấu tiêu đề phiên bản, không giấu được lỗ hổng.

Làm sao biết máy chủ đã bị tấn công?

Không có cách chắc chắn chỉ bằng nhật ký, nhưng có vài dấu hiệu nên rà ngay. Datadog mô tả mẫu nhật ký lỗi PHP dạng "Allowed memory size of … bytes exhausted … in Unknown on line 0" — vị trí "Unknown on line 0" nghĩa là PHP lỗi ngay trong giai đoạn khởi tạo yêu cầu. Khi mã khai thác đoán sai địa chỉ, Apache có thể ghi dòng AH00052: child pid … exit signal Segmentation fault (11). Yêu cầu đáng ngờ có thể mang một tên trường dài khoảng 3,5 MB. Dấu hiệu rõ nhất của tấn công thành công là tiến trình web tự mở shell.

Nhưng đừng yên tâm vì không thấy gì: Datadog lưu ý một lần khai thác thành công không nhất thiết làm sập tiến trình hay sinh lỗi, và Rapid7 viết rằng "không có dòng nhật ký liên quan không phải bằng chứng hệ thống an toàn". Với CVE-2026-109619, Rapid7 khuyên rà các cảnh báo cấu hình sớm, thông báo khi tắt, lỗi fatal và lỗi quá thời gian. Vì lỗi có thể làm lộ mật khẩu, token phiên, khoá API và khoá riêng TLS từ các yêu cầu khác (theo Sansec), máy chủ nào nghi ngờ thì nên coi như bí mật đã lộ và thay mới.

Bài học cho doanh nghiệp Việt Nam

php2shell nhắc lại một điều cũ: rủi ro lớn nhất thường nằm ở phần mềm nền mà doanh nghiệp không ai để ý. PHP được 69,3% website có ngôn ngữ phía máy chủ xác định được sử dụng (Tenable dẫn W3Techs), nên gần như doanh nghiệp nào cũng có ít nhất một hệ thống PHP — website giới thiệu, trang bán hàng, phần mềm nhân sự, cổng nội bộ. Con số của VirusTotal còn đáng ngại hơn: khoảng 4/5 máy chủ PHP giấu phiên bản, và khoảng 758 nghìn địa chỉ IP vẫn chạy nhánh đã hết hỗ trợ — những hệ thống sẽ không bao giờ có bản phát hành vá chính thức.

Ba việc nên làm bền vững, không chỉ cho đợt này: (1) giữ một danh mục cập nhật mọi hệ thống, phiên bản, người phụ trách; (2) không để hệ thống chạy trên phiên bản hết hỗ trợ — nhánh 8.2 sẽ hết hỗ trợ ngày 31/12/2026, nghĩa là các hệ thống vừa vá lên 8.2.35 cũng cần kế hoạch nâng cấp trong hai tháng tới; (3) tách các hệ thống nội bộ khỏi Internet công khai khi không bắt buộc. Đây cũng là lý do Namtech triển khai AI nội bộ trên hạ tầng riêng, không mở ra Internet: bề mặt tấn công càng nhỏ, những đợt như php2shell càng ít gây hoảng loạn.

php2shell (CVE-2026-109618 và CVE-2026-109619) là hai lỗ hổng chạy mã từ xa không cần đăng nhập trong chính PHP, ảnh hưởng mọi phiên bản từ 5.4 tới trước bản vá ngày 21/10/2026; cách khắc phục trọn vẹn duy nhất là cập nhật lên PHP 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35 và khởi động lại mọi tiến trình PHP.

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

Lưu ý: Bài viết tổng hợp từ nguồn công khai tra cứu ngày 22/10/2026 và phản ánh tình hình tại thời điểm đó — sự việc đang diễn biến, thông tin có thể thay đổi. Các con số về quy mô ảnh hưởng là đo đạc của bên thứ ba, đã ghi rõ nguồn và phạm vi; số liệu về tấn công thực tế giữa các nguồn chưa thống nhất. Thông tin mang tính tham khảo, không thay thế đánh giá của đội ngũ bảo mật phụ trách hệ thống của bạn.