PHP2Shell là gì? Cách cập nhật PHP để tránh lỗi PHP2Shell RCE

Tác giả: Nguyễn Văn Phúc

21 Phút đọc

Ngày đăng: 24/10/2026

Danh mục SEO

1. SEO cho người mới

2. Nghiên cứu & Lập kế hoạch SEO

3. Cấu trúc Website (Technical nền tảng)

4. Content SEO

5. Onpage SEO

6. Offpage SEO

7. Đo lường & Phân tích

8. Công cụ SEO

9. Case Study & Thực chiến

10. Tài nguyên bổ trợ

Thông tin chính

PHP2Shell RCE là hai lỗ hổng nằm trong chính PHP, cho phép kẻ tấn công chạy lệnh trên máy chủ mà không cần đăng nhập. Lỗ hổng đã bị khai thác thật từ trước khi có bản vá.
Lỗi xảy ra trước khi WordPress chạy, vì vậy cập nhật WordPress, plugin hay cài plugin bảo mật đều không vá được. Bạn cần cập nhật PHP trên máy chủ.
Website an toàn khi chạy PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 trở lên hoặc gói vá của hosting. Số phiên bản cũ chưa chắc là chưa vá, hãy hỏi hosting xác nhận.
Vá xong vẫn cần kiểm tra dấu hiệu bị xâm nhập, vì bản vá không xoá được tệp mã độc đã bị cài trước đó.
Nếu phải tạm đóng web để vá, hãy trả mã 503 ở CDN hoặc máy chủ để giữ thứ hạng trên Google.

Những ngày gần đây, cái tên PHP2Shell xuất hiện dày đặc trên báo chí và trong email cảnh báo của các nhà cung cấp hosting. Đây là lỗ hổng nằm trong PHP, nền tảng chạy phía sau phần lớn website, trong đó có toàn bộ website WordPress. Bài viết này giúp bạn hiểu lỗ hổng là gì và vì sao nó nguy hiểm. Bạn cũng sẽ biết cách tự kiểm tra website, khắc phục đúng cách mà vẫn giữ thứ hạng trên Google.

1. PHP2Shell là gì?

PHP2Shell là cách gọi chung được cộng đồng bảo mật dùng cho hai lỗ hổng thực thi mã từ xa (RCE) trong ngôn ngữ PHP gồm CVE-2026-109618 và CVE-2026-109619, được phát hiện nhờ sự hỗ trợ của AI và công bố vào tháng 10/2026. Chỉ bằng một yêu cầu gửi tới website, kẻ tấn công có thể chạy lệnh trên máy chủ mà không cần tài khoản đăng nhập.

RCE là viết tắt của Remote Code Execution, tức thực thi mã từ xa. Đây là lỗ hổng bảo mật nghiêm trọng cho phép kẻ tấn công làm mọi việc chủ website có thể làm được như đọc dữ liệu, sửa nội dung hoặc cài lệnh để quay lại bất cứ lúc nào mà không cần có quyền truy cập vật lý.

Ngôn ngữ lập trình PHP đang được ứng dụng cho hơn 70% website trên thế giới, vậy nên phạm vi ảnh hưởng của PHP2Shell rất rộng. Bảng dưới đây tóm tắt các thông tin chính theo thông báo bảo mật của PHP:

Hạng mục	Thông tin
Mã lỗ hổng	CVE-2026-109618, CVE-2026-109619
Mức độ	9,2/10 theo thang CVSS v4.0, mức nghiêm trọng (Critical)
Phiên bản bị ảnh hưởng	Mọi bản PHP đang phục vụ website chưa cập nhật bản vá
Bản đã vá	PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35, phát hành ngày 21/10/2026
PHP 7.4, 8.0, 8.1	Chỉ có bản vá mã nguồn, phụ thuộc nhà cung cấp hosting
PHP 7.3 trở xuống	Không có bản vá, phải nâng cấp
Tình trạng	Đã bị khai thác thật

