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

Lỗ hổng SQL Injection khẩn cấp trong WordPress AI Chatbot & Workflow Automation (AIWU) <= 1.4.17 — Phải làm gì ngay bây giờ

Vào ngày 12 tháng 5 năm 2026, một lỗ hổng nghiêm trọng (CVE-2026-2993) đã được công bố cho plugin WordPress “AI Chatbot & Workflow Automation của AIWU” (thường được đóng gói dưới dạng AI Copilot / AIWU). Các phiên bản lên đến và bao gồm 1.4.17 bị ảnh hưởng bởi một lỗ hổng SQL injection không xác thực trong một hàm có tên getListForTbl().

Lỗ hổng này có mức độ nghiêm trọng cao (CVSS 9.3) và có thể khai thác mà không cần xác thực. Điều đó có nghĩa là bất kỳ khách truy cập nào — ngay cả người dùng không xác thực hoặc bot tự động — có thể tiềm năng chèn SQL vào cơ sở dữ liệu của trang web của bạn thông qua điểm cuối bị tổn thương. Nói ngắn gọn: đây là khẩn cấp. Nếu bạn chạy plugin này (hoặc một trang web sử dụng nó), hãy đọc bài viết này từ đầu đến cuối và áp dụng các biện pháp giảm thiểu ngay lập tức.

Dưới đây, chúng tôi giải thích rủi ro là gì, cách lỗ hổng hoạt động ở mức độ cao, các bước giảm thiểu thực tế mà bạn có thể thực hiện ngay bây giờ (bao gồm cả vá ảo với WP-Firewall), các dấu hiệu phát hiện có thể chỉ ra sự xâm phạm, và một danh sách kiểm tra sau sự cố để phục hồi an toàn.

---

Tóm tắt nhanh (dành cho các chủ sở hữu trang muốn những điều thiết yếu)

• Plugin bị ảnh hưởng: WordPress AI Chatbot & Workflow Automation của AIWU (AI Copilot / AIWU)
• Các phiên bản dễ bị tổn thương: <= 1.4.17
• Lỗ hổng: SQL Injection không xác thực trong getListForTbl() (CVE-2026-2993)
• Mức độ nghiêm trọng: Cao (CVSS 9.3)
• Có thể khai thác từ xa mà không cần xác thực
• Hành động ngay lập tức: cập nhật plugin khi có phiên bản an toàn; nếu không thể, thực hiện các biện pháp giảm thiểu tạm thời — vô hiệu hóa hoặc gỡ bỏ plugin, hạn chế truy cập vào điểm cuối bị tổn thương, hoặc áp dụng một bản vá ảo WAF (được khuyến nghị).
• Nếu bạn sử dụng WP-Firewall, hãy bật quy tắc WAF trực tiếp cho lỗ hổng này hoặc đăng ký gói miễn phí của chúng tôi để nhận được bảo vệ ngay lập tức: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Tại sao điều này lại nguy hiểm như vậy

Các lỗ hổng SQL injection (SQLi) cho phép kẻ tấn công chèn các câu lệnh SQL vào các truy vấn cơ sở dữ liệu mà ứng dụng của bạn thực hiện. Khi mã dễ bị tổn thương chạy mà không có tham số hóa hoặc làm sạch đúng cách, kẻ tấn công có thể thao tác các truy vấn để:

• Đọc hoặc lấy dữ liệu nhạy cảm (người dùng, email, mật khẩu đã băm, nội dung riêng tư)
• Sửa đổi hoặc xóa dữ liệu (bài viết, người dùng, tùy chọn)
• Tạo người dùng quản trị mới hoặc nâng cao quyền hạn
• Thực hiện các lệnh cấp cơ sở dữ liệu (tùy thuộc vào cấu hình DB)
• Kết hợp với các cuộc tấn công khác (ví dụ: ghi tệp, khởi động shell) trong các môi trường cấu hình kém

