PHP2Shell và Node2Shell: lỗ hổng không mới cũng không cũ, và bản vá mới chỉ là bước đầu

Hãy hình dung sáng ngày 22/10, đội kỹ thuật của một công ty thương mại điện tử đọc tin về PHP2Shell, cập nhật PHP trên máy chủ chính lên 8.3.36 và báo cáo: đã vá xong. Một tuần sau, họ mới nhận ra còn ba chỗ bị bỏ sót: container staging vẫn dựng từ image cũ, một trang giới thiệu chạy WordPress trên hosting chung vẫn dùng PHP 7.4, và dịch vụ Node.js nhận webhook (lời gọi tự động từ hệ thống khác) của cổng thanh toán chưa ai đụng đến — trong khi cùng ngày đó Node.js cũng phát hành bản vá khẩn.

Tình huống trên là giả định, nhưng rất dễ xảy ra. PHP2Shell không phải loại lỗ hổng mà cài một bản cập nhật là xong việc. Nó là lời nhắc rằng mã nguồn cũ đang được soi lại bằng công cụ mới, và việc vá phải đi đến từng nơi phần mềm thực sự chạy.

PHP2Shell là gì

PHP2Shell là tên gọi chung của hai lỗ hổng nghiêm trọng trong chính lõi của PHP: CVE-2026-109618 và CVE-2026-109619. CVE (Common Vulnerabilities and Exposures) là mã định danh công khai cho từng lỗ hổng. Cả hai đều cho phép RCE (remote code execution — thực thi mã từ xa): kẻ tấn công gửi yêu cầu đến máy chủ và có thể khiến máy chủ chạy mã của họ.

• Vị trí lỗi: theo PHP Foundation, cả hai nằm ở những phần gần như mọi yêu cầu web đều đi qua — quản lý bộ nhớ và xử lý lỗi. Đây là lỗi của PHP, không phải lỗi trong mã ứng dụng của bạn.
• Mức độ: PHP chấm cả hai 9,2/10 theo CVSS 4.0 (Common Vulnerability Scoring System — thang chấm mức nghiêm trọng của lỗ hổng); hãng bảo mật watchTowr chấm 10/10.
• Phạm vi: PHP Foundation cho biết mọi cài đặt PHP xử lý yêu cầu web đều có thể bị ảnh hưởng, gồm PHP-FPM, Apache với mod_php, php-cgi, FrankenPHP và LiteSpeed. Lỗi có mặt ở gần như mọi phiên bản từ PHP 5.4.
• Hệ quả phụ: theo các bài tổng hợp của Tenable và The Hacker News, lỗi còn có thể bị dùng để đọc bộ nhớ của tiến trình PHP — nơi có thể chứa mật khẩu cơ sở dữ liệu, khoá API và các thông tin bí mật khác.
• Bản sửa: PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. PHP 8.1 trở xuống đã hết hỗ trợ và không có bản sửa chính thức.

PHP chạy phía sau một tỷ lệ rất lớn các website — nhiều báo cáo ước tính khoảng 70% — gồm WordPress, WooCommerce, Magento, OpenCart, Laravel và hầu hết các gói hosting chung. Vì vậy một lỗi ở lõi PHP chạm đến gần như mọi doanh nghiệp có website.

Không mới, cũng không cũ

Gọi PHP2Shell là lỗ hổng mới thì chưa đúng: theo Wiz, các lỗi nền tảng đã có mặt trong mã PHP hàng chục năm. Gọi nó là lỗ hổng cũ cũng không đúng: chưa ai công bố cách khai thác được nó cho đến năm 2026.

Theo báo chí quốc tế, lỗi được phát hiện qua một đợt rà soát mã vào tháng 8/2026 của hãng bảo mật Calif, có dùng mô hình GPT-5.6 Sol của OpenAI, trong khuôn khổ chương trình OpenAI hỗ trợ giới nghiên cứu tìm lỗ hổng bằng AI. Wiz và OpenAI cũng tham gia. Calif cho biết họ không kỳ vọng tìm được lỗi nghiêm trọng, vì PHP đã được nhiều nhóm rà soát kỹ, kể cả bằng AI.