Tính đến thời điểm hiện tại, đội ngũ phát triển PHP khẳng định không có cách cấu hình nào chặn được hoàn toàn hai lỗ hổng này và khuyến cáo mọi website cập nhật PHP ngay.

2. Nguyên nhân và cách thức hoạt động của PHP2Shell RCE

Nói đơn giản, PHP2Shell lợi dụng đúng lúc PHP đọc dữ liệu mà người dùng gửi lên website. Kẻ tấn công cố tình gửi dữ liệu khiến PHP bị lỗi bộ nhớ giữa chừng. Đáng lẽ PHP phải bỏ toàn bộ phần dữ liệu lỗi, nhưng nó vẫn tiếp tục dùng. Trong phần dữ liệu đó, kẻ tấn công đã giấu sẵn lệnh độc, nên lệnh được chạy thẳng trên máy chủ.

2.1. Lỗ hổng xảy ra ở đâu?

Mỗi khi ai đó mở một trang hay gửi biểu mẫu trên website, trình duyệt sẽ gửi lên máy chủ một yêu cầu kèm dữ liệu. Dữ liệu này có thể là nội dung ô tìm kiếm, thông tin đăng nhập hoặc tệp tải lên. Yêu cầu này đi qua CDN hoặc tường lửa, tới máy chủ web rồi đến PHP. PHP có nhiệm vụ đọc dữ liệu và sắp xếp vào bộ nhớ, sau đó mới giao cho WordPress xử lý.

PHP2Shell xảy ra ngay ở bước PHP đọc dữ liệu. Lúc này WordPress, theme và các plugin đều chưa chạy, nên chúng không nhìn thấy yêu cầu độc hại để chặn lại. Ví dụ, plugin bảo mật như Wordfence chỉ kiểm tra yêu cầu sau khi PHP đọc xong dữ liệu. Trong khi đó, kẻ tấn công đã chạy được lệnh từ trước.

Vì vậy, cập nhật WordPress, cập nhật plugin hay cài thêm plugin bảo mật đều không vá được lỗi này. Bạn cần cập nhật chính PHP trên máy chủ.

Sơ đồ vị trí lỗ hổng PHP2Shell trên website WordPress — PHP2Shell tấn công ở bước PHP đọc dữ liệu, trước khi WordPress chạy.

2.2. CVE-2026-109618: PHP hết bộ nhớ khi đang đọc dữ liệu

Lỗ hổng thứ nhất xảy ra khi PHP hết bộ nhớ trong lúc đang đọc dữ liệu của một yêu cầu. Lẽ ra PHP phải dừng và bỏ toàn bộ yêu cầu đó. Do lỗi, bước dọn dẹp chạy sau lại xử lý phần dữ liệu đọc dở như dữ liệu bình thường. Bộ nhớ bị hỏng và kẻ tấn công lợi dụng chỗ hỏng này để chạy lệnh.

Ví dụ, kẻ tấn công không cần tìm biểu mẫu nào trên website. Họ chỉ cần gửi tới một trang bất kỳ chạy bằng PHP, kể cả trang chủ, một yêu cầu chứa lượng dữ liệu cực lớn. PHP mới đọc được một nửa thì hết bộ nhớ, nhưng vẫn xử lý tiếp nửa dữ liệu đó. Lệnh độc giấu trong phần dữ liệu dở dang được chạy trên máy chủ.

2.3. CVE-2026-109619: lượt truy cập sau dùng nhầm dữ liệu của lượt trước

Trên máy chủ, mỗi tiến trình PHP phục vụ lần lượt nhiều lượt truy cập. Kẻ tấn công gửi lượt truy cập thứ nhất để cố tình gây lỗi. PHP dọn dẹp lượt này chưa sạch, phần dữ liệu cũ vẫn nằm lại trong bộ nhớ. Khi lượt truy cập tiếp theo tới, PHP dùng nhầm phần dữ liệu cũ đó. Kết quả là kẻ tấn công có thể chạy lệnh hoặc đọc trộm thông tin trong bộ nhớ, chẳng hạn mật khẩu cơ sở dữ liệu và khoá API.