Lỗ hổng này không yêu cầu xác thực, có nghĩa là nó có thể được kích hoạt bởi bất kỳ khách truy cập nào. Điều này làm tăng đáng kể bề mặt tấn công và khả năng khai thác tự động rộng rãi.

---

Tổng quan kỹ thuật (mức cao — không có mã khai thác)

Lỗ hổng được báo cáo xảy ra trong một hàm có tên getListForTbl() bên trong plugin. Dựa trên chi tiết thông báo công khai, vấn đề xuất phát từ việc xây dựng các truy vấn SQL bằng cách sử dụng đầu vào không được làm sạch từ các tham số HTTP. Một mẫu không an toàn điển hình trông giống như việc nối các tham số yêu cầu trực tiếp vào một chuỗi SQL và thực thi nó với đối tượng cơ sở dữ liệu WordPress ($wpdb) mà không sử dụng các câu lệnh đã chuẩn bị hoặc thoát đúng cách.

Tại sao điều đó quan trọng:

• WordPress cung cấp $wpdb->chuẩn bị() để liên kết an toàn các tham số. Khi mã bỏ qua các câu lệnh đã chuẩn bị và trực tiếp chèn các biến vào SQL, một giá trị tham số độc hại có thể thay đổi logic SQL.
• Nếu plugin tiết lộ một điểm cuối AJAX hoặc front-end chấp nhận các tham số và truyền chúng vào getListForTbl() mà không có xác thực, một kẻ tấn công có thể tạo ra các yêu cầu chèn SQL.

Chúng tôi sẽ không công bố mã khai thác hoặc tải trọng yêu cầu cụ thể. Việc chia sẻ mã khai thác sẽ làm tăng rủi ro cho các trang web chưa được vá. Thay vào đó, chúng tôi sẽ cung cấp hướng dẫn lập trình an toàn, chỉ báo phát hiện và các biện pháp giảm thiểu thực tế.

---

Cách mà một kẻ tấn công có thể lạm dụng điều này (kịch bản)

• Các bot quét tự động và bộ công cụ khai thác thăm dò nhiều trang web sẽ nhắm vào điểm cuối dễ bị tổn thương và chèn tải trọng SQL. Điều này có thể dẫn đến khai thác hàng loạt quy mô lớn.
• Một cuộc tấn công thành công có thể trút dữ liệu từ các bảng như wp_users, wp_options, hoặc bất kỳ bảng nào khác có thể truy cập bởi người dùng DB WordPress.
• Kẻ tấn công thường sử dụng SQLi để tạo tài khoản quản trị viên mới, sửa đổi các plugin/giao diện đang hoạt động, hoặc lưu trữ backdoor trong hệ thống tệp (thông qua các tùy chọn và tính năng của plugin/giao diện).
• Việc đánh cắp thông tin đăng nhập từ wp_users có thể dẫn đến việc chiếm đoạt toàn bộ trang web hoặc di chuyển sang các dịch vụ khác.

Bởi vì lỗ hổng này không yêu cầu xác thực, ngay cả các trang web có lưu lượng thấp cũng gặp rủi ro. Kẻ tấn công thường nhắm đến hàng ngàn trang web một cách bừa bãi bằng các công cụ tự động.

---

Dấu hiệu của sự xâm phạm (những gì cần tìm kiếm ngay bây giờ)

Kiểm tra trang web của bạn cho các dấu hiệu nghi ngờ sau đây. Không có dấu hiệu nào trong số này là bằng chứng xác định về việc khai thác một mình, nhưng chúng cần được chú ý ngay lập tức:

• Các lỗi không giải thích được trong nhật ký đề cập đến cảnh báo cơ sở dữ liệu, lỗi SQL, hoặc các truy vấn bị sai định dạng.
• Số lượng lớn yêu cầu đến các điểm cuối cụ thể của plugin (điểm cuối AJAX, tuyến REST) từ các IP hoặc dải IP bất thường.
• Các truy vấn đọc cơ sở dữ liệu không mong đợi cho information_schema hoặc các siêu dữ liệu khác (nếu nhật ký DB hoặc tường lửa của bạn có thể hiển thị văn bản truy vấn).
• Tài khoản người dùng mới với quyền quản trị mà bạn không tạo ra.
• Các tệp plugin/giao diện đã được sửa đổi hoặc các thay đổi tệp gần đây trong wp-content/uploads, wp-content/plugins, hoặc wp-content/themes mà bạn không ủy quyền.
• Nhiệm vụ theo lịch đáng ngờ (cron) hoặc các cron job mới trong WordPress.
• Kết nối mạng ra ngoài từ trang web của bạn mà bạn không mong đợi (tải dữ liệu lên các máy chủ do kẻ tấn công kiểm soát).
• Gửi email spam từ miền của bạn hoặc thay đổi cấu hình cài đặt mail.
• Tăng tải CPU hoặc cơ sở dữ liệu trong thời gian ngắn.

Nếu bạn thấy bất kỳ điều gì ở trên, hãy coi trang web của bạn là có khả năng bị xâm phạm và làm theo danh sách kiểm tra phản ứng sự cố bên dưới.

---

Các bước ngay lập tức để giảm thiểu rủi ro (từng bước một)

Nếu trang web của bạn sử dụng plugin AIWU và đang chạy phiên bản dễ bị tổn thương (<= 1.4.17), hãy hành động ngay lập tức. Chọn các bước phù hợp với môi trường và ràng buộc hoạt động của bạn.