Wiz mô tả điểm mấu chốt: chứng minh lỗi khai thác được đòi hỏi một chuỗi bước rất phức tạp, gần chạm giới hạn của những gì người nghiên cứu làm được bằng tay, và mô hình AI tiên tiến đã hạ thấp rào cản đó đáng kể. Nói cách khác, đoạn mã không thay đổi; thứ thay đổi là công cụ dùng để đọc nó.

Lỗ hổng không "mới" theo nghĩa vừa được viết ra. Nó "mới" theo nghĩa vừa được nhìn thấy — và từ nay, những thứ đã nằm yên nhiều năm sẽ được nhìn thấy nhanh hơn.

Diễn biến trong vài ngày

• Tháng 8/2026: Calif rà soát mã PHP với sự hỗ trợ của AI và báo lỗi cho đội PHP.
• Kế hoạch ban đầu: công bố có phối hợp vào ngày 22/10.
• Khoảng ngày 20/10: thông tin bị lộ trước hạn; một video trình diễn được đăng lên rồi gỡ xuống. PHP Foundation quyết định đẩy bản vá sớm một ngày.
• 21/10, 14:00 UTC (21:00 giờ Việt Nam): PHP phát hành bản vá. Cùng ngày, Node.js phát hành đợt vá bảo mật riêng.
• Sau khi công bố: Amazon ghi nhận nỗ lực khai thác trên mạng cảm biến MadPot; Cloudflare báo có dấu hiệu khai thác sớm; một báo cáo trên The Hacker News cho biết có nỗ lực khai thác bốn ngày trước khi công bố. Mã thử nghiệm khai thác công khai xuất hiện trên GitHub.

Các nguồn chưa thống nhất về quy mô khai thác thực tế. Recorded Future cho rằng thông tin hiện có chưa xác định được bao nhiêu hệ thống thật sự bị xâm nhập. Tính đến 22/10, CISA (cơ quan an ninh mạng Mỹ) chưa đưa hai CVE này vào danh mục lỗ hổng đã bị khai thác. PHP Foundation cũng thừa nhận việc chậm trễ trong xử lý là "một thất bại mang tính cấu trúc" trong quy trình ra quyết định và nguồn lực của họ.

Vì sao bản vá mới chỉ là bước đầu

Tính đến ngày 22/10, chưa có bằng chứng công khai nào cho thấy bản sửa chính thức của PHP bị vượt qua; theo tổng hợp từ các trang hỏi đáp về PHP2Shell, cơ quan an ninh thông tin Đức BSI đã bác bỏ các tin đồn rằng bản vá không đầy đủ. Thứ chưa hoàn thiện là quá trình đưa bản vá đến mọi nơi PHP đang chạy. Có năm khoảng trống thường gặp.

1. Bản vá chính thức chưa phải bản vá trên máy của bạn

PHP phát hành mã nguồn đã sửa. Từ đó đến máy chủ của bạn còn nhiều tầng: bản phân phối Linux đóng gói lại (Ubuntu, Debian, Red Hat...), image Docker chính thức và image công ty tự dựng, bảng điều khiển hosting như cPanel, HestiaCP hay aaPanel. Mỗi tầng cập nhật theo nhịp riêng. Sau khi cài, tiến trình PHP-FPM hoặc Apache phải được khởi động lại, nếu không bộ nhớ vẫn đang chạy mã cũ.

2. Các phiên bản đã hết hỗ trợ không có bản sửa chính thức

PHP 8.1, 8.0, 7.x và 5.x không nhận bản vá từ PHP. Với các phiên bản này chỉ còn bản vá từ nhà cung cấp hỗ trợ mở rộng (ví dụ TuxCare) hoặc bản vá cộng đồng. Bản vá cộng đồng cần được thẩm định trước khi dùng trên hệ thống thật. Hướng đi bền vững là nâng cấp ứng dụng lên phiên bản PHP còn hỗ trợ.

3. Biện pháp giảm thiểu chỉ che được một phần