Theo Datadog Security Labs, lỗ hổng này đi qua tính năng theo dõi tiến trình tải tệp (upload progress) của PHP. Tính năng này được bật sẵn trong cấu hình mặc định, nên rất nhiều máy chủ nằm trong diện bị ảnh hưởng mà chủ web không hề hay biết.

Minh hoạ cách hoạt động của hai lỗ hổng PHP2Shell RCE — Hai lỗ hổng PHP2Shell RCE đều không cần tài khoản đăng nhập.

2.4. Mức độ nghiêm trọng và ảnh hưởng thế nào?

Mọi máy chủ dùng PHP để phục vụ website đều nằm trong diện ảnh hưởng, nhưng mức rủi ro khác nhau tuỳ cách PHP được cài đặt. Bạn có thể đối chiếu theo bảng sau:

Cách PHP chạy trên máy chủ	Mức rủi ro
Apache mod_php	Cao nhất, PHP đã chứng minh khai thác được
PHP-FPM, LiteSpeed, php-cgi, FrankenPHP	Trong diện ảnh hưởng, cần cập nhật
PHP 7.4, 8.0, 8.1	Phụ thuộc bản vá riêng của nhà cung cấp
PHP 7.3 trở xuống	Không có bản vá

Khi chiếm được máy chủ, kẻ tấn công có thể lấy dữ liệu khách hàng hoặc dùng máy chủ gửi thư rác. Họ cũng có thể cài tệp mã độc để lần sau vào lại website mà không cần mật khẩu. Nhiều website còn bị chèn hàng loạt trang spam và chuyển hướng người dùng sang trang lạ, khiến website mất uy tín với Google và rớt thứ hạng.

Với người truy cập, Cục An ninh mạng và Hiệp hội An ninh mạng quốc gia cho biết lỗ hổng nằm ở phía máy chủ. Việc lướt web, mua sắm thông thường không bị ảnh hưởng trực tiếp.

3. Dấu hiệu nhận biết website bị tấn công qua PHP2Shell RCE

Các cuộc tấn công thật đã bắt đầu từ ngày 17/10, tức trước khi PHP phát hành bản vá. Điều đáng lo là một lần khai thác thành công có thể không làm website sập, trang vẫn hiển thị bình thường. Vì vậy, bạn không thể dựa vào việc website vẫn mở được để yên tâm.

3.1. Dấu hiệu chủ web tự thấy được

Bạn có thể tự rà các dấu hiệu sau trong trang quản trị WordPress, email từ hosting và Search Console:

Xuất hiện tài khoản quản trị mà bạn và đội ngũ không hề tạo.
Có plugin lạ hoặc tệp .php lạ trong thư mục tải lên, thư mục bộ nhớ đệm.
Website tự chuyển hướng sang trang khác, nhất là khi truy cập từ Google hoặc trên điện thoại.
Search Console xuất hiện truy vấn, URL lạ bằng tiếng Nhật, cờ bạc, thuốc, hoặc số trang được lập chỉ mục tăng vọt.
Hosting báo CPU, RAM tăng bất thường, tài khoản gửi thư rác hoặc bị khoá.

5 dấu hiệu website bị xâm nhập qua lỗ hổng PHP2Shell — 5 dấu hiệu cho thấy website có thể đã bị xâm nhập.

Một dấu hiệu riêng lẻ chưa đủ để kết luận website bị tấn công qua PHP2Shell. Khi thấy bất thường, bạn hãy ghi lại thời điểm, chụp màn hình và gửi cho bên quản trị hosting để họ đối chiếu với nhật ký máy chủ.

3.2. Dấu hiệu trong nhật ký máy chủ

Phần này dành cho người quản trị máy chủ hoặc đội kỹ thuật của hosting. Theo Datadog Security Labs, các dấu vết cần chú ý gồm:

Lỗi hết bộ nhớ lặp lại ngay lúc PHP bắt đầu xử lý yêu cầu, thường hiện dạng “Unknown on line 0”.
Tiến trình PHP hoặc Apache bị dừng đột ngột (lỗi AH00052).
Yêu cầu POST có tên trường dữ liệu dài bất thường.
Tiến trình web mở shell hoặc chạy lệnh hệ thống, đây là bằng chứng rõ nhất của việc bị khai thác.

