php2shell và WordPress: Tình trạng vá PHP và những việc cần kiểm tra

CVE-2026-109618 và CVE-2026-109619 là gì?

Ngày 21 tháng 10 năm 2026, đội bảo mật của PHP phát hành bản vá cho hai lỗi nghiêm trọng, CVE-2026-109618 và CVE-2026-109619 ^[1]. Cộng đồng gọi chúng là php2shell, và cả hai đều được chấm CVSS v4.0 9.2. MalCare mô tả rủi ro khá thẳng: một lỗ hổng nghiêm trọng nằm ngay trong PHP cho phép kẻ tấn công chiếm website mà không cần đăng nhập ^[2].

Lỗi nằm trong bộ thông dịch PHP chạy website của bạn, không nằm trong mã của WordPress. Bản tin của Vercel cho biết các lỗ hổng ảnh hưởng đến PHP 5.4 trở lên trong cấu hình mặc định ^[1]. MalCare cũng nói tương tự: mọi phiên bản PHP từ 5.4 trở đi đều bị ảnh hưởng bởi ít nhất một trong hai lỗi ^[2].

Vercel cũng liệt kê WordPress, Drupal, Laravel và Magento là những framework và CMS bị ảnh hưởng khi chạy trên phiên bản PHP có lỗi ^[1]. WordPress nằm trong phạm vi vì nó chạy trên PHP bị lỗi, bất kể bạn dùng plugin hay theme nào.

Những phiên bản PHP nào đã có bản vá?

Bản tin của Vercel liệt kê một bản vá cho mỗi nhánh PHP được hỗ trợ ^[1].

Nhánh PHP	Bản vá
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

Vercel cho biết PHP 8.1 trở xuống không còn nhận bản cập nhật thường xuyên ^[1]. MalCare bổ sung rằng các nhánh cũ không có bản vá chính thức ^[2], nên website đang chạy nhánh cũ cần được chuyển sang nhánh còn được hỗ trợ, không chỉ vá ^[2].

Một số bản phân phối Linux và nhà cung cấp hỗ trợ dài hạn backport bản vá vào phiên bản PHP họ đang phân phối ^[1]. Cách này giúp các server đang chạy nhánh cũ, nhưng nó làm thay đổi cách bạn kiểm tra xem đã vá hay chưa, như các phần sau sẽ giải thích.

Website WordPress có bị ảnh hưởng nếu WordPress đã cập nhật không?

Có. MalCare cho biết các nhà nghiên cứu đã chỉ ra cách chiếm toàn quyền WordPress, Drupal và Joomla phiên bản mới nhất ^[2]. Lõi WordPress, plugin và theme đều được cập nhật vẫn không đóng được lỗi PHP, vì bản vá phải đến từ tầng PHP ^[2].

Plugin bảo mật và tường lửa hỗ trợ ít hơn một bản vá. Vercel cho biết các luật WAF của họ giảm mức phơi nhiễm trước những mẫu khai thác đã biết, nhưng không thay thế việc vá ^[1]. MalCare, một nhà cung cấp bảo mật WordPress, nói rằng tường lửa của chính họ không chặn được cuộc tấn công này ^[2]. Các website đứng sau Cloudflare được áp dụng luật khẩn cấp, nhưng MalCare vẫn khuyên chủ website cập nhật ^[2].

Các nhà cung cấp WordPress được quản lý đang ở trạng thái nào?

Pasquale Pillitteri cho biết các website trên WordPress.com, WordPress VIP, WP Cloud, Pressable và Tumblr đã được bảo vệ trước hai lỗi này ^[3]. Đó là hạ tầng của Automattic. Đây là một báo cáo duy nhất, nên website dùng nhà cung cấp khác vẫn cần kiểm tra trực tiếp.

Với website tự host và phần lớn hosting dùng chung, nhà cung cấp là bên quyết định. MalCare nói rõ: cách vá duy nhất là một bản cập nhật PHP mà nhà cung cấp hosting của bạn phải cài đặt ^[2]. Nếu nhà cung cấp chưa xác nhận đã cập nhật, hãy coi website vẫn đang bị phơi nhiễm.

Làm sao xác nhận website đã được vá?