Một số hướng dẫn khuyên tắt tính năng theo dõi tiến độ tải tệp (session.upload_progress.enabled = Off trong php.ini). Theo The Hacker News, việc này chặn được các đường khai thác đã xác nhận qua session nhưng không chặn được các biến thể khác. PHP Foundation nói rõ: các biện pháp giảm thiểu chỉ giảm mức phơi nhiễm, không làm cài đặt trở nên an toàn. Tường lửa ứng dụng web (WAF) cũng chỉ nên coi là lớp chắn tạm thời trong lúc nâng cấp.

4. Bộ nhớ có thể đã bị đọc trước khi bạn vá

Vì lỗi có thể làm lộ nội dung bộ nhớ, một máy chủ đã nhận yêu cầu từ Internet trong khoảng thời gian chưa vá nên được coi là có khả năng đã lộ khoá bí mật. Vá xong vẫn cần đổi mật khẩu cơ sở dữ liệu, khoá API và khoá ký phiên đăng nhập.

5. Đây có thể không phải lỗi cuối cùng

Khi một kỹ thuật tìm lỗi bằng AI cho kết quả trên một dự án lớn, nhiều nhóm sẽ dùng kỹ thuật đó để rà soát những đoạn mã lân cận và những dự án tương tự. Nên chuẩn bị tinh thần cho các đợt vá tiếp theo, không chỉ với PHP.

Node2Shell: cùng ngày, ở Node.js

Cũng ngày 21/10, Node.js phát hành đợt vá sửa 10 lỗ hổng trên cả ba dòng phiên bản còn hỗ trợ. Lỗi đáng chú ý nhất là CVE-2026-111497, được đặt biệt danh Node2Shell: một lỗi ghi ra ngoài vùng nhớ cho phép trong bộ giải nén Brotli — định dạng nén dữ liệu phổ biến trên web.

• Mức độ: Node.js xếp mức Cao; Cơ quan An ninh mạng Singapore (CSA) ghi nhận 9,8/10 theo CVSS 3.1; Google, với vai trò cơ quan cấp mã CVE, chấm 9,2 theo CVSS 4.0.
• Phạm vi: theo Astra Security, ứng dụng Node.js nào nhận dữ liệu nén Brotli đều có thể bị ảnh hưởng; hàm fetch tích hợp sẵn mặc định yêu cầu máy chủ HTTPS trả về dữ liệu nén Brotli. Ngoài Node.js, Bun trước bản 1.4.4, Envoy và một số gói Python cũng bị ảnh hưởng.
• Vai trò của AI: thông báo bảo mật của Node.js ghi công Khai Tran và Sylvie Mayer thuộc nhóm OpenAI Codex Security. Theo OpenAI, bản sửa đã được đưa vào mã nguồn Brotli từ tháng 2/2026 nhưng lúc đó không được phân loại là lỗi bảo mật — một ví dụ khác của lỗ hổng "không mới cũng không cũ".
• Bản sửa: Node.js 26.12.1, 24.22.1 và 22.23.4. Các dòng đã hết hỗ trợ như 25.x, 23.x và 20.x không có bản sửa.
• Tình trạng khai thác: nhóm nghiên cứu Imperva cho biết đã chứng minh được khả năng chạy mã trên một bản dựng Node.js chính thức trong môi trường thử nghiệm; đến thời điểm các báo cáo được viết, chưa ghi nhận tấn công thực tế.

Đợt vá này còn gồm các lỗi kiểm tra tên máy chủ trong chứng chỉ TLS (CVE-2026-106069, CVE-2026-105483) và lỗi cắt ngắn tên miền khi phân giải DNS (CVE-2026-105482), cùng ở mức Cao. Với các hệ thống gọi API của bên thứ ba qua HTTPS, đây cũng là lý do để nâng cấp sớm.

AI đang thay đổi nhịp vá lỗi