Nếu nghi ngờ, bạn không nên tự xoá nhật ký hay tệp lạ, vì làm vậy sẽ mất dấu vết để điều tra.

4. Cách kiểm tra website có bị ảnh hưởng hoặc bị tấn công không

Để biết website có an toàn hay không, bạn cần kiểm tra hai việc. Thứ nhất là PHP của website đã được vá chưa. Thứ hai là website có bị xâm nhập trong khoảng thời gian trước khi vá hay không.

4.1. Kiểm tra phiên bản PHP trong WordPress

Cách nhanh nhất là xem ngay trong trang quản trị WordPress, chỉ mất khoảng 5 phút. Để kiểm tra phiên bản PHP, bạn hãy thực hiện theo các bước sau:

Bước 1: Trong trang quản trị WordPress, bạn bấm vào Công cụ (Tools) ở menu bên trái.

Bước 2: Trong danh sách hiện ra, bạn chọn Tình trạng website (Site Health).

Bước 3: Tại trang Tình trạng website, bạn chuyển sang tab Thông tin (Info).

Mở Công cụ, Tình trạng website và tab Thông tin trong WordPress — Mở Công cụ (1), Tình trạng website (2) rồi chọn tab Thông tin (3).

Bước 4: Bạn kéo xuống và bấm vào mục Máy chủ (Server). Lúc này WordPress hiển thị các thông tin về máy chủ. Dòng Phiên bản PHP cho biết bản PHP website đang chạy, còn dòng PHP SAPI cho biết cách PHP được cài đặt.

Dòng Phiên bản PHP trong mục Máy chủ của Tình trạng website — Mục Máy chủ (4) hiển thị phiên bản PHP của website WordPress.

Nếu không vào được trang quản trị, bạn có thể xem phiên bản PHP trong cPanel ở mục Select PHP Version hoặc MultiPHP Manager. Sau khi có số phiên bản, bạn đối chiếu theo bảng dưới đây:

Phiên bản PHP bạn thấy	Kết luận
8.5.12, 8.4.27, 8.3.36, 8.2.35 trở lên	Đã vá
Thấp hơn các mốc trên trong cùng nhánh	Có thể chưa vá, cần hỏi hosting
PHP 7.4, 8.0, 8.1	Hỏi hosting đã cài bản vá riêng chưa
PHP 7.3 trở xuống	Không có bản vá, cần nâng cấp

Ví dụ, website trong ảnh trên đang hiện PHP 8.2.34, thấp hơn mốc vá 8.2.35 của nhánh 8.2. Dù vậy, kết quả này chưa đủ để kết luận website còn lỗ hổng. Các nền tảng như cPanel, CloudLinux, Debian hay Ubuntu thường đưa bản vá vào gói của mình mà vẫn giữ nguyên số phiên bản cũ. Vì vậy, bạn hãy gửi mã CVE cho hosting để họ xác nhận gói PHP đã được vá hay chưa.

4.2. Hỏi hosting hoặc agency 3 câu

Hosting dùng chung (shared hosting) là loại hosting mà nhiều website cùng chạy trên một máy chủ do nhà cung cấp quản lý. Nếu website đặt trên loại hosting này, bạn thường không có quyền cập nhật PHP. Lúc này cách nhanh nhất là nhắn cho nhà cung cấp hosting hoặc agency đang quản lý website. Bạn có thể dùng mẫu tin nhắn sau:

Website [tên miền] của tôi đang dùng PHP phiên bản nào? Gói PHP này đã được vá lỗ hổng CVE-2026-109618 và CVE-2026-109619 chưa? Sau khi vá, các tiến trình PHP đã được khởi động lại chưa?

Bạn hãy lưu lại câu trả lời và thời điểm hosting xử lý. Nếu website do agency quản lý, hãy gửi cùng câu hỏi cho đầu mối kỹ thuật của họ, tránh trường hợp mỗi bên nghĩ bên kia đã lo.

