Tên plugin	TableOn
Loại lỗ hổng	Tiêm SQL
Số CVE	CVE-2026-42755
Tính cấp bách	Cao
Ngày xuất bản CVE	2026-06-01
URL nguồn	CVE-2026-42755

Khẩn cấp: Lỗ hổng SQL Injection trong TableOn (<= 1.0.5.1) — Những gì chủ sở hữu trang WordPress cần làm ngay bây giờ

Tác giả: Nhóm bảo mật WP‑Firewall

Được xuất bản tại: 2026-06-01

Bản tóm tắt: Một lỗ hổng SQL injection nghiêm trọng (CVE‑2026‑42755, CVSS 9.3) ảnh hưởng đến các phiên bản plugin WordPress TableOn <= 1.0.5.1. Các kẻ tấn công không xác thực có thể chạy SQL tùy ý trên cơ sở dữ liệu của trang web của bạn. Cập nhật plugin lên 1.0.6 ngay lập tức. Nếu bạn không thể cập nhật ngay, hãy áp dụng vá ảo / biện pháp giảm thiểu WAF và làm theo các bước phản ứng sự cố bên dưới.

---

Tại sao điều này quan trọng (trả lời ngắn)

Các phiên bản TableOn (posts-table / posts-table-filterable) lên đến và bao gồm 1.0.5.1 chứa một lỗ hổng SQL injection không xác thực cho phép kẻ tấn công tiêm SQL tùy ý vào các truy vấn cơ sở dữ liệu. Đây là một rủi ro nghiêm trọng vì nó có thể dẫn đến việc đánh cắp dữ liệu (hồ sơ người dùng, đơn hàng thương mại điện tử), leo thang quyền hạn (tạo người dùng quản trị), sửa đổi nội dung, hoặc làm tổn hại hoàn toàn trang web.

Lỗ hổng đã được gán CVE‑2026‑42755 và có điểm CVSS là 9.3 — có nghĩa là nó có độ nghiêm trọng cao và có khả năng được đưa vào các chiến dịch khai thác hàng loạt. Nếu bạn lưu trữ các trang WordPress sử dụng TableOn, hãy coi đây là một tình huống khẩn cấp.

---

Ai nên đọc điều này

• Chủ sở hữu và quản trị viên trang web đang chạy WordPress với plugin TableOn (posts-table-filterable)
• Các nhà cung cấp dịch vụ WordPress được quản lý và các cơ quan
• Các nhà phát triển và kỹ sư bảo mật hỗ trợ các trang WordPress
• Các đội ngũ bảo mật trang web chịu trách nhiệm phát hiện, giảm thiểu và phản ứng sự cố

---

Điều gì đã xảy ra (bối cảnh & thời gian)

• Các phiên bản dễ bị tổn thương: plugin TableOn <= 1.0.5.1
• Phiên bản đã được vá: 1.0.6 (cập nhật ngay lập tức)
• CVE: CVE‑2026‑42755 (độ nghiêm trọng cao — CVSS 9.3)
• Thời gian công bố: lỗ hổng được tài liệu công khai và chi tiết được công bố vào cuối tháng 5 năm 2026.

Nguyên nhân gốc rễ là một cấu trúc SQL không an toàn nơi đầu vào do người dùng cung cấp đến truy vấn cơ sở dữ liệu mà không có xác thực và tham số hóa đúng cách. Trong nhiều trường hợp SQL injection trên WordPress, đường dẫn mã dễ bị tổn thương là một điểm cuối AJAX, điểm cuối REST, hoặc thuộc tính shortcode được xử lý mà không sử dụng các truy vấn có tham số.

---

Tác động tiềm tàng (hệ quả của việc khai thác)

Một kẻ tấn công khai thác lỗ hổng SQL injection này có thể:

• Đọc các bảng cơ sở dữ liệu tùy ý và trích xuất dữ liệu nhạy cảm (email người dùng, mật khẩu đã băm, chi tiết đơn hàng).
• Chỉnh sửa hoặc xóa dữ liệu (bài viết, tùy chọn, đơn hàng, vai trò người dùng).
• Tạo hoặc nâng cấp tài khoản quản trị để có quyền truy cập liên tục.
• Tiêm nội dung hoặc cửa hậu (web shell được lưu trữ trong cơ sở dữ liệu + thực thi qua các lỗ hổng khác).
• Chuyển sang các hệ thống khác nếu thông tin nhạy cảm được lưu trữ trong cơ sở dữ liệu.
• Xâm phạm tính toàn vẹn và bảo mật của trang web và dữ liệu người dùng của bạn.

Bởi vì lỗ hổng này có thể bị khai thác mà không cần xác thực, ngay cả những trang web không có người dùng đã đăng ký ngoài quản trị viên cũng gặp rủi ro.

---

Hành động ngay lập tức (danh sách kiểm tra ưu tiên — làm những điều này ngay bây giờ)

1. Cập nhật TableOn lên phiên bản 1.0.6 hoặc mới hơn (được khuyến nghị)
   • Đi tới quản trị WordPress → Plugins → Plugins đã cài đặt và cập nhật TableOn.
   • Nếu cập nhật tự động được bật cho plugin, xác nhận rằng việc cập nhật đã hoàn tất thành công.
2. Nếu bạn không thể cập nhật ngay lập tức, áp dụng vá ảo/quy tắc WAF
   • Chặn các yêu cầu nhắm vào các điểm cuối của plugin chấp nhận các tham số có khả năng bị tiêm (xem hướng dẫn WAF bên dưới).
   • Áp dụng các bộ quy tắc nghiêm ngặt để loại bỏ các yêu cầu chứa ký tự meta SQL và tải trọng đáng ngờ gần đường dẫn plugin.
3. Quét trang web của bạn ngay lập tức để tìm dấu hiệu bị xâm phạm
   • Kiểm tra các người dùng quản trị không mong đợi, các tệp đã được sửa đổi, các tác vụ theo lịch đáng ngờ (cron), các plugin/giao diện mới và các mục cơ sở dữ liệu đáng ngờ.
   • Chạy quét phần mềm độc hại toàn bộ trên các tệp và cơ sở dữ liệu.
   • Xem xét nhật ký máy chủ web và ứng dụng để tìm các truy vấn bất thường hoặc các yêu cầu chạy lâu.
4. Sao lưu trước khi thực hiện thay đổi
   • Xuất một bản sao lưu đầy đủ của cơ sở dữ liệu và tệp, lưu trữ ngoại tuyến trước các bước khắc phục (để bạn có thể điều tra).
5. Thay đổi thông tin xác thực quan trọng
   • Đặt lại mật khẩu quản trị WordPress và bất kỳ thông tin xác thực cơ sở dữ liệu nào có thể được sử dụng lại.
   • Xoay API keys hoặc các bí mật khác nếu được lưu trữ trong cơ sở dữ liệu hoặc có thể truy cập bởi các plugin.
6. Thông báo cho các bên liên quan
   • Thông báo cho đội ngũ, nhà cung cấp hoặc khách hàng của bạn rằng bạn đang phản hồi một lỗ hổng nghiêm trọng.

---

Làm thế nào để biết nếu bạn đã bị tấn công (các chỉ số bị xâm phạm)

Tìm một hoặc nhiều điều sau đây:

• Tài khoản quản trị viên mới hoặc không xác định:
  • Trong quản trị WordPress → Người dùng, tìm kiếm các tài khoản bạn không tạo ra.
• Các truy vấn cơ sở dữ liệu đáng ngờ trong nhật ký:
  • Các truy vấn lặp lại chứa các từ khóa SQL (UNION, SELECT, INTO OUTFILE, SLEEP) qua các điểm cuối của plugin.
• Thay đổi nội dung bất ngờ:
  • Các bài viết, liên kết, quảng cáo mới được chèn vào, hoặc các tùy chọn đã được sửa đổi.
• Sự hiện diện của các tệp web shell hoặc các tệp PHP bị làm mờ:
  • Các tệp có tên đáng ngờ, các cuộc gọi eval/base64_decode.