Chỉ nhìn số phiên bản có thể gây hiểu nhầm. Pillitteri cảnh báo rằng số phiên bản giống nhau chưa đủ để yên tâm ^[3], vì một bản build được backport có thể mang bản vá dưới một chuỗi phiên bản trông vẫn cũ.

Hãy hỏi nhà cung cấp hosting bằng văn bản ba điều: phiên bản PHP đang chạy hoặc bản build nào chứa bản vá, ngày cập nhật, và các worker PHP đã được khởi động lại sau đó hay chưa. Pillitteri cũng đề xuất đúng những câu hỏi này ^[3]. Việc khởi động lại rất quan trọng, vì một gói đã cập nhật không thay đổi worker đang chạy mã cũ.

Nếu bạn quản lý nhiều website WordPress, hãy phân loại chúng theo nhà cung cấp và nhánh PHP trước khi gửi yêu cầu. Nhà cung cấp chỉ trả lời bằng số phiên bản thì mới đóng được một dòng trong danh sách. Nhà cung cấp trả lời kèm bản build, ngày cập nhật và xác nhận đã khởi động lại mới đóng được cả hạng mục.

Có thể làm gì trước khi vá?

Pillitteri mô tả một biện pháp tạm thời mà dự án PHP liệt kê: tắt session.upload_progress.enabled trong php.ini, cấu hình PHP-FPM pool hoặc cấu hình server, rồi khởi động lại toàn bộ worker ^[3]. Đặt giá trị bằng iniset() hoặc file .user.ini là chưa đủ. Cài đặt này chặn các đường khai thác đã được xác nhận cho CVE-2026-109619 nhưng không chặn các biến thể khác, và Pillitteri nhấn mạnh chỉ bản cập nhật mới là bản vá đầy đủ ^[3].

Hãy coi cài đặt này là biện pháp câu giờ, không phải lá chắn. Bản vá mới là cách khắc phục.

Vì sao bản vá đến sớm?

Chi tiết đã bị rò rỉ trước khi phát hành. The Hacker News đưa tin bản phát hành ban đầu được lên lịch vào ngày 22 tháng 10 năm 2026, nhưng mã CVE và một proof-of-concept khai thác đã rò rỉ trước đó, khiến PHP Foundation phải đẩy bản phát hành lên sớm một ngày ^[4]. MalCare ghi nhận chi tiết rò rỉ vào ngày 20 tháng 10, một ngày trước bản vá ^[2].

Đội PHP mô tả, qua lời trích của The Hacker News, rằng cả hai lỗi nằm ở những phần của PHP mà gần như mọi request đều chạm tới ^[4]. Khoảng cách ngắn hơn giữa lúc chi tiết được công bố và lúc có bản vá để lại ít thời gian hơn cho các website đang chờ cập nhật.

Có ai đang khai thác không?

Theo Amazon, có. Đội Threat Intelligence của Amazon cho biết họ phát hiện một lần thử khai thác các lỗi này từ ngày 17 tháng 10 năm 2026, nhắm vào honeypot MadPot của họ ^[4]. MalCare cho biết các cuộc tấn công đã bắt đầu ^[2]. Đội của Amazon cho rằng có nhiều tác nhân đe dọa khác nhau ^[4]. Một website đang chờ nhà cung cấp cập nhật sẽ vẫn ở trạng thái mở trong suốt thời gian chờ đó.

Các nguồn không hoàn toàn thống nhất về ngày đầu tiên ^[5]. Hãy kiểm tra log truy cập từ ngày 17 tháng 10 trở đi, không chỉ từ ngày phát hành.

Tuần này nên làm gì?

1. Hỏi nhà cung cấp hosting phiên bản PHP nào đang chạy website, bản build nào chứa bản vá, và các worker PHP đã được khởi động lại sau khi cập nhật hay chưa.
2. Nếu website chạy PHP 8.1 trở xuống, yêu cầu nhà cung cấp chuyển sang một nhánh còn được hỗ trợ. Đừng dừng ở một bản vá trên nhánh không còn được hỗ trợ.
3. Kiểm tra website trên phiên bản PHP mới trước khi đưa vào sử dụng.
4. Tìm trong log truy cập từ ngày 17 tháng 10 trở đi các request bất thường tới file PHP, và chuyển mọi kết quả khớp cho người phụ trách bảo mật của bạn.