4.3. Kiểm tra dấu hiệu bị xâm nhập

Sau khi xác nhận đã vá, bạn tiếp tục kiểm tra xem website có bị xâm nhập trước đó hay không. Việc đầu tiên là rà danh sách tài khoản quản trị trong WordPress theo các bước sau:

Bước 1: Trong trang quản trị WordPress, bạn bấm vào Tài khoản (Users) ở menu bên trái.

Bước 2: Ở dòng lọc phía trên danh sách, bạn bấm Quản lý (Administrator) để chỉ xem các tài khoản có quyền quản trị. Một số bản dịch WordPress ghi mục này là Quản trị viên.

Bước 3: Bạn xem tên và cột Vai trò của từng tài khoản. Nếu có tài khoản mà bạn và đội ngũ không hề tạo, hãy báo ngay cho bên kỹ thuật.

Lọc tài khoản quản trị trong WordPress để tìm tài khoản lạ — Mở Tài khoản (1), lọc Quản lý (2) và xem cột Vai trò (3).

Kế đó, bạn nhờ hosting quét mã độc và kiểm tra các tệp .php mới tạo từ ngày 17/10 trong thư mục wp-content. Bạn cũng có thể gõ `site:tenmiencuaban.com` trên Google để xem có trang lạ nào đã được lập chỉ mục không.

Cuối cùng, bạn mở Search Console, chọn mục Vấn đề bảo mật (Security issues) ở menu bên trái. Nếu website bình thường, trang này hiện dòng “Không phát hiện thấy vấn đề nào”. Khi Google phát hiện mã độc hoặc nội dung bị chèn, mục này sẽ liệt kê vấn đề kèm các URL bị ảnh hưởng. Sau đó, bạn xem tiếp báo cáo Trang và báo cáo Hiệu suất để tìm URL hoặc truy vấn bất thường.

Mục Vấn đề bảo mật trong Google Search Console — Website chưa bị Google phát hiện vấn đề bảo mật sẽ hiện như ảnh.

5. Cách khắc phục lỗ hổng PHP2Shell RCE

Theo PHP, cách khắc phục đầy đủ là cập nhật PHP lên bản đã vá rồi khởi động lại PHP. Ai là người làm việc này phụ thuộc vào loại hosting bạn đang dùng.

Cách khắc phục PHP2Shell theo từng tình huống — Chọn cách khắc phục PHP2Shell theo tình huống của website.

5.1. Website trên hosting dùng chung hoặc hosting WordPress quản lý

Với hosting dùng chung, nhà cung cấp quản lý PHP và sẽ vá cho bạn. Việc của bạn là gửi tin nhắn xác nhận như mẫu ở phần trên, sau đó vào lại Tình trạng website để kiểm tra.

Nhiều nhà cung cấp lớn đã chủ động xử lý. Ví dụ, Hostinger cho biết họ đã chặn các yêu cầu có dấu hiệu tấn công và đang cài bản vá trên mọi máy chủ dùng chung. Riêng khách dùng VPS phải tự cập nhật. Với hosting tại Việt Nam, bạn nên hỏi trực tiếp thay vì mặc định gói của mình đã được vá.

5.2. Dùng VPS hoặc máy chủ riêng

Nếu tự quản lý VPS, bạn cần cập nhật gói PHP từ kho phần mềm của hệ điều hành hoặc bảng điều khiển đang dùng. Sau đó, bạn phải khởi động lại toàn bộ dịch vụ PHP như PHP-FPM, Apache hoặc LiteSpeed. Nếu bỏ qua bước này, các tiến trình cũ vẫn tiếp tục chạy bản PHP chưa vá.

Với website chạy trong container, bạn cần dựng lại image bằng gói PHP mới rồi triển khai lại. Trước khi cập nhật, bạn hãy sao lưu website và cấu hình máy chủ để có thể quay lại khi gặp sự cố.

5.3. Chưa cập nhật ngay được: biện pháp tạm thời

