Website WordPress bị hack: Quy trình 72 giờ làm sạch và chặn tái nhiễm

Wecanadmin  /  Twitter 10.11.2026

Sáng ra mở website thấy trang chủ chuyển hướng sang trang cờ bạc, Google hiện dòng “Trang web này có thể đã bị tấn công”, hoặc khách gọi báo trình duyệt cảnh báo đỏ khi vào website. Nhiều doanh nghiệp đã nhờ người xoá mã độc, website chạy lại được vài ngày rồi lại bị y như cũ. Tháng 10/2026, giới bảo mật vừa ghi nhận một loại mã độc WordPress có thể tự dựng lại sau khi bị xoá, đúng lúc WordPress phát hành bản 7.1.4 vá 22 lỗ hổng, trong đó có lỗi thực thi mã từ xa bị dò quét ngay trong ngày phát hành.

Bài viết dưới đây của Wecan Group tổng hợp quy trình xử lý website WordPress bị hack theo mốc 72 giờ: việc gì làm trong 4 giờ đầu, làm sạch thế nào để mã độc không quay lại, khi nào phải thông báo cho cơ quan chức năng và khách hàng, và cách gỡ cảnh báo của Google. Nội dung viết cho chủ doanh nghiệp và người quản lý website, kèm checklist để bạn kiểm tra lại công việc của đội kỹ thuật hoặc đơn vị xử lý.

1. Vì sao website WordPress bị hack nhiều hơn trong năm 2026?

WordPress không kém an toàn hơn các nền tảng khác, nhưng hệ sinh thái plugin quá lớn khiến bề mặt tấn công rộng. Theo báo cáo State of WordPress Security in 2026 của Patchstack, năm 2025 có 11.334 lỗ hổng mới trong hệ sinh thái WordPress, tăng 42% so với năm 2024. 91% số lỗ hổng nằm ở plugin, và 46% chưa có bản vá vào thời điểm được công bố.

Tốc độ khai thác cũng nhanh hơn khả năng cập nhật của phần lớn doanh nghiệp. Cũng theo Patchstack, với các lỗ hổng bị nhắm nhiều, thời gian trung vị từ lúc công bố đến lần khai thác đầu tiên chỉ là 5 giờ. Với bản WordPress 7.1.4 phát hành ngày 28/10/2026, lỗi thực thi mã từ xa trong quá trình cập nhật core (CVSS 8.1, ảnh hưởng WordPress 4.7 – 7.1.3) bị dò quét hơn 18.500 lượt trong 21 giờ đầu, theo dữ liệu Wordfence được GBHackers dẫn lại.

Nói cách khác, một website không được cập nhật trong vài tuần đã nằm trong vùng rủi ro. Trường hợp lỗ hổng PHP2Shell mà Wecan Group phân tích gần đây là một ví dụ khác: doanh nghiệp cần theo dõi cả lỗ hổng ở tầng PHP và máy chủ, không chỉ ở WordPress.

2. Dấu hiệu website đang bị hack

Phát hiện sớm giúp giảm thiệt hại về SEO, uy tín và dữ liệu. Doanh nghiệp nên nghi ngờ website bị xâm nhập khi gặp một trong các dấu hiệu sau:

• Website tự chuyển hướng sang trang lạ, thường chỉ khi truy cập từ Google hoặc từ điện thoại, nên quản trị viên vào trực tiếp lại không thấy.
• Google hiển thị “Trang web này có thể đã bị tấn công” dưới kết quả tìm kiếm, hoặc trình duyệt hiện màn hình cảnh báo đỏ.
• Tìm site:tenmiencuaban.com trên Google thấy hàng loạt trang tiếng Nhật, tiếng Trung, quảng cáo thuốc, cờ bạc mà doanh nghiệp không hề tạo.
• Xuất hiện tài khoản quản trị lạ, hoặc tài khoản admin cũ bị đổi mật khẩu.
• Trong Google Search Console có thông báo ở mục Vấn đề bảo mật (Security issues).
• Hosting báo vượt tài nguyên CPU, gửi email spam hàng loạt, hoặc tài khoản bị tạm khoá.
• Có file PHP lạ trong thư mục wp-content/uploads, hoặc file hệ thống có ngày sửa gần đây mà không ai cập nhật.
• Plugin bảo mật tự tắt, hoặc danh sách plugin trong trang quản trị khác với danh sách thư mục trên hosting.

Dấu hiệu cuối cùng rất quan trọng. Theo phân tích của Sucuri được The Hacker News đưa tin ngày 01/10/2026, có loại mã độc tự ẩn khỏi màn hình Plugin và khỏi kiểm tra cập nhật, nên không thể chỉ dựa vào giao diện quản trị để kết luận website sạch.

