Khi WordPress xuất hiện URL spam, nội dung lạ hoặc JavaScript không rõ nguồn gốc, database WordPress bị chèn mã độc hoặc nội dung spam là một khả năng cần kiểm tra. Tuy nhiên, chuỗi code, HTML hoặc domain lạ trong database chưa đủ để kết luận compromise vì plugin, theme và nội dung hợp lệ cũng lưu dữ liệu phức tạp ở đây.
Map entity trước khi truy vấn
| Entity | Table thường liên quan | Câu hỏi điều tra |
|---|---|---|
| Post/Page | wp_posts, wp_postmeta |
Nội dung/revision nào xuất hiện ngoài quy trình? |
| Options | wp_options |
Option nào ảnh hưởng frontend và owner là component nào? |
| User/Role | wp_users, wp_usermeta |
Account/quyền nào không có owner hợp lệ? |
| Taxonomy | wp_terms, wp_term_taxonomy, wp_term_relationships |
Spam có tạo category/tag/entity trái phép không? |
Prefix thực tế có thể không phải wp_; phải xác định đúng prefix của site trước khi query.
Tạo backup trước khi sửa dữ liệu
Database remediation có thể ảnh hưởng trực tiếp tới nội dung và cấu hình website. Trước thay đổi, cần có backup/snapshot phù hợp, kiểm tra khả năng restore và ghi rõ rollback point. Không chạy replace hàng loạt trên production chỉ vì tìm thấy một chuỗi đáng ngờ.
Bắt đầu từ triệu chứng và URL bị ảnh hưởng
Ghi lại URL nào hiển thị spam, redirect hay script lạ, sau đó truy ngược dữ liệu tạo nên output đó. Cách tiếp cận theo triệu chứng giúp thu hẹp phạm vi tốt hơn việc quét và xóa mọi chuỗi trông giống code.
Read-only query mẫu để thu hẹp phạm vi
Nếu đã khóa đúng table prefix và có quyền truy vấn an toàn, ưu tiên SELECT trước mọi thay đổi. Ví dụ tìm post/page gần incident window:
SELECT ID, post_type, post_status, post_date, post_modified, post_title
FROM wp_posts
WHERE post_modified >= '2026-09-05 00:00:00'
ORDER BY post_modified DESC
LIMIT 100;Hoặc kiểm tra một option đã biết tên:
SELECT option_name, autoload, LENGTH(option_value) AS value_length
FROM wp_options
WHERE option_name = 'known_option_name';Các ví dụ trên chỉ đọc dữ liệu và phải được điều chỉnh cho prefix/site thực tế. Tài liệu WP-CLI cho truy vấn database: WP-CLI — db query.
Workflow kiểm tra post, page và revision
- Inventory URL/post bị ảnh hưởng.
- Đối chiếu author, post_date, post_modified và revision quanh incident window.
- So nội dung hiện tại với revision/baseline hợp lệ.
- Kiểm tra meta liên quan nếu output frontend không nằm trực tiếp trong post_content.
- Gắn finding với user/process/plugin có thể đã ghi dữ liệu.
Nếu website tự sinh bài lạ, đối chiếu thêm workflow WordPress tự đăng post spam.
Workflow kiểm tra options
Một số plugin, theme và custom code lưu cấu hình trong options. Dữ liệu lạ cần được đối chiếu với component sở hữu option và baseline trước đó. Không xóa option chỉ vì tên khó hiểu hoặc value được serialize.
| Check | PASS khi | Escalate khi |
|---|---|---|
| Owner | Xác định plugin/theme/custom code sở hữu option | Không có owner |
| Provenance | Có docs/change record giải thích value | Value xuất hiện ngoài incident window |
| Rendered effect | Khớp chức năng hợp lệ | Tạo redirect/script/spam trái phép |
Serialized data guard
Không dùng search/replace thô trên serialized data vì có thể làm sai length metadata và phá cấu hình. Nếu cần remediation, dùng cơ chế hiểu serialization của WordPress/plugin, backup trước và test trên bản sao hoặc staging phù hợp.
Kiểm tra user và quyền liên quan
Nếu database cho thấy tài khoản hoặc quyền mới ngoài quy trình, cần xác minh nguồn tạo và timeline. Trường hợp xuất hiện administrator không rõ nguồn gốc nên được điều tra theo workflow Admin WordPress lạ.
Đừng tìm malware chỉ bằng một signature
Chuỗi JavaScript, encoded data hoặc HTML có thể hợp lệ trong nhiều plugin. Ngược lại, spam có thể được lưu dưới dạng dữ liệu bình thường nhưng được tạo trái phép. Hãy kết hợp provenance, timestamp, revision, log và rendered behavior.
Rollback gate trước UPDATE/DELETE
- Chưa có backup/snapshot đã kiểm tra restore.
- Chưa khóa đúng table prefix và record scope.
- Chưa xác định serialized data hay owner của option/meta.
- Không có evidence cho thấy record cụ thể là trái phép.
- Chưa biết process nào tạo lại dữ liệu — xóa output có thể chỉ tạm thời.
Nếu phát hiện dữ liệu trái phép thì xử lý thế nào?
Ghi record ID/key, timestamp, owner và mối liên hệ với triệu chứng trước remediation khi điều kiện cho phép. Sau đó sửa hoặc phục hồi đúng record dựa trên baseline, đồng thời xử lý source ghi dữ liệu để tránh tái xuất hiện.
Xác minh sau cleanup database
Kiểm tra lại frontend, URL spam, redirect, tài khoản và IOC ban đầu. Database sạch tại một thời điểm không chứng minh entry point đã được đóng; dùng verification sau cleanup.
Nguồn kỹ thuật tham khảo
Kết luận
Kiểm tra database WordPress bị chèn mã độc hoặc spam nên đi từ triệu chứng tới entity, record, owner và timeline. Dùng read-only query để thu hẹp phạm vi, bảo vệ serialized data, khóa rollback trước UPDATE/DELETE và luôn xử lý cả nguồn tạo dữ liệu trái phép thay vì chỉ xóa output nhìn thấy.