Trong lúc chờ bản vá, người quản trị máy chủ có thể áp dụng một số biện pháp giảm rủi ro mà PHP đưa ra. Các biện pháp này cần người có quyền máy chủ thực hiện:

Biện pháp	Tác dụng
Tắt `session.upload_progress.enabled` rồi khởi động lại PHP	Chặn đường khai thác đã biết của CVE-2026-109619
Đặt `memory_limit=-1` ở cấp quản trị máy chủ	Giảm khả năng kích hoạt CVE-2026-109618
Giảm `post_max_size` (8M nếu không cần tải tệp, 32M nếu cần)	Hạn chế yêu cầu dữ liệu quá lớn
Bật luật tường lửa ứng dụng web (WAF)	Lọc bớt yêu cầu tấn công, Cloudflare đã có luật tạm
Hạn chế truy cập vào website thử nghiệm, trang nội bộ	Giảm số điểm có thể bị tấn công

Tuy nhiên, các biện pháp này chỉ giảm rủi ro, không giúp website của bạn an toàn hoàn toàn. Nếu không trực tiếp quản trị máy chủ, bạn không nên tự sửa cấu hình PHP mà hãy đề nghị bên cung cấp hosting thực hiện.

5.4. Nếu website đã bị tấn công

Bản vá PHP không xoá được tệp mã độc đã bị cài từ trước. Vì vậy, nếu thấy dấu hiệu bị xâm nhập, bạn hãy nhờ kỹ thuật vá PHP trước, sau đó mới dọn dẹp website. Việc cần làm ngay là đổi mật khẩu tài khoản quản trị WordPress theo các bước sau:

Bước 1: Trong trang quản trị WordPress, bạn bấm vào Tài khoản (Users) ở menu bên trái.

Bước 2: Bạn chọn Hồ sơ (Profile) để mở trang thông tin tài khoản của mình.

Bước 3: Bạn kéo xuống mục Quản lý tài khoản và bấm Đặt mật khẩu mới (Set New Password).

Bước 4: WordPress tự tạo sẵn một mật khẩu mạnh trong ô bên dưới. Bạn có thể giữ mật khẩu này hoặc nhập mật khẩu riêng, sau đó lưu lại ở nơi an toàn.

Đặt mật khẩu mới cho tài khoản quản trị WordPress — Tài khoản (1), Hồ sơ (2), Đặt mật khẩu mới (3), nhập mật khẩu (4).

Bước 5: Bạn kéo xuống cuối trang và bấm Cập nhật hồ sơ (Update Profile) để lưu mật khẩu mới.

Nút Cập nhật hồ sơ và mục Mật khẩu ứng dụng trong WordPress — Bấm Cập nhật hồ sơ (5) để lưu, rà lại danh sách Mật khẩu ứng dụng.

Ngay phía trên nút Cập nhật hồ sơ là mục Mật khẩu ứng dụng. Nếu thấy mật khẩu ứng dụng nào bạn không nhận ra, hãy bấm Gỡ bỏ ở dòng đó. Ở mục Phiên đăng nhập, bạn cũng nên bấm Đăng xuất khỏi những nơi khác để thoát mọi phiên đang mở trên thiết bị lạ.

Các quản trị viên khác của website cũng cần đổi mật khẩu theo cách tương tự.

Sau khi đổi mật khẩu WordPress, bạn tiếp tục đổi mật khẩu hosting và cơ sở dữ liệu. Kế đó, bạn nhờ kỹ thuật đổi các khoá bí mật trong tệp wp-config.php rồi xoá tài khoản và tệp lạ. Nếu có bản sao lưu sạch trước ngày 17/10, bạn có thể khôi phục từ bản đó. Cuối cùng, hãy kiểm tra các trang spam đã bị Google lập chỉ mục. Nếu cần đơn vị rà soát cả kỹ thuật lẫn SEO sau sự cố, bạn có thể tham khảo dịch vụ SEO của SEONGON.

6. Diễn biến PHP2Shell RCE: từ phát hiện đến bản vá