3. Quy trình 72 giờ xử lý website WordPress bị hack

Quy trình dưới đây chia việc theo 4 mốc thời gian. Mốc 72 giờ không phải con số tuỳ chọn: đó cũng là thời hạn thông báo khi lộ dữ liệu cá nhân nhạy cảm theo quy định hiện hành (xem mục 5).

Giờ 0–4: Cô lập và giữ hiện trường

1. Bật chế độ bảo trì hoặc tạm chặn truy cập công khai để khách hàng không bị chuyển hướng hay nhiễm mã độc.
2. Sao lưu nguyên trạng toàn bộ file và database đang bị nhiễm, lưu riêng, đặt tên rõ “bản nhiễm – không dùng để khôi phục”. Bản này dùng để điều tra nguyên nhân.
3. Đổi mật khẩu hosting, cPanel/DirectAdmin, FTP/SFTP, SSH và email quản trị tên miền từ một máy tính sạch, không dùng máy đang nghi nhiễm.
4. Tải về log truy cập (access log) và log lỗi của máy chủ trước khi hosting xoá log theo chu kỳ.
5. Xác định ai đang giữ quyền quản trị tên miền, hosting và mã nguồn. Nếu doanh nghiệp không tự nắm các quyền này, mọi bước sau sẽ chậm. Bài kiểm tra quyền quản trị tên miền, hosting, mã nguồn có checklist chi tiết.

Giờ 4–24: Tìm đường vào và làm sạch tận gốc

1. Đọc log để tìm điểm xâm nhập: các request POST bất thường tới file PHP, request tới thư mục wp-content/upgrade (liên quan lỗi vừa vá ở bản 7.1.4), hay đăng nhập thành công từ IP lạ.
2. Liệt kê toàn bộ tài khoản quản trị (ví dụ lệnh wp user list --role=administrator) và xoá tài khoản không xác định được chủ.
3. Kiểm tra toàn vẹn core và plugin bằng checksum (wp core verify-checksums, wp plugin verify-checksums --all). File nào lệch so với bản gốc là file cần xử lý.
4. Thay core WordPress bằng bản sạch, cài lại toàn bộ plugin và theme từ nguồn chính thức. Xoá hẳn plugin, theme không dùng và mọi bản “nulled” (bản crack).
5. Rà các vị trí mã độc thường ẩn nấp ở mục 4: .user.ini, .htaccess, mu-plugins, drop-in, database, cron, bộ nhớ chia sẻ.
6. Quét lại bằng ít nhất hai công cụ khác nhau, một công cụ quét phía máy chủ và một công cụ quét từ bên ngoài.

Giờ 24–48: Vá lỗ hổng và khôi phục an toàn

1. Cập nhật WordPress lên 7.1.4 hoặc bản vá tương ứng của nhánh đang dùng. Theo WordPress.org, bản vá được đưa ngược xuống tới nhánh 4.7; từ 4.6 trở về trước không còn được vá.
2. Cập nhật PHP lên phiên bản còn được hỗ trợ và vá các plugin có lỗ hổng đã biết.
3. Tạo lại các khoá bảo mật (salt) trong wp-config.php, đổi mật khẩu database, thu hồi và cấp lại API key của cổng thanh toán, email, CRM.
4. Chặn thực thi PHP trong wp-content/uploads; đặt quyền file 644, thư mục 755, wp-config.php chặt hơn.
5. Nếu khôi phục từ bản sao lưu, chỉ dùng bản có trước thời điểm xâm nhập và vẫn phải vá lỗ hổng trước khi mở lại website.

Giờ 48–72: Gỡ cảnh báo Google, thông báo và giám sát

1. Vào Google Search Console, mục Vấn đề bảo mật, kiểm tra đã xử lý hết các URL được liệt kê rồi bấm Yêu cầu xem xét (Request Review). Theo hướng dẫn của Google, cần mô tả rõ vấn đề, các bước đã làm và kết quả; quá trình xem xét có thể mất từ vài ngày đến vài tuần. Không gửi lại yêu cầu khi yêu cầu cũ đang chờ.
2. Xoá các URL rác khỏi chỉ mục: để các URL này trả về 404 hoặc 410, cập nhật sitemap, dùng công cụ Xoá URL nếu cần ẩn nhanh.
3. Đánh giá website có lộ dữ liệu khách hàng hay không, nếu có thì thực hiện nghĩa vụ thông báo (mục 5).
4. Bật giám sát toàn vẹn file, cảnh báo đăng nhập quản trị và theo dõi log ít nhất 30 ngày sau sự cố.

4. Vì sao xoá mã độc rồi website vẫn bị hack lại?

