Ngày 21/10/2026, nhóm phát triển PHP phát hành bản cập nhật khẩn cho hai lỗ hổng nghiêm trọng nằm ngay trong lõi ngôn ngữ. Cộng đồng bảo mật gọi chung chúng là PHP2Shell. Năm ngày sau, CISA (Mỹ) đưa cả hai vào danh mục các lỗ hổng đã bị khai thác ngoài đời thực.[1][2] PHP đứng sau khoảng 70% website, trong đó có WordPress, Drupal và Joomla, nên phạm vi ảnh hưởng trải từ máy chủ doanh nghiệp đến website nhỏ.[3]
Bài viết này tổng hợp từ các nguồn uy tín (nhà phát triển PHP, nhóm nghiên cứu đã tìm ra lỗi, các hãng bảo mật và báo chuyên ngành) để trả lời bốn câu hỏi: lỗi này là gì và ảnh hưởng đến ai, nó hoạt động ra sao ở mức kỹ thuật, tình hình khai thác thực tế đến đâu, và các cơ quan, hãng bảo mật đã khuyến cáo gì. Bài viết mang tính thông tin và giải thích; mọi khuyến cáo nêu trong bài đều trích từ nguồn có ghi chú.
- Là gì: hai CVE (CVE-2026-109618 và CVE-2026-109619) trong lõi PHP, mỗi lỗi đạt CVSS v4.0 9.2, cho phép thực thi mã từ xa mà không cần đăng nhập.[4]
- Ảnh hưởng: mọi bản PHP từ 5.4 đến 8.5, trên PHP-FPM, Apache mod_php, php-cgi, FrankenPHP và LiteSpeed; mod_php rủi ro cao nhất.[5][4]
- Không chỉ RCE: kẻ tấn công còn có thể đọc bộ nhớ của PHP worker, nơi có thể chứa mật khẩu, token và API key.[3]
- Bản vá: PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35 (phát hành 21/10). PHP 8.1 trở xuống không có bản phát hành chính thức; có bản vá nguồn tối thiểu và gói backport từ một số distro hoặc nhà cung cấp LTS.[4][6]
- Thực tế: CISA đưa cả hai CVE vào KEV ngày 26/10. Tuy vậy nhiều báo cáo “bị xâm nhập” ban đầu đã được rút lại, và khai thác tổng quát trên mọi môi trường vẫn khó.[1][7]
- Khuyến cáo chính thức: PHP khẳng định chỉ cập nhật phiên bản mới đóng hoàn toàn lỗ hổng. Các nguồn cũng lưu ý cập nhật WordPress hay plugin không đóng được lỗi vì lỗi nằm ở PHP.[4][3]
PHP2Shell là gì?
PHP2Shell là tên gọi do Wiz Research đặt cho hai lỗ hổng CVE-2026-109618 và CVE-2026-109619.[5] Cả hai đều là lỗi an toàn bộ nhớ (memory safety) xuất phát từ cách PHP xử lý lỗi nghiêm trọng, đặc biệt là khi một request làm cạn bộ nhớ (out-of-memory, OOM). Khi request bị ngắt đột ngột, PHP có thể để lại trạng thái nội bộ dở dang. Request tiếp theo hoặc một worker khác dùng lại trạng thái đó và dẫn đến lộ hoặc hỏng bộ nhớ.[3]
| CVE | Mô tả theo PHP | Mã advisory | CVSS v4.0 | Hậu quả |
|---|---|---|---|---|
| CVE-2026-109618 | RCE do hỏng bộ nhớ khi OOM: PHP bị ngắt giữa chừng lúc dữ liệu request mới khởi tạo một phần, bước dọn dẹp lại coi dữ liệu đó là hợp lệ. | GHSA-w8hw-w9fx-j79w | 9.2 | Thực thi mã từ xa không xác thực |
| CVE-2026-109619 | RCE do trạng thái global cũ (stale): trạng thái của request vẫn còn sau khi vùng nhớ phía sau đã được giải phóng, request sau trên cùng worker có thể dùng lại. | GHSA-6wmf-4rv5-p3rp | 9.2 | Thực thi mã từ xa không xác thực, có thể kèm lộ bộ nhớ |
Nguồn bảng: thông báo của PHP và phân tích của Arctic Wolf.[4][8] Trên thang CVSS v3.1, NVD ghi nhận mức 9.8 (Critical).[9]
Điều gì khiến PHP2Shell khác thường?
- Lỗi nằm dưới tầng ứng dụng. Lỗi kích hoạt khi PHP còn đang phân tích request, trước khi code ứng dụng chạy. Một website viết sạch, đã cập nhật đầy đủ vẫn có thể bị khai thác nếu PHP bên dưới chưa được vá.[6]
- Không cần tài khoản. Wiz cho biết ngay cả một ứng dụng “Hello World” đơn giản trên bản PHP bị ảnh hưởng cũng có thể bị tấn công.[3]
- Rủi ro vượt xa RCE. Lỗi lộ bộ nhớ cho phép đọc dữ liệu còn sót trong tiến trình PHP, gồm mật khẩu, token xác thực, API key và chứng chỉ của request khác hoặc của chính máy chủ, ngay cả khi kẻ tấn công không chạy được mã. Wiz so sánh nó với Heartbleed.[3][10]
- Đã được chứng minh trên các nền tảng phổ biến. Wiz trình diễn RCE không xác thực trên image mới nhất của WordPress, Drupal và Joomla tại thời điểm thử nghiệm.[3]
Ai bị ảnh hưởng?
Theo phân tích của Qualys trên dữ liệu ẩn danh của hơn 10.000 khách hàng, gần như mọi bản cài đặt PHP phục vụ web đều nằm trong diện phơi nhiễm.[11] Cụ thể:
- Phiên bản: toàn bộ PHP từ 5.4 đến 8.5, tức hơn một thập kỷ phát hành.[5][3]
- Cách chạy PHP: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP và LiteSpeed đều nằm trong diện rủi ro. mod_php được đánh giá nguy hiểm nhất vì một request không xác thực có thể là đủ.[4][8]
- CMS và framework: WordPress, Drupal, Joomla và mọi ứng dụng PHP khác. Bản vá phải áp dụng ở PHP, không phải ở CMS: cập nhật WordPress hay plugin không đóng được lỗ hổng.[3][12]
- Nền tảng quản lý hộ: Automattic cho biết WordPress.com, WordPress VIP, WP Cloud, Pressable và Tumblr đã được bảo vệ.[13] Hostinger cho biết đã triển khai luật tường lửa chặn mẫu tấn công trên gói quản lý của họ.[12] Luật WAF chỉ là lớp giảm thiểu, không thay thế bản vá PHP. Với VPS hoặc máy chủ riêng, việc vá thuộc về người vận hành.
- Phần mềm và thiết bị đóng gói sẵn PHP: control panel, appliance và công cụ nội bộ cũng có thể chứa PHP. Palo Alto Networks xác nhận PAN-OS và Panorama bị ảnh hưởng (ngày 22/10, khi đó chưa có bản sửa). Fortinet và Cisco chưa xác nhận sản phẩm nào bị ảnh hưởng tại thời điểm Help Net Security đưa tin.[14]
- Việt Nam: theo dữ liệu nhận diện công nghệ của BuiltWith, hơn 143.000 website tại Việt Nam dùng PHP. Đây là con số cho thấy quy mô sử dụng PHP, không phải số website đang bị lỗ hổng.[15]
| Nhánh PHP | Trạng thái | Bản vá |
|---|---|---|
| 8.5 | Có bản vá | 8.5.12 |
| 8.4 | Có bản vá | 8.4.27 |
| 8.3 | Có bản vá | 8.3.36 |
| 8.2 | Có bản vá | 8.2.35 |
| 8.1, 8.0, 7.4 | Hết hỗ trợ | Không có bản phát hành chính thức. PHP cung cấp bản vá nguồn tối thiểu trong php-src; một số distro và nhà cung cấp LTS có gói backport.[4] |
| 7.3 trở xuống | Hết hỗ trợ từ lâu | Không có bản vá; watchTowr khuyến nghị chuyển sang nhánh còn hỗ trợ.[16] |
PHP 8.6.0 RC4 cũng đã chứa bản sửa.[4]
Diễn biến: từ phát hiện đến danh mục KEV
Khoảng cách từ lúc công bố đến lúc có dấu hiệu bị khai thác ngắn bất thường, và quy trình công bố phối hợp bị xáo trộn giữa chừng bởi một vụ rò rỉ.
08/2026
17/10
20/10
21/10
22/10
26/10
27/10
Mốc thời gian được tổng hợp từ nhiều nguồn; một số nguồn ghi ngày phát hiện hơi khác nhau vì Calif và Wiz báo cáo độc lập.
Hiểu nhanh: lỗ hổng PHP2Shell hoạt động thế nào?
Phần này dùng hình ảnh so sánh để dễ hình dung cho người không chuyên. Đây là mô hình đã đơn giản hóa; cơ chế kỹ thuật chi tiết nằm ở mục sau.
Hình dung một website như một nhà hàng. PHP là đội nhân viên bếp nhận từng “đơn hàng” (mỗi yêu cầu từ trình duyệt), nấu xong rồi chuyển cho khách. Mỗi nhân viên (gọi là worker) phục vụ hết đơn này đến đơn khác thay vì bị thay mới sau mỗi đơn. Vì vậy, sau mỗi đơn, nhân viên phải dọn bàn bếp và xóa các tờ ghi chú để đơn sau bắt đầu sạch sẽ.[6]
Lỗ hổng nằm ở chỗ “quên dọn bàn”. Mỗi đơn hàng chỉ được dùng một lượng nguyên liệu (bộ nhớ) nhất định. Nếu một đơn được cố ý làm quá lớn đến mức dùng hết nguyên liệu giữa chừng, nhân viên bỏ dở đơn và thu hồi nguyên liệu, nhưng bước xóa ghi chú không được thực hiện. Những tờ ghi chú cũ vẫn còn, và chúng chỉ vào những ngăn kệ đã được dọn trống.[6][3]
Các bước diễn ra như sau (theo phân tích của Varonis và Wiz):
Thực tế khai thác khó hơn trên lý thuyết. Theo phân tích honeypot của Wiz, hai yêu cầu phải rơi đúng vào cùng một nhân viên, và bố cục bộ nhớ phải khớp với cấu hình máy chủ cụ thể. Điều này khiến việc khai thác đại trà khó hơn trong phòng lab, dù không loại trừ khả năng bị khai thác trong điều kiện thuận lợi.[7]
Giải thích kỹ thuật: lỗ hổng hoạt động thế nào?
Phần này giải thích ở mức khái niệm, đủ để hiểu cơ chế và đánh giá rủi ro cho hệ thống của bạn. Bài viết không cung cấp mã khai thác.
Vài khái niệm nền tảng
- PHP worker: tiến trình xử lý request HTTP và được tái sử dụng cho nhiều request thay vì khởi động lại mỗi lần. Giữa hai request, PHP chạy bước dọn dẹp để đặt lại trạng thái toàn cục.[6]
memory_limit: giới hạn bộ nhớ tối đa cho một request. Vượt giới hạn, PHP dừng request bằng lỗi fatal.[6]- Upload progress của session: tính năng theo dõi tiến độ upload để hiển thị thanh tiến trình. Nó chạy ngay khi PHP đang phân tích request
multipart/form-datavà được bật mặc định.[6][16] - Use-after-free (UAF): bộ nhớ đã được giải phóng nhưng con trỏ vẫn còn được dùng. Nếu kẻ tấn công điền dữ liệu của mình vào vùng nhớ đó, chương trình sẽ coi dữ liệu ấy là đáng tin.[6]
- ASLR: cơ chế ngẫu nhiên hóa địa chỉ bộ nhớ khiến việc khai thác khó hơn. Lỗi lộ bộ nhớ của PHP2Shell giúp kẻ tấn công biết địa chỉ thật và vô hiệu hóa lớp bảo vệ này.[6]
Gốc rễ: trạng thái hỏng còn sót lại sau lỗi hết bộ nhớ
Chuỗi tấn công dựa trên một khoảng thời gian rất sớm của vòng đời request, khi PHP đang phân tích dữ liệu upload nhưng chưa khởi tạo xong. Một số con trỏ toàn cục (engine-global) đã được thiết lập từ sớm. Nếu đúng lúc đó request làm cạn bộ nhớ, PHP dừng request, giải phóng toàn bộ heap của request và bỏ qua bước đặt lại các con trỏ. Worker vẫn tiếp tục sống, mang theo những con trỏ trỏ vào vùng nhớ đã giải phóng.[6][3]
Đến request kế tiếp trên cùng worker, kẻ tấn công đưa dữ liệu do mình kiểm soát vào đúng vùng nhớ đã giải phóng. PHP vẫn tin các con trỏ cũ, nên đọc hoặc ghi vào dữ liệu đó như thể hợp lệ. Từ đây có hai khả năng: đọc bộ nhớ (lộ thông tin) và làm hỏng bộ nhớ để chạy mã.[6]
BƯỚC 1
multipart/form-data được tạo để PHP dùng hết memory_limit ngay khi xử lý upload-progress/session, trước khi code ứng dụng chạy.BƯỚC 2
BƯỚC 3
PS(id) và BG(unserialize) vẫn mang giá trị cũ (stale).BƯỚC 4
BƯỚC 5
PHPSESSID giúp vượt ASLR. Kết hợp lỗi unserializer hoặc backtrace để chạy mã tùy ý.Sơ đồ khái niệm đơn giản hóa từ phân tích của Varonis và Wiz. Bước 1 đến 3 diễn ra ở request đầu; bước 4 và 5 ở request sau trên cùng worker.[6][3]
Bốn lỗi, hai CVE
Theo Varonis, thông báo của PHP mô tả bốn lỗi, được xếp thành hai CVE. Ba lỗi đầu cùng dựa vào “giai đoạn chuẩn bị” ở trên; lỗi thứ tư là một cơ chế khác ở bên trong OPcache và chi tiết khai thác chưa được công bố đầy đủ.[6]
| Lỗi | Thành phần | Tác động | CVE (theo Wiz) |
|---|---|---|---|
| 1. UAF của ID session | PS(id), xử lý upload-progress |
Lộ bộ nhớ tiến trình từ xa: nội dung vùng nhớ bị rò qua cookie PHPSESSID |
CVE-2026-109618 |
| 2. UAF của unserializer | BG(unserialize), giải mã session trong upload-progress |
Hỏng bộ nhớ; kết hợp với lỗi 1 để RCE không xác thực (đã chứng minh trên WordPress, Drupal, Joomla) | CVE-2026-109618 |
| 3. UAF của backtrace lỗi fatal | EG(last_fatal_error_backtrace) |
Hỏng bộ nhớ khi worker gặp thêm lỗi hoặc cảnh báo trước khi trạng thái được khởi tạo lại | CVE-2026-109619 |
| 4. Nhầm kiểu trong OPcache | Bộ đếm map_ptr_last cục bộ và dùng chung | Hỏng trạng thái OPcache dùng chung giữa các worker, sau đó được dùng để RCE | CVE-2026-109619 |
Nguồn: Varonis (mô tả từng lỗi) và Wiz (ánh xạ sang CVE).[6][3]
Vì sao khó phát hiện và khó chặn?
- Lỗi kích hoạt trước khi code ứng dụng chạy, nên log ở tầng ứng dụng có thể gần như không ghi nhận gì.[6]
- Một số kịch bản có thể làm lộ bộ nhớ hoặc ảnh hưởng tính sẵn sàng mà không để lại dấu hiệu giống một cuộc tấn công thực thi mã thành công.[15]
- PHP khẳng định chỉ có cập nhật phiên bản mới là bản sửa hoàn chỉnh; không có thay đổi cấu hình nào đóng hẳn lỗ hổng.[4][16]
- Luật WAF (như bộ luật Cloudflare mở cho mọi khách hàng, kể cả gói miễn phí) giúp giảm rủi ro nhưng chỉ chặn được các mẫu tấn công đã biết.[14]
Vì sao nhiều nỗ lực khai thác chưa thành công?
Theo phân tích honeypot của Wiz, chuỗi khai thác công khai hiện phụ thuộc vào nhiều điều kiện. Hai request phải rơi đúng vào cùng một Apache worker. Bố cục bộ nhớ phải khớp bản build PHP và giá trị memory_limit mà bộ công cụ được tính cho (ví dụ 128 MB so với 64 MB trên honeypot). Độ trễ mạng và timeout cũng có thể làm đứt chuỗi.[7] Đó là lý do khai thác tổng quát hàng loạt khó hơn so với trong phòng lab. Tuy vậy, honeypot của Karimi cho thấy chuỗi này vẫn chạy được trong một cấu hình thuận lợi, và Wiz cho rằng AI đang làm giảm đúng loại rào cản này.[3]
Khai thác ngoài đời thực: đâu là thật, đâu là nhiễu?
Có hai điều cùng đúng: CISA đã xác nhận khai thác, và nhiều tin ban đầu đã quá vội. Phần này phân tách những gì đã được kiểm chứng khỏi phần nhiễu.
- CISA đưa vào KEV ngày 26/10. Các cơ quan liên bang Mỹ phải xử lý trước 29/10 theo BOD 26-04, và CISA khuyến nghị mọi tổ chức ưu tiên các lỗ hổng trong KEV. CISA không nêu tổ chức nào bị xâm nhập; việc liệt kê cũng không cho biết có bao nhiêu hệ thống production đã bị chiếm quyền.[1][18]
- Bằng chứng công khai mạnh nhất đến từ Adel Karimi (Perplexity) ngày 24/10: ba honeypot chạy PHP 8.4.26 với Apache mod_php ghi nhận 35 lần thực thi shell thành công từ hai địa chỉ IP, khớp với khai thác CVE-2026-109618. Karimi lưu ý honeypot có cấu hình một worker thuận lợi, nên kết quả chưa phản ánh môi trường production.[1][7]
- Quy mô quét: Delft University Threat Intelligence Lab theo dõi hơn 50.000 request khai thác từ hơn 600 địa chỉ IP ở 70 quốc gia; 171 địa chỉ đã vượt qua giai đoạn thăm dò và gửi mã khai thác hoặc dropper.[1]
- Một số báo cáo đã bị rút lại: Sophos rút đánh giá ban đầu sau khi nhận ra đó là hoạt động quét và các nỗ lực thất bại. Palo Alto Networks rút nhận định liên kết lỗ hổng với một vụ xâm nhập tại cơ quan chính phủ châu Âu.[1]
- Công cụ “mang mác” PHP2Shell nhưng không khai thác lỗi này. Wiz và Arctic Wolf thấy nhiều request dùng kỹ thuật session poisoning cũ, phụ thuộc một lỗ hổng LFI riêng trong ứng dụng, nên không chứng minh được khai thác CVE nào. Vì vậy, chỉ thấy chuỗi “PHP2Shell” trong log là chưa đủ để kết luận.[7][8]
- Botnet Potassium: Arctic Wolf ghi nhận hoạt động quét cùng botnet Potassium (họ Mirai), nhưng dữ liệu chưa xác lập rằng các request PHP2Shell đã tải hoặc chạy các mẫu mã độc này.[8]
- Xu hướng vá: Wiz ghi nhận số tổ chức bị ảnh hưởng đáng kể giảm khoảng 47,9% sau một tuần, tức khoảng một nửa vẫn chưa xử lý xong.[7]
Tóm lại: đến thời điểm viết bài, chưa có công bố nào cho biết có bao nhiêu hệ thống production đã bị chiếm quyền, nhưng lỗi đã có bản vá, đã có PoC công khai và đã nằm trong KEV.[7][1]
AI đứng sau việc tìm ra PHP2Shell
PHP2Shell còn được nhắc đến vì cách nó được tìm ra. Wiz cho biết lỗi đã nằm trong mã nguồn PHP hơn một thập kỷ, nhưng chứng minh khả năng khai thác đòi hỏi một chuỗi bước phức tạp, gần ngưỡng mà nhà nghiên cứu con người có thể làm được trên thực tế. Các mô hình AI tiên tiến giúp điều chỉnh khai thác theo từng phiên bản PHP, cấu hình và bố cục bộ nhớ, phân tích nguyên nhân thất bại rồi thử lại, nên việc này chỉ mất vài giờ.[3]
Ryan Austin (Calif) dùng GPT-5.6 Sol của OpenAI để hỗ trợ tìm lỗi, còn Wiz dùng Gemini 4 Argon, GPT-5.6 Sol và công cụ riêng Wiz Atlas.[5][3] Cần lưu ý rằng các đánh giá về mức độ AI rút ngắn thời gian là nhận định của chính nhóm nghiên cứu, chưa phải kết quả đối chứng độc lập. Hồ sơ công khai cũng cho thấy đây là công sức phối hợp giữa nhà nghiên cứu, mô hình AI và những người bảo trì PHP (trong đó có tình nguyện viên Ondřej Surý, người tự động hóa việc tạo bản vá cho các nhánh cũ), chứ không phải AI tự làm hết.[5]
Wiz nhận định rằng khi thời gian và chuyên môn cần cho việc này giảm đi, độ phức tạp của lỗi có thể không còn là rào cản đáng kể, từ đó thay đổi cách xác định thế nào là “có thể bị khai thác” trên thực tế.[3]
Khuyến cáo chính thức từ PHP và các cơ quan
Phần này tổng hợp những gì PHP, các cơ quan an ninh mạng và các hãng đã khuyến cáo, không phải khuyến nghị riêng của KAI NETWORKS. Theo PHP, chỉ có cập nhật phiên bản mới là bản sửa hoàn chỉnh; các biện pháp khác chỉ giúp giảm rủi ro.[4]
Kết luận
PHP2Shell là trường hợp lỗi nằm ở tầng nền của web: hai CVE trong lõi PHP, ảnh hưởng từ PHP 5.4 đến 8.5, kích hoạt trước khi code ứng dụng chạy và đã có bản vá từ ngày 21/10/2026.[4][3]
Từ lúc công bố, lỗi nhanh chóng đi từ bản vá khẩn đến danh mục KEV của CISA, trong khi bằng chứng công khai về khai thác thành công ngoài đời thực còn hạn chế và vẫn đang được các hãng bảo mật theo dõi. Theo đánh giá của chính nhóm nghiên cứu, vụ việc cũng cho thấy AI có thể rút ngắn khoảng cách từ phát hiện đến khai thác.[1][7][3]
Thông tin trong bài được tổng hợp từ các nguồn công khai tính đến 01/11/2026 và có thể thay đổi. Bài viết mang tính thông tin; vui lòng đối chiếu với advisory mới nhất của PHP và nhà cung cấp.
Danh sách nguồn thông tin
Các nguồn được đánh số theo thứ tự xuất hiện trong bài. Ưu tiên nguồn gốc (PHP, nhóm phát hiện) và các hãng bảo mật có phân tích trực tiếp; một số bài tổng hợp được dùng cho thông tin khu vực hoặc để đối chiếu.
- The Register: bài về việc CISA đưa PHP2Shell vào KEV (KEV, honeypot, báo cáo bị rút lại, số liệu của Delft)
- Mend.io: PHP2Shell is in CISA KEV: why runtime visibility matters (KEV và hướng dẫn restart worker)
- Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet (phân tích kỹ thuật của nhóm phát hiện)
- PHP.net: Critical remote code execution vulnerabilities, update now (21/10/2026) (thông báo chính thức, bản vá và biện pháp giảm thiểu)
- Wikipedia: PHP2Shell (tổng hợp mốc thời gian và ghi nhận công lao)
- Varonis Threat Labs: PHP2Shell: One Upload, Full Server (giải thích chuỗi tấn công và dấu hiệu phát hiện)
- Wiz Research: PHP2Shell: Exploitation Attempts and Remediation Trends (27/10/2026) (dữ liệu honeypot và xu hướng vá)
- Arctic Wolf Labs: PHP2Shell: Critical PHP Vulnerabilities Enable Unauthenticated Remote Code Execution (hoạt động quét, khai thác và botnet Potassium)
- Pentest-Tools: PHP2Shell: what it is, how to detect, how to patch (điểm CVSS v3.1 và công cụ quét)
- Recorded Future: PHP2Shell Exploitation: Two Critical PHP Flaws Explained (PoC công khai và tác động)
- Qualys: PHP2Shell: Find, Mitigate, and Patch Now (mức phơi nhiễm và chữ ký phát hiện)
- Hostinger: php2shell: What it is and why you don’t need to panic (góc nhìn từ nhà cung cấp hosting)
- Bài tổng hợp thông báo của Automattic về PHP2Shell và WordPress (22/10/2026) (các nền tảng WordPress do Automattic quản lý)
- Help Net Security: PHP2Shell: Critical PHP vulnerabilities patched, update now! (tổng hợp diễn biến và các hãng bị ảnh hưởng)
- VnReview: PHP2Shell: hơn 143.000 website dùng PHP tại Việt Nam (bối cảnh Việt Nam)
- watchTowr: PHP Remote Code Execution (“PHP2Shell” CVE-2026-109618 & CVE-2026-109619) (mốc thời gian và hướng dẫn xử lý)
- DigitalToday: Hàn Quốc nâng mức cảnh báo an ninh mạng sau lỗ hổng PHP (phản ứng của chính phủ Hàn Quốc)
- BleepingComputer: CISA confirms PHP2Shell vulnerabilities now exploited in attacks (xác nhận từ CISA)
Chú thích thuật ngữ
Các thuật ngữ xuất hiện trong bài, gom theo nhóm để bạn tra nhanh. Các định nghĩa mang tính giải thích chung.