PHP2Shell có một điểm khác so với nhiều lỗ hổng trước đây. Lỗ hổng được tìm ra với sự hỗ trợ của AI và bị khai thác trước cả khi có bản vá chính thức. Các mốc chính như sau:

01/08/2026: Một nhà nghiên cứu của hãng bảo mật Calif phát hiện lỗ hổng khi dùng AI hỗ trợ rà mã nguồn PHP. Nhóm nghiên cứu của Wiz cũng độc lập tìm ra lỗ hổng. Cả hai đã báo cho đội ngũ PHP.
17/10/2026: Amazon ghi nhận lượt khai thác đầu tiên, bốn ngày trước khi lỗ hổng được công bố.
20/10/2026: Thông tin về lỗ hổng bị lộ ra trước hạn, PHP thông báo sẽ phát hành bản vá khẩn.
21/10/2026: Lúc 13:34 UTC (khoảng 20h34 giờ Việt Nam), PHP phát hành bản vá. Cùng ngày, hãng bảo mật watchTowr ghi nhận các cuộc tấn công thật.
22/10/2026: Cục An ninh mạng và Hiệp hội An ninh mạng quốc gia khuyến cáo các tổ chức tại Việt Nam rà soát và cập nhật.

Dòng thời gian PHP2Shell RCE từ phát hiện đến bản vá — Dòng thời gian PHP2Shell RCE, từ 01/08 đến 22/10/2026.

Trên thế giới, nhiều tổ chức lớn đã chủ động tắt website chờ vá. Ví dụ, cổng thông tin chính phủ Hà Lan và các dịch vụ công trực tuyến của Phần Lan đã tạm ngừng hoạt động để chờ vá. Khi có AI hỗ trợ, lỗ hổng được tìm ra và bị khai thác ngày càng nhanh. Vì vậy, chủ website nên có quy trình cập nhật máy chủ định kỳ thay vì đợi đến khi có tin cảnh báo.

7. Vá PHP2Shell RCE thế nào để không mất TOP Google?

Nếu phải tạm đóng website để vá, cách bạn đóng web sẽ quyết định Google hiểu đây là gián đoạn tạm thời hay website đã ngừng hoạt động. Làm sai, các trang đang đứng TOP có thể bị rút khỏi kết quả tìm kiếm.

7.1. Tạm đóng web: trả mã 503, không để lỗi 404 hoặc 500

Ngày 21/10, John Mueller của Google khuyên các website khi tạm ngừng để xử lý PHP hãy trả mã 503 thay vì để trang treo, báo lỗi 404 hoặc 500. Mã 503 báo cho Google biết website chỉ tạm thời không truy cập được, Google sẽ quay lại sau. Ông cũng gợi ý làm việc này ở ngoài PHP, chẳng hạn trỏ tên miền sang nơi khác hoặc dùng CDN.

Với người không rành kỹ thuật, cách dễ nhất là bật chế độ bảo trì ở CDN như Cloudflare hoặc nhờ hosting cấu hình. Bạn không nên dùng plugin bảo trì của WordPress, vì plugin này vẫn chạy trên PHP chưa vá. Bạn có thể đọc thêm về mã 503 để hiểu cách Google xử lý trạng thái này.

7.2. Đóng bao lâu thì an toàn?

Theo hướng dẫn của Google, bạn chỉ nên tạm đóng website trong thời gian rất ngắn, tối đa vài ngày. Bảng dưới đây tóm tắt những việc nên và không nên làm trong thời gian đóng web:

Nên	Không nên
Trả mã 503 từ CDN hoặc máy chủ	Để trang treo hoặc báo lỗi 404, 500
Đóng càng ngắn càng tốt, tối đa vài ngày	Đóng web nhiều ngày liền
Giữ tệp robots.txt hoạt động bình thường	Chặn Googlebot trong robots.txt hoặc để robots.txt trả 503
Dùng chế độ bảo trì ở CDN	Dùng plugin bảo trì chạy trên PHP chưa vá

7.3. Sau khi vá: kiểm tra trên Search Console