Lý do phổ biến nhất là mới xoá phần nhìn thấy, còn cửa hậu (backdoor) và lỗ hổng ban đầu vẫn còn. Mẫu mã độc “SC” được Sucuri phân tích là ví dụ rõ: payload nằm ở ít nhất 8 vị trí, và chỉ cần còn một bản là các bản khác được dựng lại. Dựa trên mô tả đó, đây là 8 nơi cần kiểm tra:

1. .user.ini và .htaccess: dòng auto_prepend_file buộc máy chủ chạy một file mã độc trước mọi request PHP.
2. File lạ ở gốc wp-content: tên ngẫu nhiên kiểu c1b12371.php, có khi thêm dấu chấm ở đầu để ẩn.
3. Drop-in: db.php, advanced-cache.php, object-cache.php là file WordPress tự nạp; nếu website không dùng cache hay database tuỳ biến mà vẫn có các file này thì cần kiểm tra ngay.
4. functions.php của theme: kể cả theme không kích hoạt.
5. mu-plugins và plugin giả: plugin “must-use” tự chạy, không tắt được từ trang quản trị; mã độc còn tạo thư mục plugin trùng tên để dự phòng.
6. Database: bản sao mã độc được nén và mã hoá Base64 lưu trong database, đủ để tái tạo file đã bị xoá; ngoài ra cần kiểm tra script chèn vào bài viết và tài khoản quản trị ẩn.
7. Cron: cả WP-Cron lẫn cron của máy chủ, với tên hook ngẫu nhiên để định kỳ cài lại mã độc.
8. Bộ nhớ chia sẻ (shared memory) của máy chủ: vùng nhớ này tồn tại độc lập với file và database, nên cần nhờ kỹ thuật hoặc hosting kiểm tra, xoá vùng nhớ lạ hoặc khởi động lại dịch vụ máy chủ.

Nguyên nhân thứ hai là chưa tìm ra đường vào. Nếu lỗ hổng plugin, mật khẩu FTP bị lộ hay tài khoản hosting dùng chung vẫn còn, kẻ tấn công chỉ cần quay lại theo đúng đường cũ. Vì vậy bước đọc log ở giờ 4–24 không nên bỏ qua.

Nguyên nhân thứ ba là phụ thuộc hoàn toàn vào tường lửa. Theo GBHackers, quy tắc chặn lỗi RCE trong bản 7.1.4 của Wordfence được cấp cho gói trả phí từ 28/10/2026, nhưng người dùng gói miễn phí phải chờ tới 27/11/2026. Tường lửa chỉ là lớp bổ sung, không thay được việc cập nhật.

5. Website bị lộ dữ liệu khách hàng: nghĩa vụ thông báo trong 72 giờ

Nếu website có form liên hệ, đăng ký tài khoản, đơn hàng hay hồ sơ ứng tuyển, sự cố hack có thể kéo theo lộ dữ liệu cá nhân. Theo Nghị định 356/2025/NĐ-CP hướng dẫn Luật Bảo vệ dữ liệu cá nhân (hiệu lực từ 01/01/2026), Tạp chí Luật sư Việt Nam nêu: trong thời hạn không quá 72 giờ sau khi phát hiện lộ, mất dữ liệu cá nhân nhạy cảm, tổ chức trực tiếp thu thập dữ liệu có trách nhiệm thông báo cho cơ quan chuyên trách bảo vệ dữ liệu cá nhân và chủ thể dữ liệu.

Trong thực tế vận hành, doanh nghiệp nên chuẩn bị sẵn:

• Danh sách website đang thu thập những loại dữ liệu nào, lưu ở đâu, ai có quyền truy cập.
• Mẫu thông báo sự cố cho khách hàng và người phụ trách gửi thông báo.
• Đầu mối pháp chế hoặc luật sư để xác định dữ liệu bị lộ có thuộc nhóm nhạy cảm hay không.

Bài checklist bảo vệ dữ liệu cá nhân trên website doanh nghiệp giúp bạn rà các điểm thu thập dữ liệu trước khi có sự cố.

Lưu ý: Nội dung pháp lý trong bài mang tính tham khảo, cập nhật đến ngày 02/11/2026. Doanh nghiệp nên đối chiếu văn bản gốc và tham vấn luật sư cho trường hợp cụ thể.

6. Checklist nghiệm thu sau khi xử lý website bị hack

Dù tự làm hay thuê đơn vị ngoài, bạn có thể dùng checklist này để nghiệm thu:

