Khôi phục chỉ cứu được site khi bản sao lưu có trước ngày bị xâm nhập và bạn bịt cửa vào trước khi mở lại. Ở ca thật Net Solutions xử lý, site bị chiếm 20 ngày. Một chủ web giữ 7 bản sao lưu hằng ngày sẽ không còn bản sạch nào. Thứ tự đúng gồm 8 bước: giữ hiện trường, tìm ngày xâm nhập, chọn và kiểm bản, khôi phục, vá lỗ hổng, đổi khoá, quét lại, xin Google xét lại.
Chỉ khôi phục khi có bản sạch và biết ngày bị xâm nhập
Khôi phục từ bản sao lưu là đường nhanh nhất về một site sạch. Nhưng nó chỉ đúng khi bạn trả lời được hai câu. Site bị xâm nhập từ ngày nào? Bạn còn bản sao lưu nào có trước ngày đó không?
Nếu cả hai đều có, hãy khôi phục theo 8 bước dưới đây. Nếu thiếu một trong hai, đừng đoán bản nào sạch. Hãy chuyển sang dọn mã độc tại chỗ, như hướng dẫn ở bài WordPress bị chèn mã độc: cách xử lý. Còn nếu bạn chưa chắc site có bị hack không, hãy đọc trước bài dấu hiệu nhận biết website bị hack.
Bài này chỉ nói về đường quay về bản sạch. Chúng tôi không lặp lại cách tìm tệp lạ hay so checksum, vì hai bài trên đã có.
| Bước | Làm gì | Làm sai thì sao |
|---|---|---|
| 1. Giữ hiện trường | Sao chép nguyên site đang nhiễm sang chỗ riêng trước khi đụng vào | Mất dấu vết, không biết kẻ tấn công vào bằng đâu |
| 2. Tìm ngày xâm nhập | Xếp bài theo ngày sửa, đối chiếu ngày tạo tài khoản quản trị | Chọn nhầm bản đã nhiễm |
| 3. Chọn và kiểm bản | Lấy bản mới nhất trước ngày nhiễm, quét khi chưa nối mạng | Mã độc quay lại cùng bản sao lưu |
| 4. Khôi phục tệp | Dựng thư mục mới, không ghi đè lên thư mục cũ | Tệp lạ của kẻ tấn công còn sót |
| 5. Khôi phục cơ sở dữ liệu | Tạo cơ sở dữ liệu mới, sửa wp-config.php, nhập lại dữ liệu sau ngày sao lưu có chọn lọc | Tài khoản quản trị giả quay lại, hoặc mất đơn hàng mới |
| 6. Vá và bịt cửa | Nâng lõi, plugin, theme; đóng cửa REST nếu còn mở | Site bị chiếm lại ngay sau khi mở |
| 7. Đổi khoá | Đổi khoá bí mật trong wp-config.php và mọi mật khẩu | Phiên đăng nhập của kẻ tấn công vẫn sống |
| 8. Quét lại, xin xét lại | Quét lần cuối, gửi yêu cầu xét lại trong Search Console | Cảnh báo còn treo trên kết quả tìm kiếm |
Thứ tự 8 bước khôi phục WordPress từ bản sao lưu. Tổng hợp từ quy trình xử lý site bị chiếm của Net Solutions, cập nhật 21/10/2026.
Tự làm hay gọi người? Một site bị hack thường dính ba tầng. Tầng WordPress gồm bài, tài khoản, plugin. Tầng cửa REST là các đường vào qua giao diện lập trình của WordPress. Tầng tệp gồm webshell và tệp .php nằm trong thư mục uploads/.
Hai tầng đầu một người quen WordPress tự làm được. Tầng tệp cần quyền hệ thống trên máy chủ. Nếu bạn chỉ có quyền quản trị WordPress, hãy dừng ở bước 3 và nhờ người có quyền máy chủ làm tiếp.
Bước 1–2: giữ nguyên hiện trường, rồi tìm ngày bị xâm nhập
Trước khi xoá bất cứ thứ gì, hãy sao chép toàn bộ site đang nhiễm: tệp và cơ sở dữ liệu. Bản này không dùng để chạy lại. Nó để bạn truy ngược xem kẻ tấn công vào bằng đâu, và để có đường lùi nếu khôi phục hỏng giữa chừng.
Trước khi sang giai đoạn dọn dẹp tiếp theo, nên chụp thêm một bản của môi trường. Dù nó đã nhiễm, tác động của một vụ hack có thể gây nhiều rắc rối, và nếu hỏng nặng thì ít nhất bạn còn bản xấu đó để tham chiếu.
— WordPress.org, FAQ: My site was hacked (dịch), 17/10/2026
Bước 2 quyết định mọi thứ phía sau: tìm ngày bị xâm nhập. Đừng tin ngày đăng của bài, vì kẻ tấn công ghi lùi được. Ở ca Net Solutions đo ngày 10/09/2026, site bị chiếm quyền ghi liên tục 20 ngày, từ 21/08 đến 09/09/2026, tính cả hai đầu. Trên site có 47 tài khoản quản trị giả. Sáu bài mồi đặt ngày đăng lùi về 01/01/2020, nên mọi danh sách xếp theo ngày đăng đều không thấy chúng.
post_modified), không xếp theo ngày đăng (post_date). Chỉ cột ngày sửa nói thật về lúc bài bị đụng tới. Cùng cách đó, hãy xem ngày tạo của từng tài khoản quản trị: tài khoản bạn không nhận ra, tạo gần nhau, là mốc rõ nhất của ngày xâm nhập.Một mốc nữa giúp bạn khoanh vùng: lỗ hổng lõi WordPress. Theo Patchstack, yêu cầu tấn công đầu tiên vào CVE-2026-87902 chạm tường lửa lúc 11:49 UTC ngày 22/09/2026, tức 18:49 giờ Việt Nam, cùng ngày bản vá 7.1.2 ra mắt. Nếu site chạy bản lõi cũ hơn 7.1.2 vào ngày đó, hãy xét cả khả năng bị xâm nhập từ mốc này.
Bước 3: chọn bản sao lưu có trước ngày nhiễm, rồi kiểm nó
Chọn bản mới nhất nằm trước ngày xâm nhập, không phải bản mới nhất có sẵn. Càng gần ngày nhiễm, bạn càng mất ít dữ liệu. Nhưng chỉ lấy bản đó khi bạn đã xác định ngày ở bước 2.
Bảng dưới minh hoạ vì sao số bản sao lưu được giữ quyết định chuyện còn cứu được hay không. Giả định sao lưu hằng ngày, bản mới nhất là 09/09, site bị chiếm từ 21/08.
| Số bản sao lưu được giữ | Bản cũ nhất | Số bản còn sạch |
|---|---|---|
| 7 bản | 03/09 | 0 bản — không cứu được |
| 14 bản | 27/08 | 0 bản — không cứu được |
| 21 bản | 20/08 | 1 bản |
| 30 bản | 11/08 | 10 bản |
| 45 bản | 27/07 | 25 bản |
Minh hoạ theo giả định sao lưu hằng ngày, bản mới nhất 09/09/2026, site bị chiếm 20 ngày từ 21/08/2026. Số bản sạch tính bằng mã, ngày bắt đầu nhiễm là mốc ngoại trừ.
Nhìn vào dòng đầu: giữ 7 bản thì bản cũ nhất là 03/09, đã nằm trong khoảng bị chiếm. Giữ 30 bản thì bản cũ nhất là 11/08, và 10 bản trước ngày 21/08 vẫn sạch. Mỗi nhà cung cấp hosting giữ số bản khác nhau. Hãy hỏi họ giữ bao lâu ngay từ bây giờ, kể cả khi site chưa có chuyện.
Bản sao lưu của hosting dùng được, miễn là nó có trước ngày nhiễm. Hãy tải bản đó về, giải nén ở máy riêng chưa nối vào site, rồi quét mã độc và tìm tệp .php trong uploads/ trước khi đưa lên máy chủ. Bản chưa quét thì chưa được gọi là sạch.
Bước 4–5: khôi phục tệp rồi cơ sở dữ liệu, trên môi trường cô lập
Cô lập site trước: chặn truy cập công khai bằng trang bảo trì hoặc chỉ cho IP của bạn vào. Rồi khôi phục tệp trước, cơ sở dữ liệu sau.
Với tệp, hãy xoá thư mục site cũ rồi dựng thư mục mới từ bản sao lưu. Đừng chép đè. Chép đè chỉ thay những tệp có trong bản sao lưu, còn tệp lạ kẻ tấn công cài thêm vẫn nằm đó.
Với cơ sở dữ liệu, hãy tạo cơ sở dữ liệu mới, nhập bản sao lưu vào, rồi sửa wp-config.php để trỏ tới cơ sở dữ liệu mới. Cách này giữ nguyên cơ sở dữ liệu nhiễm cho bước điều tra.
Còn dữ liệu phát sinh sau ngày sao lưu thì sao? Hãy xuất ra trước khi bỏ bản nhiễm: đơn hàng, bình luận, bản ghi form liên hệ. Nhập lại từng loại một, và chỉ nhập dòng dữ liệu của khách thật. Đừng nhập bảng người dùng nguyên khối, vì tài khoản quản trị giả nằm ngay trong đó.
Bước 6: vá và bịt cửa trước khi mở lại site
Bản sao lưu cũ mang theo lỗ hổng cũ. Chính lỗ hổng đó đã cho kẻ tấn công vào lần trước, nên khôi phục mà không vá là mở lại đúng cánh cửa đó. Hãy nâng lõi WordPress, plugin và theme lên bản mới nhất. Với lỗ hổng lõi gần đây, bản vá là 7.1.2, như bài về CVE-2026-87902 đã nêu.
Có một lỗi nữa mà khôi phục sạch không chữa được. Ở một ca khác, tài khoản quản trị giả mọc lại sau khi chúng tôi đã dọn và đổi mật khẩu. Lệnh kiểm checksum lõi WordPress vẫn báo sạch. Nguyên nhân là cửa REST batch còn mở, và kẻ tấn công dùng nó tạo lại tài khoản.
Trên 86 site chúng tôi đo ngày 10/09/2026, có 3 site mở cửa này, và đó đúng là 3 site đang bị chiếm. Vì vậy, nếu bạn khôi phục mà không đóng cửa REST, bản sạch sẽ nhiễm lại. Đóng cửa này cần cấu hình ở máy chủ hoặc lớp bảo vệ phía trước site. Nếu bạn không có quyền ở tầng đó, đây là chỗ cần nhờ người.
Bước 7: đổi khoá sau khi site đã sạch
Đổi khoá khi site còn nhiễm là đổi vô ích, vì kẻ tấn công vẫn thấy mật khẩu mới. Hãy đổi sau khi đã khôi phục và vá xong. Việc đầu tiên là làm mọi phiên đăng nhập đang sống hết hạn.
Bạn làm việc này bằng cách cập nhật các khoá bí mật trong wp-config.
— WordPress.org, FAQ: My site was hacked (dịch), 17/10/2026
Tạo bộ khoá mới bằng trang tạo khoá của WordPress.org, dán đè lên các dòng khoá trong wp-config.php. Sau đó đổi mật khẩu theo thứ tự: tài khoản hosting, FTP hoặc SSH, cơ sở dữ liệu, email quản trị, rồi mọi tài khoản quản trị WordPress. Cách đặt mật khẩu quản trị đủ mạnh có trong bài hướng dẫn đổi mật khẩu quản trị website.
Bước 8: quét lại và xin Google xét lại
Quét toàn site một lần cuối trước khi mở. Nếu còn một tệp lạ, quay lại bước 3 và kiểm bản sao lưu. Nếu sạch, hãy mở site cho khách vào.
Nếu Google đã gắn cảnh báo, hãy vào Search Console, mở mục Vấn đề bảo mật, rồi gửi yêu cầu xem xét sau khi chắc site sạch. Thời gian Google gỡ cảnh báo thường từ vài ngày đến vài tuần. Chi tiết ở bài website bị Google đánh dấu không an toàn.
Chỉ gửi yêu cầu khi bạn đã qua đủ 7 bước trước và chắc site sạch. Gửi sớm khi còn mã độc chỉ khiến bạn phải làm lại.
Net Solutions làm gì khi site bị hack
Chúng tôi nhận site do đơn vị khác làm. Việc đầu tiên là rà bản sao lưu và ngày xâm nhập, rồi mới quyết định khôi phục hay dọn tại chỗ. Chúng tôi kiểm cả ba tầng, kể cả tầng cửa REST và tầng tệp, nơi người quản trị WordPress thường không có quyền.
Với site cần giữ lâu dài, dịch vụ chăm sóc website có ba gói: C1 1.500.000đ, C2 2.500.000đ, C3 3.500.000đ mỗi tháng. Cả ba gồm sao lưu và quét mã độc. Tần suất sao lưu, thời gian lưu bản và điều kiện khôi phục được ghi trong thỏa thuận, và không ràng buộc theo năm. Giá theo trang dịch vụ, đọc ngày 17/10/2026.
Gói này không hợp mọi người. Nếu bạn đã có đội kỹ thuật riêng, bạn không cần chúng tôi. Và nếu site không còn bản sao lưu nào trước ngày nhiễm, chúng tôi cũng không khôi phục được. Khi đó là dọn tại chỗ, tốn công hơn và cần thời gian kiểm kỹ hơn.
Câu hỏi thường gặp
Khôi phục có xoá hết mã độc không? Chỉ khi bản sao lưu có trước ngày nhiễm và bạn vá lỗ hổng trước khi mở site. Bản sao lưu sau ngày nhiễm mang mã độc theo. Bản sạch mà lỗ hổng cũ còn nguyên thì site vẫn bị chiếm lại. Vì vậy hai việc đi liền nhau: chọn đúng bản, rồi vá.
Không biết bị hack từ ngày nào thì chọn bản nào? Tìm ngày bằng cột ngày sửa của bài và ngày tạo của tài khoản quản trị, như ở bước 2. Chưa tìm ra thì lấy bản cũ nhất còn giữ, rồi quét kỹ. Hãy quét bản đó trước khi dùng, và đừng lấy bản mới nhất chỉ vì nó ít mất dữ liệu nhất.
Khôi phục xong có mất bài, đơn hàng mới không? Có thể mất mọi thứ phát sinh sau ngày sao lưu. Vì vậy hãy xuất đơn hàng, bình luận và bản ghi form ra trước khi bỏ bản nhiễm. Nhập lại từng loại, kiểm từng dòng. Đừng nhập nguyên bảng người dùng, vì tài khoản quản trị giả nằm trong đó.
Không có bản sạch thì làm gì? Chuyển sang dọn mã độc tại chỗ: tìm tệp lạ, gỡ tài khoản giả, thay tệp lõi bằng bản gốc. Các bước đó có trong bài WordPress bị chèn mã độc: cách xử lý. Cách này lâu hơn, và vẫn phải làm bước vá, đổi khoá và xin Google xét lại.
Bản sao lưu của hosting dùng được không? Dùng được nếu bản đó có trước ngày nhiễm. Vấn đề thường nằm ở số bản được giữ, vì nhiều nơi giữ rất ít. Hãy hỏi nhà cung cấp họ giữ bao nhiêu bản, và tải bản cần dùng về quét trước khi đưa lên máy chủ.
Bao lâu Google gỡ cảnh báo? Thường từ vài ngày đến vài tuần sau khi bạn gửi yêu cầu xem xét. Thời gian phụ thuộc vào việc Google quét lại thấy site sạch. Vì vậy hãy gửi yêu cầu sau khi đã quét lại, không gửi sớm khi site chưa sạch.
Cần người rà bản sao lưu và bịt cửa cho site?
Net Solutions nhận site do đơn vị khác làm. Gọi hoặc nhắn Zalo 0906.207.001 để nhờ xác định ngày xâm nhập và chọn bản khôi phục.
Xem dịch vụ chăm sóc websiteNhắn ZaloHotline 0906.207.001
Cập nhật 23/10/2026 bởi Công ty TNHH Net Solutions.