Sau khi website hoạt động lại, bạn hãy dùng công cụ Kiểm tra URL trong Search Console cho trang chủ và các trang quan trọng. Kế đó, bạn mở Cài đặt, chọn Số liệu thống kê về hoạt động thu thập dữ liệu. Báo cáo này cho biết Googlebot có gặp lỗi máy chủ trong những ngày vừa qua không.

Số liệu thống kê về hoạt động thu thập dữ liệu trong Search Console — Theo dõi trạng thái máy chủ lưu trữ trong Search Console sau khi vá.

Trong ảnh trên, biểu đồ cho biết số yêu cầu Googlebot gửi tới website mỗi ngày. Dòng Trạng thái của máy chủ lưu trữ cho biết máy chủ có từng gặp sự cố khi Google thu thập dữ liệu hay không. Nếu số yêu cầu giảm mạnh hoặc lỗi máy chủ kéo dài sau khi vá, bạn cần xử lý sớm để tránh thứ hạng bị tụt.

Nếu doanh nghiệp đang chạy Google Ads, SEONGON khuyến nghị bạn chủ động tạm dừng các chiến dịch dẫn về website trong thời gian đóng web. Cách này giúp bạn không phải trả tiền cho lượt nhấp vào trang lỗi.

8. Câu hỏi thường gặp về PHP2Shell RCE

Dưới đây là những câu hỏi chủ website thường gặp khi nhận được cảnh báo về PHP2Shell.

PHP2Shell RCE có ảnh hưởng tới WordPress không?

Có. WordPress chạy trên PHP, nên website WordPress dùng bản PHP chưa vá đều nằm trong diện ảnh hưởng. Đây không phải lỗi của WordPress, vì vậy cập nhật WordPress không giúp vá lỗi.

Website trên hosting dùng chung có phải tự cập nhật PHP không?

Không. Với hosting dùng chung, nhà cung cấp quản lý và vá PHP cho bạn. Bạn chỉ cần nhắn hỏi xác nhận và kiểm tra lại phiên bản trong Tình trạng website.

Cập nhật PHP có làm hỏng website không?

Thường là không nếu cập nhật trong cùng nhánh, ví dụ từ 8.3.30 lên 8.3.36. Khi phải nhảy nhánh như từ 7.4 lên 8.3, theme hoặc plugin cũ có thể gây lỗi 500. Vì vậy, bạn hãy sao lưu và thử trên bản sao của website trước.

Đã dùng Cloudflare hoặc Wordfence thì có an toàn chưa?

Chưa. Cloudflare có luật tường lửa tạm thời giúp lọc bớt yêu cầu tấn công, nhưng không thay thế được bản vá. Wordfence chạy sau khi PHP đọc dữ liệu nên không chặn được lỗ hổng này.

Website đang chạy PHP 7.4 thì sao?

PHP 7.4 không còn bản cập nhật chính thức, chỉ có bản vá mã nguồn mà hosting phải tự áp dụng. Bạn hãy hỏi hosting đã vá chưa và lên kế hoạch nâng cấp lên PHP 8.3 trở lên.

Website nhỏ, ít dữ liệu có cần vá gấp không?

Có. Kẻ tấn công dùng công cụ dò quét tự động, không chọn website lớn hay nhỏ. Website nhỏ thường bị lợi dụng để chèn trang spam hoặc gửi thư rác.

Người truy cập website có bị ảnh hưởng không?

Không trực tiếp. Lỗ hổng nằm ở máy chủ, nhưng nếu website bị chiếm, dữ liệu khách hàng lưu trên website có thể bị lộ.

PHP2Shell RCE là lỗ hổng ở tầng PHP, nên cách khắc phục đầy đủ là cập nhật PHP. Bạn hãy kiểm tra phiên bản PHP trong Tình trạng website và nhờ hosting xác nhận bản vá. Sau đó, bạn rà tài khoản quản trị, đổi mật khẩu nếu thấy dấu hiệu lạ và theo dõi Search Console trong những ngày tiếp theo.