• ☐ Đã có bản sao lưu nguyên trạng lúc bị nhiễm, lưu riêng.
• ☐ Đã xác định và ghi lại đường xâm nhập (hoặc ghi rõ chưa xác định được và lý do).
• ☐ Toàn bộ mật khẩu hosting, FTP/SSH, database, quản trị WordPress và API key đã được đổi; salt đã được tạo lại.
• ☐ Không còn tài khoản quản trị lạ.
• ☐ Core, plugin, theme khớp checksum hoặc đã cài lại từ nguồn chính thức; không còn plugin, theme thừa hay bản nulled.
• ☐ Đã kiểm tra .user.ini, .htaccess, mu-plugins, drop-in, database, cron và bộ nhớ chia sẻ.
• ☐ WordPress đang ở 7.1.4 hoặc bản vá tương ứng; PHP còn được hỗ trợ.
• ☐ Thư mục uploads không thực thi được PHP.
• ☐ Đã gửi yêu cầu xem xét trên Google Search Console và theo dõi kết quả.
• ☐ Đã đánh giá việc lộ dữ liệu cá nhân và thông báo nếu thuộc diện phải thông báo.
• ☐ Đã bật giám sát và có lịch kiểm tra lại sau 7 ngày và 30 ngày.

7. Phòng ngừa tái diễn: lịch vận hành tối thiểu cho website doanh nghiệp

Phần lớn sự cố có thể tránh được bằng một lịch vận hành đều đặn, không cần đầu tư lớn:

Phần lớn sự cố có thể tránh được bằng một lịch vận hành đều đặn

• Hằng tuần: cập nhật plugin, theme; xem báo cáo quét mã độc; kiểm tra Search Console.
• Hằng tháng: rà danh sách tài khoản quản trị, xoá plugin không dùng, thử khôi phục một bản sao lưu.
• Khi có tin lỗ hổng lớn: kiểm tra website có dùng thành phần bị ảnh hưởng không trong vòng 24 giờ.
• Hằng quý: rà quyền truy cập hosting, đổi mật khẩu dùng chung, kiểm tra phiên bản PHP.

Các bước cấu hình cơ bản như xác thực hai lớp, giới hạn đăng nhập, phân quyền file được trình bày trong bài tối ưu bảo mật WordPress. Nếu website đã bàn giao và không còn ai theo dõi, bạn có thể tham khảo bài bảo trì website sau bàn giao để xây quy trình phù hợp.

Một số câu hỏi thường gặp

Website bị hack có nên xoá đi làm lại từ đầu không? Không nhất thiết. Nếu xác định được đường xâm nhập và làm sạch đủ các vị trí ẩn nấp, website có thể dùng tiếp. Nên cân nhắc làm lại khi mã nguồn quá cũ, dùng nhiều plugin không còn được hỗ trợ, hoặc đã tái nhiễm nhiều lần.

Khôi phục bản sao lưu có phải là xong không? Chưa. Bản sao lưu chỉ đưa website về trạng thái trước khi bị hack, còn lỗ hổng vẫn nguyên đó. Cần vá lỗ hổng, đổi toàn bộ mật khẩu và kiểm tra bản sao lưu có sạch không trước khi mở lại.

Bao lâu thì Google gỡ cảnh báo “Trang web này có thể đã bị tấn công”? Theo Google, sau khi gửi yêu cầu xem xét trong Search Console, quá trình xem xét có thể mất từ vài ngày đến vài tuần. Website cần sạch hoàn toàn trước khi gửi, vì gửi khi chưa xử lý xong có thể làm thời gian chờ kéo dài hơn.

Đã cài plugin bảo mật thì có cần cập nhật WordPress lên 7.1.4 ngay không? Có. Tường lửa giúp giảm rủi ro nhưng không thay thế bản vá. Với lỗi RCE trong bản 7.1.4, quy tắc chặn của Wordfence cho gói miễn phí chỉ có từ 27/11/2026.

Website không có dữ liệu thanh toán thì có phải thông báo khi bị lộ dữ liệu không? Nghĩa vụ thông báo phụ thuộc vào loại dữ liệu bị lộ, không chỉ dữ liệu thanh toán. Doanh nghiệp nên liệt kê dữ liệu website thu thập và hỏi ý kiến luật sư để xác định.

Wecan Group – Dịch vụ bảo trì và xử lý sự cố website

Website bị hack không chỉ là sự cố kỹ thuật: mỗi ngày bị Google gắn cảnh báo là một ngày khách hàng tiềm năng quay đi. Wecan Group hỗ trợ doanh nghiệp đánh giá hiện trạng, làm sạch mã độc, vá lỗ hổng, gỡ cảnh báo trên Google và xây dựng quy trình bảo trì định kỳ để sự cố không lặp lại.

Nếu website của bạn đang có dấu hiệu bất thường, hoặc chưa được cập nhật lên WordPress 7.1.4, hãy liên hệ Wecan Group để được kiểm tra và tư vấn hướng xử lý phù hợp.