1. Xác nhận sự hiện diện và phiên bản của plugin
   • Bảng điều khiển: Plugins > Installed Plugins > kiểm tra số phiên bản.
   • FTP/SSH: Kiểm tra thư mục plugin (wp-content/plugins//readme.txt hoặc tiêu đề tệp chính của plugin).
2. Nếu bạn có thể cập nhật plugin một cách an toàn lên phiên bản đã được vá, hãy làm ngay.
   • Cập nhật qua bảng điều khiển WP hoặc composer nếu trang web của bạn sử dụng quản lý phụ thuộc.
   • Sau khi cập nhật, xóa bộ nhớ cache và quét lại trang web bằng trình quét phần mềm độc hại của bạn.
3. Nếu không có bản vá chính thức nào có sẵn, hoặc bạn không thể cập nhật ngay:
   • Tạm thời vô hiệu hóa plugin:
     • Plugins > Deactivate (nhanh chóng và đáng tin cậy).
     • Nếu bạn không thể truy cập giao diện quản trị, hãy đổi tên thư mục plugin qua SFTP/SSH (ví dụ: từ aiwu thành aiwu.disabled).
   • Điều này ngăn chặn mã dễ bị tổn thương chạy.
4. Vá ảo bằng Tường lửa Ứng dụng Web (được khuyến nghị khi không thể cập nhật)
   • Triển khai một quy tắc WAF để chặn các yêu cầu cố gắng thực hiện các mẫu SQL injection, và cụ thể chặn truy cập vào điểm cuối hoặc tham số dễ bị tổn thương được sử dụng bởi getListForTbl().
   • Nếu bạn chạy WP-Firewall, hãy kích hoạt quy tắc giảm thiểu mà chúng tôi đã công bố cho lỗ hổng này. Quy tắc của chúng tôi chặn các mẫu khai thác phổ biến cho lỗi này cho đến khi có bản vá plugin chính thức.
5. Hạn chế quyền truy cập nếu điểm cuối là màn hình quản trị:
   • Giới hạn quyền truy cập vào wp-admin và các điểm cuối plugin theo IP (nếu có thể).
   • Sử dụng xác thực HTTP trên wp-admin để thêm một rào cản truy cập khác.
   • Vô hiệu hóa các cuộc gọi AJAX phía trước cho plugin (nếu cài đặt cho phép).
6. Xoay vòng thông tin xác thực và bí mật:
   • Thay đổi bất kỳ thông tin đăng nhập người dùng cơ sở dữ liệu nào nếu có dấu hiệu bị xâm phạm.
   • Thay đổi mật khẩu quản trị WordPress và các khóa API được lưu trữ trong cơ sở dữ liệu.
7. Thực hiện sao lưu và chụp ảnh:
   • Trước khi thực hiện các thay đổi khác, hãy sao lưu đầy đủ các tệp và cơ sở dữ liệu để phân tích pháp y.
   • Lưu trữ sao lưu ở nơi khác.
8. Giám sát nhật ký và lưu lượng:
   • Kích hoạt ghi log nâng cao cho các yêu cầu HTTP và truy vấn cơ sở dữ liệu.
   • Giám sát các nỗ lực khai thác lặp lại sau khi giảm thiểu (kẻ tấn công thường thử lại).

---

Hướng dẫn WAF / vá ảo (các mẫu, không phải tải khai thác)

Một WAF có thể ngăn chặn nhiều nỗ lực tiêm SQL trước khi chúng đến ứng dụng. Dưới đây là các hướng dẫn quy tắc chung được khuyến nghị mà bạn có thể áp dụng để chặn các mẫu khai thác phổ biến. Đừng sử dụng chúng như là hàng phòng thủ duy nhất — chúng là biện pháp giảm thiểu cho đến khi có bản cập nhật plugin chính thức được áp dụng.

Ví dụ về các khối chung (quy tắc khái niệm):

• Chặn các yêu cầu có từ khóa SQL nghi ngờ trong tham số hoặc URI khi chúng xuất hiện kết hợp với các ký tự meta nghi ngờ:
  • Các mẫu cần theo dõi: UNION SELECT, information_schema, LOAD_FILE(, INTO OUTFILE, SLEEP(, –, /*, hoặc các dấu phân cách truy vấn xếp chồng như ;.
  • Ví dụ (logic giả lập ModSecurity):
    • Nếu REQUEST_URI hoặc bất kỳ tham số REQUEST_BODY nào chứa: (union.*select|information_schema|load_file\(|into\s+outfile|sleep\(|benchmark\() thì chặn
• Chặn các yêu cầu bao gồm các mã thông báo SQLi dựa trên tautology phổ biến:
  • Mẫu: ' hoặc '1'='1, " hoặc "1"="1, HOẶC 1=1, vân vân.
• Chặn các yêu cầu đến các điểm cuối đã biết của plugin:
  • Nếu plugin tiết lộ các điểm cuối như /wp-admin/admin-ajax.php?action=aiwu_get_list hoặc một tuyến REST cụ thể, chặn hoặc giới hạn tỷ lệ truy cập đến những tuyến đó ngoại trừ từ các IP đáng tin cậy.
• Giới hạn tỷ lệ yêu cầu theo IP đến các điểm cuối của plugin:
  • Các máy quét tự động sẽ cố gắng nhiều payloads. Giới hạn tỷ lệ làm chậm và thường ngăn chặn việc khai thác hàng loạt.

Quan trọng: Các quy tắc WAF nên được thử nghiệm trong chế độ giám sát trước (nếu có thể) để giảm thiểu các cảnh báo sai. WP-Firewall cung cấp các quy tắc đã được điều chỉnh sẵn cho WordPress và có thể được áp dụng trực tiếp.

---

Ví dụ quy tắc kiểu ModSecurity (khái niệm)

# Chặn các thuật ngữ SQLi rõ ràng trong chuỗi truy vấn hoặc thân"

Một lần nữa: đừng sao chép-dán điều này vào sản xuất mà không thử nghiệm và điều chỉnh. WP-Firewall duy trì và cung cấp các quy tắc đã được điều chỉnh cho các ngữ cảnh WordPress và sẽ cập nhật các quy tắc khi mối đe dọa phát triển.

---

Thực hành mã an toàn — cách mà plugin nên được sửa chữa

Nếu bạn là một nhà phát triển duy trì mã plugin, đây là cách đúng để tránh SQL injection trong WordPress:

Mẫu dễ bị tổn thương (giả lập):

// KHÔNG làm điều này:;

Mẫu an toàn sử dụng $wpdb->chuẩn bị():

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

Đối với các giá trị số sử dụng %d; đối với chuỗi sử dụng %s. Đối với các truy vấn LIKE sử dụng esc_like() kết hợp với chuẩn bị. Không sử dụng nối chuỗi đơn giản cho các giá trị xuất phát từ đầu vào của người dùng.

Cũng hãy tuân theo những thực tiễn tốt nhất sau:

• Xác thực và làm sạch đầu vào sớm (kiểm tra loại, danh sách trắng các giá trị cho phép).
• Sử dụng truy vấn có tham số ($wpdb->chuẩn bị).
• Tránh tên bảng động hoặc SQL thô khi có thể — sử dụng API của WordPress.
• Áp dụng kiểm tra khả năng và nonce cho AJAX quản trị hoặc điểm cuối REST.
• Giới hạn đầu ra và tránh tiết lộ lỗi DB thô cho khách hàng.

---

Danh sách kiểm tra dọn dẹp sau khai thác (nếu bạn nghi ngờ bị xâm phạm)

Nếu bạn có lý do để tin rằng trang web của bạn đã bị nhắm đến và có thể đã bị xâm phạm, hãy tuân theo một quy trình cẩn thận. Nếu có thể, hãy làm việc với một chuyên gia bảo mật hoặc nhà cung cấp dịch vụ của bạn.

1. Đưa trang web ngoại tuyến (chế độ bảo trì) hoặc chặn lưu lượng công cộng — bảo tồn chứng cứ.
2. Sao lưu các tệp và cơ sở dữ liệu hiện tại (lưu trữ bên ngoài).
3. Quét trang web để tìm phần mềm độc hại, cửa hậu, webshell và các tệp đã được sửa đổi. Sử dụng nhiều trình quét nếu có thể.
4. Kiểm tra bảng wp_users để tìm các tài khoản quản trị không mong đợi; xóa và điều tra.
5. Kiểm tra wp_options và các bảng khác để tìm các tải trọng tuần tự đáng ngờ hoặc tùy chọn bất hợp pháp.
6. Gỡ bỏ plugin dễ bị tổn thương (vô hiệu hóa và xóa) cho đến khi mã được vá có sẵn.
7. Thay đổi tất cả mật khẩu: quản trị WordPress, người dùng cơ sở dữ liệu, FTP/SFTP, bảng điều khiển hosting, khóa API.
8. Khôi phục từ một bản sao lưu đã biết tốt nếu bạn có thể xác nhận rằng bản sao lưu trước khi bị xâm phạm.
9. Tăng cường bảo mật cho trang web: áp dụng nguyên tắc quyền hạn tối thiểu, vô hiệu hóa chỉnh sửa tệp, kích hoạt giám sát tính toàn vẹn tệp.
10. Quét lại sau khi dọn dẹp và tiếp tục theo dõi nhật ký để tìm các chỉ báo tái nhiễm.

Nếu bạn không tự tin thực hiện các bước này, hãy liên hệ với một chuyên gia bảo mật WordPress đáng tin cậy.

---

Các khuyến nghị tăng cường lâu dài

Để giảm thiểu rủi ro từ các lỗ hổng plugin gây ra sự cố lớn trong tương lai, hãy thực hiện những thực tiễn tốt nhất sau:

• Giữ cho các plugin và chủ đề được cập nhật, nhưng hãy thử nghiệm các thay đổi trong môi trường staging trước khi đưa vào sản xuất.
• Giảm thiểu số lượng plugin đang hoạt động — vô hiệu hóa và gỡ bỏ các plugin không sử dụng.
• Yêu cầu các plugin từ các nguồn uy tín và xem xét nhật ký thay đổi cũng như hoạt động hỗ trợ của chúng.
• Sử dụng một dịch vụ WAF và quét điểm cuối cung cấp vá lỗi ảo và cập nhật quy tắc liên tục.
• Thực hiện sao lưu tự động với các bài kiểm tra khôi phục định kỳ.
• Sử dụng xác thực mạnh: người dùng quản trị duy nhất, mật khẩu mạnh và xác thực hai yếu tố cho tất cả các tài khoản có quyền cao.
• Hạn chế quyền của người dùng cơ sở dữ liệu: sử dụng một người dùng DB chỉ với các quyền mà WordPress yêu cầu (tránh cấp quyền superuser).
• Giám sát nhật ký và thiết lập cảnh báo cho các hoạt động bất thường.
• Duy trì kế hoạch phản ứng sự cố và thông tin liên hệ để được hỗ trợ bảo mật.

---

Cách WP-Firewall giúp (bảo vệ thực sự mà bạn có thể tin tưởng)

Là một nhà cung cấp bảo mật và tường lửa WordPress, WP-Firewall cung cấp nhiều lớp bảo vệ liên quan trực tiếp đến lỗ hổng này:

• Các quy tắc WAF được quản lý phù hợp với các lỗ hổng plugin WordPress (vá lỗi ảo). Khi một lỗ hổng như CVE-2026-2993 được công bố, đội ngũ của chúng tôi nhanh chóng phân tích các mẫu khai thác và đẩy một quy tắc giảm thiểu để chặn các vectơ tấn công có khả năng xảy ra.
• Chặn tấn công theo thời gian thực trên các điểm cuối plugin đã biết có lỗ hổng, được điều chỉnh để giảm thiểu các cảnh báo sai.
• Quét phần mềm độc hại và kiểm tra tính toàn vẹn để phát hiện các thay đổi tệp đáng ngờ và cửa hậu thường theo sau khai thác SQLi.
• Cập nhật thông tin tình báo về mối đe dọa tự động và cải thiện quy tắc để các mẫu tấn công mới bị chặn khi chúng xuất hiện.
• Giới hạn tỷ lệ và bảo vệ bot để làm chậm việc quét hàng loạt và khai thác tự động.
• Các tính năng ghi nhật ký và cảnh báo để bạn có thể thấy các nỗ lực và hành động nhanh chóng.

Nếu bạn muốn duy trì tư thế phòng thủ sâu, việc kết hợp WAF với các sửa lỗi và thực tiễn ở cấp mã được mô tả ở trên sẽ giảm thiểu rủi ro một cách đáng kể.

---

Ví dụ về chữ ký và phát hiện (dành cho quản trị viên và nhà cung cấp dịch vụ)

Nếu bạn vận hành ghi log cấp máy chủ hoặc IDS, hãy thêm phát hiện cho các mẫu cấp cao sau:

• Giá trị tham số bất thường chứa các từ khóa SQL: khớp các yêu cầu mà tham số chứa các mã thông báo như LIÊN ĐOÀN, SƠ ĐỒ THÔNG TIN, NGỦ(, LOAD_FILE(, vân vân.
• Tỷ lệ phản hồi 400/403 cao nhắm vào các điểm cuối plugin từ các IP đơn lẻ.
• Các yêu cầu đến admin-ajax.php hoặc các điểm cuối REST với tải trọng không mong đợi khớp với các từ khóa SQL.
• Bất kỳ yêu cầu nào gây ra lỗi DB lặp lại được ghi lại trong nhật ký ứng dụng.

Một lần nữa, điều chỉnh ngưỡng phát hiện để giảm thiểu các cảnh báo sai.

---

Bảo vệ trang web của bạn ngay bây giờ — đăng ký gói WP-Firewall Basic (Miễn phí)

Nếu bạn muốn bảo vệ ngay lập tức, không tốn chi phí trong khi sắp xếp cập nhật hoặc sửa chữa sâu hơn, gói WP-Firewall Basic (Miễn phí) cung cấp cho bạn các biện pháp phòng ngừa thiết yếu quan trọng cho loại lỗ hổng này:

• Bảo vệ thiết yếu: tường lửa được quản lý, băng thông không giới hạn, WAF, trình quét phần mềm độc hại và giảm thiểu 10 rủi ro hàng đầu của OWASP.
• Triển khai nhanh chóng và cập nhật liên tục các quy tắc WAF khi các lỗ hổng mới được công bố.
• Tùy chọn không tốn chi phí để giữ cho trang web của bạn được bảo vệ trong khi bạn lên kế hoạch nâng cấp, hoặc để kiểm tra khả năng dịch vụ trước khi nâng cấp lên các cấp trả phí.

Đăng ký gói WP-Firewall Miễn phí và kích hoạt các quy tắc WAF hoạt động cho lỗ hổng SQL injection AIWU: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Nếu bạn cần nhiều tự động hóa và kiểm soát hơn, các gói Standard và Pro của chúng tôi thêm vào việc loại bỏ phần mềm độc hại tự động, kiểm soát danh sách đen/trắng IP, vá ảo và dịch vụ bảo mật được quản lý để bảo vệ không cần can thiệp.

---

Những gì cần truyền đạt đến các bên liên quan của bạn

Nếu bạn điều hành các trang web cho khách hàng, nhân viên hoặc người dùng, hãy làm theo các bước giao tiếp rõ ràng:

• Thông báo ngay lập tức cho các chủ sở hữu trang web bị ảnh hưởng nếu bạn quản lý nhiều trang web.
• Thông báo cho các đội nội bộ (CNTT, devops, hỗ trợ) về lỗ hổng và các biện pháp giảm thiểu đã lên kế hoạch.
• Nếu một sự cố xảy ra, hãy có một báo cáo sự cố bằng văn bản ghi lại việc phát hiện, kiểm soát, khắc phục và bài học rút ra.
• Phối hợp bảo trì theo lịch trình (cập nhật plugin hoặc thời gian ngừng hoạt động đã lên kế hoạch) với người dùng trước.

---

Ghi chú cuối cùng — sự khẩn cấp và thận trọng

CVE-2026-2993 là một lỗ hổng SQL injection nghiêm trọng, không xác thực ảnh hưởng đến các đường dẫn mã được sử dụng rộng rãi trong plugin AIWU. Bề mặt tấn công rất rộng và các quét tự động có khả năng tăng lên sau khi công bố công khai. Nếu bạn vận hành các trang WordPress sử dụng plugin này, hãy coi đây là một sự cố vá và giảm thiểu ưu tiên cao.

Nếu việc cập nhật ngay lập tức không phải là một lựa chọn — hoặc bạn muốn một lớp bảo vệ tạm thời nhanh chóng — hãy triển khai một bản vá ảo WAF. WP-Firewall cung cấp bảo vệ miễn phí, được quản lý có thể chặn các nỗ lực khai thác trong khi bạn áp dụng các sửa chữa lâu dài. Đội ngũ kỹ sư bảo mật WordPress của chúng tôi theo dõi các thông báo và phát hành các quy tắc giảm thiểu kịp thời để khách hàng của chúng tôi được bảo vệ khỏi việc khai thác quét hàng loạt.

Chúng tôi sẵn sàng giúp đỡ với việc kiểm tra, giảm thiểu và phản ứng sự cố. Nếu bạn không chắc liệu trang web của mình có bị ảnh hưởng hay không, hãy kích hoạt trình quét WP-Firewall và bộ quy tắc WAF ngay lập tức, và xem lại nhật ký của bạn để tìm hoạt động đáng ngờ.

Hãy giữ an toàn, và đừng ngần ngại liên hệ nếu bạn muốn được hỗ trợ thực hiện bất kỳ bước nào ở trên.

— Đội ngũ Bảo mật WP-Firewall