• Lưu lượng outbound tăng hoặc các đỉnh bất thường trong việc sử dụng tài nguyên.
• Các tệp plugin/theme đã được sửa đổi với dấu thời gian không khớp với các thay đổi của bạn.
• Các tác vụ cron hoặc nhiệm vụ đã lên lịch mà bạn không tạo ra.

Các lệnh phát hiện nhanh (dành cho nhà cung cấp/ người dùng kỹ thuật):

• Tìm kiếm các tệp có khả năng là web shells:
  grep -R --line-number --color -E "eval\(|base64_decode\(|gzinflate\(" /path/to/wordpress
• Kiểm tra các người dùng / tùy chọn DB đáng ngờ:
  CHỌN user_login, user_email, user_registered TỪ wp_users SẮP XẾP THEO user_registered GIẢM DẦN GIỚI HẠN 20;
SELECT option_name, option_value FROM wp_options WHERE option_name LIKE '%cron%' OR option_name LIKE '%malware%' LIMIT 50;
• Kiểm tra nhật ký cho các URI đáng ngờ:
  grep -E "posts-table|posts-table-filterable|tableon" /var/log/nginx/access.log | grep -E "UNION|SELECT|SLEEP|benchmark|information_schema|into outfile" -i

---

Giảm thiểu tạm thời thông qua WAF / vá ảo

Nếu bạn không thể cập nhật ngay lập tức, vá ảo (chặn các mẫu tấn công tại rìa ứng dụng web) sẽ cho bạn thêm thời gian. Các bước được khuyến nghị:

• Chặn các yêu cầu HTTP đến các điểm cuối đã biết của plugin bao gồm các tham số truy vấn hoặc thân yêu cầu được sử dụng bởi plugin (ví dụ: URL AJAX). Các khái niệm quy tắc ví dụ:
  • Từ chối các yêu cầu chứa các từ khóa SQL trong các tham số chuỗi truy vấn: UNION SELECT, information_schema, INTO OUTFILE, SLEEP(, BENCHMARK(.
  • Từ chối các yêu cầu chứa các mẫu tautology hoặc các ký hiệu chú thích được sử dụng trong SQLi: ‘ OR ‘1’=’1, –, /*, */.
  • Chặn các yêu cầu nơi có đường dẫn plugin và yêu cầu bao gồm các ký tự meta SQL đáng ngờ: --, ;, ' HOẶC 1=1, HỢP NHẤT CHỌN.
• Giới hạn tỷ lệ hoặc chặn các yêu cầu đáng ngờ lặp lại từ cùng một địa chỉ IP.
• Đưa các IP quản trị hợp lệ vào danh sách trắng cho các điểm cuối quản trị nếu có thể.
• Giám sát và ghi lại các sự kiện bị chặn để điều tra.

Ví dụ về các mẫu kiểu ModSecurity (khái niệm, điều chỉnh cho tường lửa của bạn):

• Chặn nếu URI yêu cầu chứa đường dẫn plugin VÀ truy vấn/thân chứa (không phân biệt chữ hoa chữ thường):
  • (union.*select|information_schema|into.?outfile|sleep\(|benchmark\(|\bor\b.+=?\b1\b)
• Chặn các ký hiệu chú thích SQL đáng ngờ khi tìm thấy trong POST/GET gần tham số plugin: --, /*, */

Quan trọng: Không tạo ra các quy tắc quá rộng chặn lưu lượng hợp lệ. Thêm ghi lại và giám sát để bạn có thể điều chỉnh quy tắc nhanh chóng.

---

Cách WP‑Firewall bảo vệ bạn (nếu bạn là người dùng WP‑Firewall)

Là một nhà cung cấp dịch vụ/tường lửa WordPress được quản lý tập trung vào các biện pháp bảo vệ nhanh chóng và thực tiễn, chúng tôi cung cấp:

• Vá ảo ngay lập tức: khi một lỗ hổng plugin nghiêm trọng được công bố, chúng tôi tạo và phân phối các quy tắc WAF nhắm mục tiêu để chặn các nỗ lực khai thác cho tất cả các trang web được bảo vệ.
• Phát hiện và chặn payload độc hại theo thời gian thực ở lớp HTTP (trước khi thực thi PHP) để ngăn chặn các nỗ lực SQLi không xác thực trước khi chúng đến ứng dụng.
• Quét malware tự động cộng với việc xóa tự động tùy chọn (trên các gói trả phí) để làm sạch các shell đã được chèn.
• Giám sát liên tục và cảnh báo để các quản trị viên được thông báo ngay khi một nỗ lực khai thác bị chặn.
• Hướng dẫn và hỗ trợ thực hành cho việc phục hồi sau sự cố và tăng cường bảo mật.

Nếu bạn đang sử dụng WP‑Firewall và trang web của bạn được kết nối với dịch vụ của chúng tôi, chúng tôi sẽ đẩy các biện pháp giảm thiểu để chặn các chữ ký tấn công SQLi TableOn và giám sát bất kỳ nỗ lực khai thác nào chống lại các trang web của bạn.

---

Cách sửa mã (hướng dẫn cho các nhà phát triển plugin)

Nếu bạn là một nhà phát triển plugin hoặc bạn duy trì mã tùy chỉnh xây dựng các câu lệnh SQL, hãy tuân theo các quy tắc này để ngăn chặn SQL injection:

1. Sử dụng truy vấn tham số hóa / câu lệnh đã chuẩn bị
   • Trong WordPress, sử dụng $wpdb->chuẩn bị() đối với các truy vấn bao gồm đầu vào của người dùng:

     $sql = $wpdb->prepare( "SELECT * FROM {$wpdb->prefix}posts WHERE post_title = %s", $user_input );

   • Tránh nối chuỗi trực tiếp vào SQL.
2. Xác thực và làm sạch đầu vào
   • Đảm bảo các giá trị có kiểu và định dạng mong đợi (số nguyên, slug, enum).
   • Đối với số nguyên sử dụng (int) ép kiểu hoặc intval(); đối với slug sử dụng sanitize_title(); đối với email sử dụng sanitize_email().
3. Thoát khi cần thiết
   • Đối với các định danh SQL thô (tên bảng hoặc tên cột) tránh chấp nhận đầu vào của người dùng. Nếu bạn phải, hãy xác thực theo danh sách trắng các giá trị cho phép và không bao giờ sử dụng chèn trực tiếp.
4. Thực hiện kiểm tra khả năng và nonce đúng cách
   • Chỉ cho phép các hành động nhạy cảm cho khả năng đúng (người dùng hiện tại có thể()) và bảo vệ các điểm cuối thay đổi trạng thái bằng nonce.
5. Ưu tiên các API WordPress cấp cao
   • Sử dụng WP_Query và các API WordPress khác khi có thể thay vì SQL thô. Các API này xử lý việc thoát và tham số hóa.
6. Kiểm tra tất cả các điểm truy cập
   • Các điểm cuối REST, admin-ajax, thuộc tính shortcode và đầu vào biểu mẫu - tất cả đều phải được xem xét để sử dụng DB trực tiếp.

Ví dụ về dễ bị tổn thương so với an toàn (khái niệm):

Dễ bị tổn thương (không sử dụng):

$search = $_GET['search'];

An toàn hơn:

$search = isset($_GET['search']) ? wp_unslash( $_GET['search'] ) : '';

---

Sổ tay phản ứng sự cố (bước‑theo‑bước)

Nếu bạn nghi ngờ bị khai thác, hãy làm theo phản ứng có cấu trúc này:

1. Cách ly và kiểm soát
   • Tạm thời đưa trang web ngoại tuyến hoặc bật chế độ bảo trì để ngăn chặn việc khai thác thêm.
   • Áp dụng các khối WAF hoặc vô hiệu hóa plugin dễ bị tổn thương cho đến khi được vá.
2. Bảo quản bằng chứng
   • Tạo một bản sao lưu đầy đủ (tệp + DB) và lưu trữ nó ngoại tuyến để phân tích pháp y.
   • Lưu lại nhật ký máy chủ web và ứng dụng trong khoảng thời gian nghi ngờ.
3. Xác định phạm vi
   • Xác định các trang web nào đang sử dụng plugin dễ bị tổn thương và liệu có trang nào đã bị xâm phạm không.
   • Kiểm tra thời gian sửa đổi cuối cùng và tính toàn vẹn của tệp.
4. Loại bỏ lỗ hổng
   • Cập nhật plugin lên 1.0.6 hoặc phiên bản mới hơn (hoặc gỡ bỏ plugin nếu không cần thiết).
   • Dọn dẹp các tệp bị nhiễm (khôi phục từ bản sao lưu sạch đã biết hoặc loại bỏ mã độc hại).
   • Nếu các bản ghi cơ sở dữ liệu bị sửa đổi, hãy khôi phục hoặc sửa chữa các bảng bị ảnh hưởng.
5. Khắc phục thông tin đăng nhập
   • Đặt lại mật khẩu quản trị viên và xoay vòng thông tin đăng nhập dịch vụ.
   • Cấp lại khóa API nếu chúng có thể bị xâm phạm.
6. Làm cứng và giám sát
   • Bật xác thực đa yếu tố cho người dùng quản trị.
   • Bật giám sát tính toàn vẹn tệp và quét bảo mật liên tục.
   • Duy trì nhật ký và thiết lập cảnh báo cho các hoạt động đáng ngờ.
7. Thông báo cho các bên bị ảnh hưởng
   • Nếu dữ liệu nhạy cảm bị lộ, hãy tuân theo các luật thông báo vi phạm áp dụng và thông báo cho người dùng bị ảnh hưởng.
8. Đánh giá sau sự cố
   • Thực hiện phân tích nguyên nhân gốc rễ và cập nhật quy trình phát triển/bảo mật để ngăn chặn tái diễn.

---

Phát hiện: những gì cần tìm trong nhật ký và số liệu

• Nhật ký truy cập với tải trọng chứa các từ khóa SQL gần các URI plugin.
• Tần suất cao của các yêu cầu POST/GET đến các điểm cuối như admin-ajax.php hoặc các tuyến REST với slug plugin.
• Phản hồi 500 hoặc 200 với tải trọng lớn bất thường trả về nội dung cơ sở dữ liệu.
• Tăng đột biến trong các truy vấn chứa thông tin_schema hoặc các câu lệnh select trong các ngữ cảnh không mong đợi.
• Các sự kiện bị chặn lặp lại trong tường lửa của bạn với các mẫu SQLi.

Đảm bảo rằng nhật ký của bạn bao gồm toàn bộ nội dung yêu cầu trong một khoảng thời gian sau sự cố (hãy chú ý đến quyền riêng tư/tuân thủ).

---

Giám sát và kiểm tra sau khi vá lỗi được khuyến nghị

Sau khi bạn cập nhật lên 1.0.6:

• Xác minh rằng việc cập nhật plugin đã thành công trên mọi cài đặt.
• Chạy lại quét phần mềm độc hại trên các tệp và cơ sở dữ liệu.
• Xem xét tài khoản người dùng và quyền — xóa bất kỳ tài khoản không được ủy quyền nào.
• Cấu hình lại các quy tắc WAF để loại bỏ các khối tạm thời có thể quá nghiêm ngặt khi plugin được vá, nhưng giữ cho việc phát hiện và ghi nhật ký được bật.
• Lên lịch xem xét thứ hai 7–14 ngày sau khi vá để đảm bảo không có chỉ báo bị trì hoãn xuất hiện.

---

Phòng ngừa: tăng cường lâu dài cho các trang WordPress

• Giữ cho lõi WordPress, các chủ đề và plugin được cập nhật. Sử dụng các khoảng thời gian bảo trì đã lên lịch hoặc cập nhật tự động cho các bản vá bảo mật quan trọng.
• Giới hạn việc sử dụng plugin: loại bỏ các plugin và chủ đề không sử dụng — mỗi plugin đều làm tăng bề mặt tấn công.
• Giữ bản sao lưu ngoại tuyến và kiểm tra quy trình khôi phục thường xuyên.
• Thực hiện nguyên tắc quyền tối thiểu cho các tài khoản WordPress: giới hạn người dùng quản trị và cấp vai trò chi tiết cho biên tập viên/ tác giả.
• Sử dụng mật khẩu mạnh và thực thi xác thực đa yếu tố cho các tài khoản quản trị.
• Chạy quét lỗ hổng theo lịch trình và kiểm tra tính toàn vẹn của tệp.
• Sử dụng giải pháp WAF được quản lý cung cấp vá ảo cho các lỗ hổng zero-day.
• Xem xét mã plugin trước khi cài đặt: kiểm tra lịch sử bảo trì, nhịp độ cập nhật và phản hồi từ cộng đồng.

---

Đối với các nhà cung cấp và cơ quan: mở rộng các thực tiễn giảm thiểu tốt nhất

• Kiểm kê: duy trì một danh sách chính xác các plugin đã cài đặt cho mỗi trang.
• Vá tự động cho các lỗ hổng đã biết: khi một lỗ hổng nghiêm trọng được đánh dấu, lên lịch cập nhật tự động hoặc đẩy các bản vá ảo đến các trang bị ảnh hưởng.
• Giám sát tập trung: tổng hợp các nhật ký WAF và web trên tất cả các trang của khách hàng để phát hiện nhanh chóng các nỗ lực khai thác hàng loạt.
• Mẫu giao tiếp với khách hàng: chuẩn bị các mẫu để thông báo cho khách hàng về tính cấp bách, các hành động được khuyến nghị và các bước dịch vụ mà bạn sẽ thực hiện.

---

Danh sách kiểm tra cho nhà phát triển (xem xét bảo mật trước khi phát hành)

• Sử dụng các câu lệnh đã chuẩn bị cho mọi tương tác với DB.
• Xác thực & làm sạch tất cả các đầu vào. Từ chối các đầu vào không đáp ứng loại/định dạng mong đợi.
• Chạy các công cụ phân tích tĩnh tập trung vào các mẫu bảo mật PHP và WordPress.
• Thực hiện các bài kiểm tra đơn vị và kiểm tra tích hợp cho các trường hợp biên, bao gồm các kịch bản đầu vào độc hại.
• Thêm kiểm tra phụ thuộc bên thứ ba cho các lỗ hổng đã biết.
• Thêm tiêu đề bảo mật và giảm thiểu việc lộ dữ liệu từ các điểm cuối REST.

---

Những câu hỏi thường gặp

Hỏi: Điều gì xảy ra nếu trang web của tôi được khôi phục từ một bản sao lưu trước khi lỗ hổng bị khai thác?
Đáp: Khôi phục là một lựa chọn phục hồi hợp lệ, nhưng hãy đảm bảo rằng bản sao lưu trước bất kỳ sự xâm phạm nào và bạn vá plugin ngay sau khi khôi phục. Cũng hãy thay đổi thông tin đăng nhập sau khi khôi phục.

Hỏi: Việc vô hiệu hóa plugin có giảm thiểu rủi ro không?
Đáp: Có — việc vô hiệu hóa hoặc gỡ bỏ plugin có lỗ hổng ngăn chặn đường dẫn mã lỗ hổng có thể tiếp cận. Nhưng nếu trang web đã bị xâm phạm, sẽ cần thêm việc dọn dẹp (phần mềm độc hại, tài khoản quản trị, thay đổi DB).

Hỏi: Liệu kẻ tấn công có thể khai thác điều này thông qua quét tự động không?
Đáp: Có — các lỗ hổng SQLi không xác thực là mục tiêu phổ biến cho các trình quét tự động và bot. Việc giảm thiểu nhanh chóng là rất cần thiết.

Hỏi: Tôi có nên gỡ cài đặt plugin nếu tôi không sử dụng nó không?
Đáp: Chắc chắn rồi. Các plugin không sử dụng làm tăng rủi ro. Nếu bạn không cần TableOn, hãy vô hiệu hóa và xóa nó.

---

Ví dụ: mẫu truy vấn an toàn vs không an toàn (dành cho các nhà phát triển)

Không an toàn:

<?php

An toàn:

<?php

---

Những gì WP‑Firewall khuyến nghị ngay bây giờ

• Cập nhật TableOn lên 1.0.6 ngay lập tức trên mọi trang bị ảnh hưởng.
• Nếu bạn quản lý nhiều trang và không thể cập nhật tất cả cùng một lúc, hãy kích hoạt các quy tắc vá ảo / chặn trên toàn mạng của bạn để ngăn chặn việc khai thác.
• Chạy quét bảo mật toàn diện và xem xét nhật ký để tìm các chỉ số của sự xâm phạm.
• Thay đổi thông tin đăng nhập và thực thi MFA trên các tài khoản quản trị.
• Duy trì chính sách quản lý plugin nghiêm ngặt để giảm thiểu việc lộ tương tự trong tương lai.

---

Bảo vệ trang web của bạn ngay hôm nay — Bắt đầu với Kế hoạch Miễn phí WP‑Firewall

Tiêu đề: Bảo vệ trang WordPress của bạn trong vài phút — Thử kế hoạch miễn phí WP‑Firewall

Bạn muốn bảo vệ nhanh chóng, được quản lý trong khi xử lý cập nhật và phản ứng sự cố? Kế hoạch Cơ bản (Miễn phí) của WP‑Firewall cung cấp các biện pháp bảo vệ thiết yếu mà mọi trang WordPress cần:

• Tường lửa được quản lý và Tường lửa ứng dụng web (WAF)
• Bảo vệ băng thông không giới hạn
• Quét phần mềm độc hại tự động
• Các biện pháp giảm thiểu 10 rủi ro hàng đầu của OWASP

Nếu bạn cần công cụ khắc phục nhanh hơn, hãy xem xét các kế hoạch Tiêu chuẩn hoặc Chuyên nghiệp của chúng tôi cho việc loại bỏ phần mềm độc hại tự động, danh sách đen/trắng IP, vá lỗi ảo lỗ hổng, báo cáo bảo mật hàng tháng và dịch vụ bảo mật được quản lý.

Đăng ký kế hoạch Cơ bản miễn phí và nhận bảo vệ tự động ngay lập tức cho các trang của bạn:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Suy nghĩ kết thúc

Lỗ hổng SQL injection trong TableOn là một ví dụ điển hình về lý do tại sao bảo mật plugin phải được coi là ưu tiên hoạt động. SQLi không xác thực cho phép kẻ tấn công có lối đi trực tiếp đến cơ sở dữ liệu của bạn và, do đó, đến dữ liệu của người dùng và tính toàn vẹn của trang web của bạn. Tin tốt là tác giả plugin đã phát hành một bản vá (1.0.6) — nhưng khoảng thời gian giữa việc công bố và khai thác thường rất ngắn.

Nếu bạn quản lý các trang WordPress, hãy hành động ngay: cập nhật, quét và áp dụng vá lỗi ảo nếu bạn không thể cập nhật ngay lập tức. Nếu bạn sử dụng WP‑Firewall, các quy tắc vá lỗi ảo của chúng tôi có sẵn để bảo vệ các trang của bạn nhanh chóng trong khi bạn hoàn thành việc khắc phục và dọn dẹp.

Nếu bạn cần trợ giúp: đội ngũ bảo mật của chúng tôi có thể hỗ trợ kiểm tra pháp y, loại bỏ phần mềm độc hại và khuyến nghị tăng cường bảo mật. Để bảo vệ ngay lập tức, hãy đăng ký kế hoạch miễn phí và kết nối trang của bạn — chúng tôi sẽ bắt đầu chặn các nỗ lực khai thác ngay lập tức.

---

Nếu bạn cần danh sách kiểm tra phản ứng sự cố được điều chỉnh cho môi trường lưu trữ của bạn (cPanel, Plesk, nhà cung cấp dịch vụ quản lý), hoặc cần trợ giúp triển khai các quy tắc WAF cụ thể cho lỗ hổng này, hãy liên hệ với đội ngũ hỗ trợ của chúng tôi và chúng tôi sẽ hướng dẫn bạn từng bước.