Hai sự kiện cùng ngày cho thấy một xu hướng: AI giúp tìm lỗi sâu trong mã nền tảng nhanh hơn trước. Bên phòng thủ được lợi vì lỗi được phát hiện và sửa. Nhưng khoảng thời gian từ lúc công bố đến lúc có mã khai thác cũng ngắn lại — với PHP2Shell, mã thử nghiệm công khai xuất hiện chỉ trong vài ngày.

Với doanh nghiệp, điều đó có nghĩa là lịch "vá theo quý" không còn đủ. Cần biết chính xác mình đang chạy phiên bản nào ở đâu, và có quy trình đưa bản vá nghiêm trọng ra môi trường thật trong vài ngày thay vì vài tháng. Chúng tôi đã bàn về nguyên tắc này trong bài bảo mật cho hệ thống có AI: kiểm tra phụ thuộc tự động trong CI là rào chắn tối thiểu, không phải tuỳ chọn.

Danh sách việc cần làm

Trong 24–48 giờ

• Liệt kê mọi máy chủ, container và gói hosting có PHP hoặc Node.js; chạy php -v và node -v trên từng nơi, kể cả bên trong container
• Ưu tiên các dịch vụ nhận yêu cầu trực tiếp từ Internet: website, API công khai, webhook
• Cài bản đã sửa (PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35; Node.js 26.12.1 / 24.22.1 / 22.23.4) hoặc bản cập nhật bảo mật tương ứng của bản phân phối Linux
• Khởi động lại PHP-FPM, Apache, LiteSpeed và các dịch vụ Node.js, rồi kiểm tra lại phiên bản đang chạy
• Với hosting chung hoặc dịch vụ quản lý, hỏi nhà cung cấp bằng văn bản: đã vá chưa, phiên bản nào, khi nào

Trong tuần

• Dựng lại mọi image Docker từ thẻ phiên bản đã sửa và triển khai lại, kể cả staging và tác vụ chạy theo lịch
• Đổi mật khẩu cơ sở dữ liệu, khoá API và khoá ký phiên trên các máy chủ PHP từng phơi nhiễm khi chưa vá
• Xem lại nhật ký máy chủ trong khoảng từ 17/10: tìm tiến trình PHP-FPM bị dừng bất thường lặp lại, yêu cầu tải tệp lạ, hoặc tệp mới xuất hiện trong thư mục web
• Tắt expose_php để máy chủ không công khai phiên bản PHP trong phản hồi HTTP

Trong quý

• Lên kế hoạch nâng cấp mọi ứng dụng còn chạy PHP 8.1 trở xuống hoặc Node.js 25.x, 23.x, 20.x
• Thêm bước kiểm tra phiên bản và lỗ hổng phụ thuộc vào CI, chặn triển khai khi có lỗi mức nghiêm trọng
• Đăng ký nhận thông báo bảo mật của PHP, Node.js và bản phân phối Linux đang dùng; chỉ định một người chịu trách nhiệm đọc và phân loại

Một bản vá chỉ có giá trị khi nó đến được nơi phần mềm thực sự chạy. Bảng kiểm kê phiên bản quan trọng không kém chính bản vá.

KonexForge có thể hỗ trợ gì

Đội Development của KonexForge hỗ trợ doanh nghiệp kiểm kê phiên bản PHP và Node.js trên máy chủ, container và hosting; nâng cấp ứng dụng khỏi các phiên bản đã hết hỗ trợ; dựng lại image và quy trình triển khai; và thêm bước kiểm tra phụ thuộc vào CI để lần sau không phải chạy theo tin tức.

Kết luận

PHP2Shell và Node2Shell không phải lỗi mới được viết ra, cũng không phải lỗi cũ đã biết. Đó là những lỗi đã nằm trong mã nhiều năm và vừa được AI giúp nhìn thấy. Bản vá đã có từ ngày 21/10, nhưng việc vá chỉ xong khi mọi máy chủ, container và gói hosting đều chạy phiên bản đã sửa, các khoá bí mật có thể đã lộ được đổi, và quy trình build tự cảnh báo ở lần sau.

Nếu bạn cần một bảng kiểm kê nhanh hoặc kế hoạch nâng cấp cho hệ thống PHP và Node.js của mình, liên hệ với KonexForge.