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

Khẩn cấp: Lỗ hổng SQL Injection trong JetBooking (<= 4.0.3) — 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

Ngày: 2026-03-11

Thẻ: WordPress, bảo mật, lỗ hổng, WAF, SQL Injection, JetBooking

Tóm tắt: Một lỗ hổng SQL injection nghiêm trọng (CVE-2026-3496, CVSS 9.3) đã được công bố trong các phiên bản plugin JetBooking cho WordPress lên đến và bao gồm 4.0.3. Vấn đề này cho phép các kẻ tấn công không xác thực tiêm SQL qua tham số check_in_date. Bài viết này giải thích rủi ro, cách giảm thiểu lỗ hổng ngay bây giờ, những gì cần làm nếu bạn không thể cập nhật ngay lập tức, các bước phát hiện và phục hồi, và cách WP‑Firewall bảo vệ các trang — bao gồm một kế hoạch miễn phí mà bạn có thể kích hoạt trong vài phút.

Mục lục

Chuyện gì đã xảy ra? Tóm tắt nhanh
Tại sao điều này quan trọng: tác động tiềm tàng
Cách thức hoạt động của lỗ hổng (mức độ cao)
Các hành động cần thực hiện ngay lập tức cho chủ sở hữu trang web (theo từng bước)
Nếu bạn không thể vá ngay lập tức — các biện pháp giảm thiểu khẩn cấp
Các quy tắc WAF / vá ảo được đề xuất (các mẫu an toàn, phòng thủ)
Phát hiện và chỉ báo xâm phạm (IoC)
Phục hồi: cách đánh giá và dọn dẹp sau khi bị khai thác
Tăng cường và phòng ngừa (các biện pháp kiểm soát lâu dài)
Câu hỏi thường gặp
Bảo mật trang WordPress của bạn trong vài phút với WP‑Firewall (Kế hoạch miễn phí)

Chuyện gì đã xảy ra? Tóm tắt nhanh

Vào ngày 11 tháng 3 năm 2026, một lỗ hổng SQL injection nghiêm trọng (CVE‑2026‑3496) đã được công bố ảnh hưởng đến plugin JetBooking cho WordPress trong các phiên bản lên đến và bao gồm 4.0.3. Vấn đề này cho phép một kẻ tấn công không xác thực tiêm SQL thông qua ngày_check_in tham số mà plugin chấp nhận trong một số yêu cầu công khai nhất định. Nhà phát triển đã phát hành một bản vá trong phiên bản 4.0.3.1 để giải quyết vấn đề này.

Bởi vì điểm cuối dễ bị tấn công có thể truy cập mà không cần xác thực và lỗ hổng này là SQL injection cổ điển, lỗi này gây ra rủi ro ngay lập tức và nghiêm trọng cho bất kỳ trang nào sử dụng các phiên bản bị ảnh hưởng của plugin và phơi bày điểm cuối dễ bị tấn công.

Tại sao điều này quan trọng: tác động tiềm tàng

SQL injection là một trong những loại lỗ hổng nguy hiểm nhất cho các ứng dụng web. Các hậu quả tiềm tàng bao gồm:

Rò rỉ dữ liệu: một kẻ tấn công có thể đọc các hàng từ bất kỳ bảng nào mà người dùng cơ sở dữ liệu WordPress có thể truy cập — bao gồm địa chỉ email của người dùng, mật khẩu đã băm, bài viết và bất kỳ dữ liệu nhạy cảm nào của plugin.
Manipulation dữ liệu: tùy thuộc vào payload và quyền hạn, các kẻ tấn công có thể chèn, sửa đổi hoặc xóa dữ liệu — bao gồm việc tạo tài khoản quản trị viên cửa sau, sửa đổi nội dung bài viết hoặc thay đổi tùy chọn plugin.
Xâm phạm trang: kết hợp với các vấn đề khác, SQL injection có thể dẫn đến việc xâm phạm toàn bộ trang — cho phép ghi tệp, thực thi mã từ xa hoặc cửa sau kéo dài.
Tuân thủ và tác động đến quyền riêng tư: các vi phạm dữ liệu có thể kích hoạt yêu cầu phản ứng sự cố GDPR/CCPA và báo cáo quy định.
Danh tiếng và gián đoạn hoạt động: việc phá hoại, spam hoặc phân phối nội dung độc hại từ một trang web bị xâm phạm làm tổn hại đến lòng tin và xếp hạng tìm kiếm.

Bởi vì lỗ hổng này không xác thực và được gán điểm CVSS cao (9.3), chúng tôi coi đây là điều quan trọng để các chủ sở hữu trang web hành động ngay lập tức.

Cách thức hoạt động của lỗ hổng (mức độ cao)

Ở cấp độ cao, plugin JetBooking đã chấp nhận một tham số HTTP có tên ngày_check_in và đưa nó vào một truy vấn SQL mà không có sự làm sạch hoặc câu lệnh chuẩn bị đầy đủ. Mặc dù plugin có lý do hợp pháp để chấp nhận đầu vào ngày (để cung cấp khả năng và tìm kiếm theo ngày), việc xác thực không đủ kết hợp với việc nội suy SQL thô đã cho phép một kẻ tấn công tạo ra đầu vào thay đổi cấu trúc của truy vấn được thực thi chống lại cơ sở dữ liệu.

Ghi chú: Tôi cố ý không công bố chuỗi khai thác hoặc tải trọng bằng chứng khái niệm. Việc tiết lộ những điều đó sẽ giúp kẻ tấn công và đi ngược lại với các thực tiễn tốt nhất về tiết lộ có trách nhiệm. Điểm quan trọng đối với các quản trị viên là: ngày_check_in tham số nên được coi là đầu vào không đáng tin cậy và phải được xác thực nghiêm ngặt như một ngày hoặc được xử lý thông qua các truy vấn tham số đã chuẩn bị.

Các hành động ngay lập tức cho chủ sở hữu trang web (từng bước)

Nếu trang web của bạn sử dụng JetBooking, hãy làm theo danh sách kiểm tra ưu tiên này ngay bây giờ:

Xác định xem trang web của bạn có sử dụng JetBooking và phiên bản nào
- Trong quản trị WordPress: Plugins → Plugins đã cài đặt → tìm kiếm “JetBooking”.
- Qua WP‑CLI: wp plugin list --status=active | grep jet-booking và sau đó wp plugin get jet-booking --field=version (hoặc wp plugin list --format=json).
- Nếu trang web của bạn sử dụng một gói giao diện hoặc đến từ một thị trường phát triển, hãy kiểm tra các plugin đi kèm.
Nếu bạn chạy JetBooking và phiên bản là ≤ 4.0.3: hãy cập nhật ngay lập tức
- Cập nhật JetBooking lên phiên bản 4.0.3.1 hoặc mới hơn. Sử dụng quy trình cập nhật quản trị WordPress hoặc WP-CLI: wp plugin update jet-booking
- Luôn sao lưu trang web của bạn (tệp + cơ sở dữ liệu) trước khi thực hiện cập nhật.
Nếu bạn không thể cập nhật ngay lập tức, hãy áp dụng các biện pháp giảm thiểu khẩn cấp (xem phần tiếp theo)
- Áp dụng WAF/đắp vá ảo để chặn các yêu cầu nghi ngờ nhằm vào ngày_check_in tham số.
- Hạn chế truy cập vào các điểm cuối dễ bị tổn thương (danh sách trắng IP, giới hạn tỷ lệ, hoặc chặn tạm thời).
Sau khi cập nhật hoặc giảm thiểu, hãy xác minh:
- Xác nhận cập nhật plugin đã hoàn tất và plugin đang hoạt động.
- Kiểm tra nhật ký truy cập và lỗi để tìm các yêu cầu đáng ngờ nhắm vào các điểm cuối của plugin hoặc chứa các ký tự metacharacters SQL.
- Chạy quét phần mềm độc hại toàn bộ trang web.
- Thay đổi mật khẩu quản trị và thông tin xác thực dịch vụ nếu bạn phát hiện hoạt động đáng ngờ.
Giám sát và phản hồi:
- Theo dõi nhật ký máy chủ, cảnh báo từ plugin bảo mật và bảng điều khiển WP‑Firewall để tìm các đỉnh bất thường hoặc các nỗ lực thử lại.
- Nếu bạn phát hiện dấu hiệu khai thác, hãy làm theo hướng dẫn phục hồi trong bài viết này.

Nếu bạn không thể vá ngay lập tức — các biện pháp giảm thiểu khẩn cấp

Chúng tôi hiểu rằng một số môi trường (hosting quản lý, các trang web tùy chỉnh nặng, hoặc cửa hàng) có thể yêu cầu kiểm tra trước khi cập nhật plugin. Nếu bạn không thể cập nhật ngay lập tức, hãy đặt các biện pháp kiểm soát tạm thời để giảm thiểu rủi ro:

Bản vá ảo (quy tắc WAF): Chặn hoặc làm sạch bất kỳ yêu cầu nào mà ngày_check_in tham số chứa các ký tự ngoài một mẫu ngày nghiêm ngặt (ví dụ regex bên dưới).
Hạn chế truy cập vào các điểm cuối: Nếu trình xử lý dễ bị tổn thương có thể truy cập tại một đường dẫn cụ thể, hãy hạn chế đường dẫn đó theo IP (chỉ cho phép lưu lượng truy cập mong đợi), hoặc chặn hoàn toàn nếu không cần thiết.
Giới hạn tỷ lệ yêu cầu: Thêm giới hạn tỷ lệ nghiêm ngặt cho các điểm cuối công khai được sử dụng bởi JetBooking để các nỗ lực tấn công brute force hoặc tiêm lặp lại trở nên khó khăn hơn.
Vô hiệu hóa plugin (tạm thời): Nếu plugin không quan trọng cho hoạt động của trang web, hãy vô hiệu hóa nó cho đến khi bạn có thể cập nhật.
Tăng cường quyền truy cập DB: Đảm bảo người dùng DB WordPress có các quyền tối thiểu cần thiết. Mặc dù điều này không loại bỏ rủi ro đọc dữ liệu nếu ứng dụng vẫn có quyền SELECT, nhưng nó có thể giảm thiểu tác động của các thao tác ghi hủy diệt.

Những biện pháp này là tạm thời và không thay thế việc áp dụng cập nhật plugin chính thức.

Các quy tắc WAF / bản vá ảo được đề xuất

Dưới đây là các quy tắc an toàn, định hướng phòng thủ mà bạn có thể sử dụng trong Tường lửa Ứng dụng Web hoặc cổng bảo mật. Chúng mang tính bảo thủ và được thiết kế để giảm thiểu các cảnh báo sai trong khi chặn các mẫu SQL injection phổ biến nhắm vào tham số ngày. Đừng coi đây là các chuỗi khai thác đầy đủ.

Quan trọng: Điều chỉnh cú pháp quy tắc cho động cơ WAF của bạn và kiểm tra các quy tắc trong môi trường staging trước khi triển khai vào sản xuất.

Xác thực các định dạng ngày cho phép (được khuyến nghị)
- Chỉ cho phép các định dạng ngày giống như ISO như YYYY-MM-DD, YYYY/MM/DD, hoặc dấu thời gian khi phù hợp.
- Ví dụ mẫu logic (pseudo‑regex): ^\d{4}[-/]\d{2}[-/]\d{2}$
- Chặn các yêu cầu nơi ngày_check_in không khớp với mẫu này.
Ví dụ về quy tắc giả:
```
Nếu ARGS:check_in_date KHÔNG khớp với regex ^\d{4}[-/]\d{2}[-/]\d{2}$ thì
```
Chặn các ký tự nghi ngờ trong check_in_date
- Từ chối các yêu cầu mà ngày_check_in chứa dấu nháy đơn (‘), dấu nháy kép (“), dấu chấm phẩy (;), dấu đánh dấu bình luận (–, /*), hoặc các từ khóa SQL được phân tách bởi các ký tự không phải chữ số.
- Giữ quy tắc này bảo thủ để tránh làm hỏng các yêu cầu hợp lệ.
Ví dụ về quy tắc giả:
```
Nếu ARGS:check_in_date chứa bất kỳ [', ", ;, --, /*]
```
Phát hiện từ khóa SQL theo phương pháp Heuristic (cho các chữ ký tiêm)
- Phát hiện sự hiện diện của các từ khóa như LIÊN ĐOÀN, LỰA CHỌN, CHÈN, CẬP NHẬT được sử dụng trong các ngữ cảnh bất thường bên trong ngày_check_in tham số.
- Sử dụng phát hiện ranh giới từ và so khớp không phân biệt chữ hoa chữ thường.
Ví dụ về quy tắc giả:
```
Nếu ARGS:check_in_date khớp với regex (?i)\b(UNION|SELECT|INSERT|UPDATE|DROP|ALTER)\b
```
Chặn các chuỗi truy vấn nghi ngờ trong các yêu cầu đến các điểm cuối plugin đã biết
- Nếu plugin tiết lộ một điểm cuối AJAX hoặc REST cụ thể (ví dụ, /wp-admin/admin-ajax.php?action=jet_booking_*) và ARGS chứa ngày_check_in với các ký tự không đều, chặn lại.
Ví dụ về quy tắc giả:
```
Nếu REQUEST_URI chứa "jet-booking" hoặc ARGS:action bắt đầu bằng "jetbooking" và ARGS:check_in_date không khớp với regex ngày
```
Giới hạn tỷ lệ và tổng hợp chữ ký
- Nếu một IP kích hoạt nhiều chặn trong một khoảng thời gian ngắn, tạm thời chặn IP đó ở mức tường lửa.
Ví dụ về quy tắc giả:
```
Nếu một IP kích hoạt 10 sự kiện chặn trong 60 giây
```

Ghi chú:

Đây là các mẫu phòng thủ chung. Điều chỉnh regex và ngưỡng dựa trên lưu lượng truy cập bình thường của trang web của bạn và định dạng tham số ngày.
Ghi log: đảm bảo các sự kiện bị chặn được ghi lại với ngữ cảnh yêu cầu đầy đủ để phân tích sau này.
Kiểm tra ở chế độ giám sát/ghi log trước khi chặn hoàn toàn để đo lường các trường hợp dương tính giả.

Phát hiện và chỉ báo xâm phạm (IoC)

Nếu trang web của bạn sử dụng JetBooking ≤ 4.0.3, bạn nên tìm kiếm trong log để phát hiện hoạt động đáng ngờ. Tìm kiếm:

Yêu cầu chứa ngày_check_in với các ký tự không mong đợi (dấu ngoặc kép, dấu đánh dấu bình luận, từ khóa SQL).
Tần suất cao của các yêu cầu đến các điểm cuối của plugin từ cùng một IP, đặc biệt là từ các dải IP đám mây hoặc ẩn danh.
Các truy vấn cơ sở dữ liệu không mong đợi trong log truy vấn chậm hoặc trong log ứng dụng (nếu bạn ghi lại các truy vấn thô).
Tạo người dùng quản trị mới, hoặc sửa đổi wp_tùy_chọn, wp_người dùng, wp_posts, hoặc các bảng nhạy cảm khác.
Các tác vụ theo lịch không mong đợi (cron jobs), các tệp PHP mới trong thư mục tải lên hoặc wp-content, các tệp plugin/theme đã thay đổi.
Kết nối ra ngoài từ máy chủ web đến các máy chủ hoặc địa chỉ IP không xác định (chỉ ra việc rò rỉ dữ liệu hoặc gọi lại).

Các tìm kiếm log được đề xuất (ví dụ):

Tìm kiếm log máy chủ web cho các hoạt động đáng ngờ ngày_check_in tham số:
grep -i "check_in_date" /var/log/nginx/access.log | grep -E "('|--|union|select|;|/\*)"
Kiểm tra cơ sở dữ liệu để tìm người dùng quản trị mới:
CHỌN ID, user_login, user_email, user_registered TỪ wp_users SẮP XẾP THEO user_registered GIẢM DẦN GIỚI HẠN 10;

Nếu bạn phát hiện bằng chứng về hoạt động trái phép, hãy xem xét việc cách ly trang web (đưa vào chế độ bảo trì/truy cập hạn chế), sao lưu trạng thái hiện tại và làm theo các bước phục hồi bên dưới.

Phục hồi: cách đánh giá và dọn dẹp sau khi bị khai thác

Nếu bạn tìm thấy dấu hiệu rằng trang web của bạn đã bị khai thác, hãy thực hiện các bước sau để kiểm soát và phục hồi:

Cách ly trang web:
- Tạm thời đưa trang web ngoại tuyến hoặc hạn chế truy cập chỉ cho các IP đã biết.
- Thay đổi mật khẩu quản trị và bất kỳ thông tin tài khoản nào khác (FTP, bảng điều khiển hosting, thông tin đăng nhập người dùng cơ sở dữ liệu) có thể bị xâm phạm.
Bảo quản bằng chứng:
- Tạo một bản sao lưu đầy đủ của trang web (tệp + DB) trước khi thực hiện các thay đổi khác, để phân tích pháp y.
- Xuất các nhật ký liên quan (máy chủ web, cơ sở dữ liệu, nhật ký xác thực hệ thống) đến một vị trí an toàn.
Quét và loại bỏ phần mềm độc hại/cửa hậu:
- Sử dụng các công cụ quét phần mềm độc hại đáng tin cậy để tìm các tệp PHP nghi ngờ, mã bị che giấu hoặc webshells.
- Kiểm tra thủ công các tệp vừa được sửa đổi (sắp xếp theo thời gian sửa đổi) trong wp-content và các thư mục có thể ghi khác.
Xem xét cơ sở dữ liệu:
- Tìm các hàng không được phép trong wp_người dùng, wp_usermeta, wp_tùy_chọn, và bất kỳ bảng plugin nào.
- Nếu người dùng quản trị đã được thêm vào, hãy xóa họ và kiểm tra những gì các tài khoản đó đã làm.
Khôi phục từ bản sao lưu sạch nếu có:
- Nếu bạn có một bản sao lưu được biết là sạch từ trước khi bị xâm phạm, hãy xem xét việc khôi phục. Sau khi khôi phục, ngay lập tức cập nhật JetBooking lên phiên bản đã được vá và các plugin/theme/core khác.
Xây dựng lại và tăng cường bảo mật:
- Thay thế các tệp WordPress, plugin và theme cốt lõi từ các nguồn đáng tin cậy.
- Đảm bảo quyền tệp là chính xác và rằng các thư mục tải lên/plugin không cho phép thực thi PHP tùy ý (nơi phù hợp).
- Thay đổi mật khẩu cơ sở dữ liệu và bất kỳ khóa API dịch vụ nào khác được lưu trữ trong trang web.
Giám sát sau sự cố:
- Kích hoạt lại sản xuất với việc giám sát được thiết lập (WAF ở chế độ chặn, giám sát tính toàn vẹn tệp, quét định kỳ).
- Theo dõi lưu lượng truy cập ra ngoài hoặc các mẫu lây nhiễm lặp lại.

Nếu bạn không thoải mái thực hiện một cuộc dọn dẹp pháp y toàn diện, hãy thuê một chuyên gia bảo mật hoặc nhà cung cấp phản ứng sự cố được quản lý.

Hướng dẫn cho nhà phát triển: cách sửa chữa plugin

Đối với các tác giả và nhà phát triển plugin, cách sửa chữa đúng là coi đầu vào của người dùng là không đáng tin cậy và sử dụng API cơ sở dữ liệu của WordPress một cách an toàn:

Sử dụng các câu lệnh đã chuẩn bị với $wpdb->chuẩn bị() thay vì nối đầu vào của người dùng vào SQL.
```
$sql = $wpdb->prepare( "SELECT * FROM {$wpdb->prefix}my_table WHERE check_in_date = %s", $check_in_date );
```
Xác thực các loại đầu vào một cách nghiêm ngặt:
- Khi mong đợi một ngày, phân tích bằng cách sử dụng DateTime::createFromFormat() (PHP) hoặc xác minh khớp regex, sau đó chuẩn hóa thành định dạng an toàn.
Thoát các đầu ra và không bao giờ sử dụng đầu vào không đáng tin cậy trong các truy vấn SQL hoặc đường dẫn tệp.
Hạn chế các điểm cuối công khai: nếu một yêu cầu chỉ cần được sử dụng bởi người dùng đã xác thực, hãy thực thi kiểm tra khả năng sớm.
Sử dụng nonces cho các điểm cuối AJAX dựa trên hành động khi thích hợp.
Áp dụng cách tiếp cận mặc định an toàn: nếu một đầu vào là tùy chọn, hãy đảm bảo rằng việc thiếu tham số dẫn đến một con đường an toàn.

Tăng cường và phòng ngừa (kiểm soát lâu dài)

Giữ cho lõi WordPress, các chủ đề và plugin được cập nhật; áp dụng quy trình cập nhật theo giai đoạn cho các trang sản xuất.
Chạy WAF/ vá ảo liên tục để giảm thiểu rủi ro zero-day.
Thực hiện nguyên tắc quyền tối thiểu cho người dùng cơ sở dữ liệu: hạn chế chỉ các động từ SQL và lược đồ cần thiết khi có thể.
Sử dụng mật khẩu quản trị mạnh, độc nhất và 2FA cho người dùng có quyền.
Sao lưu định kỳ được lưu trữ ngoài site với chính sách phiên bản và giữ lại.
Quét bảo mật định kỳ và kiểm tra xâm nhập tập trung vào các plugin và tích hợp tùy chỉnh.
Giám sát tính toàn vẹn tệp để phát hiện thay đổi đối với các tệp PHP.
Gỡ bỏ hoặc vô hiệu hóa các plugin và chủ đề không sử dụng; giảm bề mặt tấn công.

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

H: Tôi đã cập nhật lên 4.0.3.1 — tôi có an toàn không?
Đ: Cập nhật lên 4.0.3.1 loại bỏ lỗ hổng từ mã plugin. Sau khi cập nhật, xác minh nhật ký và chạy quét để đảm bảo không có khai thác nào trước đó đã xảy ra. Tiếp tục giám sát hoạt động đáng ngờ.

H: Tôi không sử dụng JetBooking — tôi có cần lo lắng không?
Đ: Nếu JetBooking không được cài đặt hoặc hoạt động trên trang của bạn, bạn không bị ảnh hưởng bởi lỗ hổng của plugin này. Tuy nhiên, hãy tiếp tục thực hiện các thực hành vá lỗi tốt trên tất cả các plugin.

H: Liệu việc giới hạn quyền truy cập cơ sở dữ liệu có bảo vệ tôi hoàn toàn không?
Đ: Giới hạn quyền truy cập DB giảm rủi ro, nhưng nếu ứng dụng cần hợp pháp SELECT/INSERT/v.v., việc tiêm vẫn có thể gây hại. Cách tiếp cận đúng là phòng thủ sâu: vá mã, sử dụng truy vấn có tham số và kích hoạt bảo vệ WAF.

H: Quét tự động có đủ không?
Đ: Quét là cần thiết nhưng không đủ một mình. Kết hợp cập nhật, bảo vệ WAF, giám sát, sao lưu và lập kế hoạch phản ứng sự cố.

Bảo mật trang WordPress của bạn trong vài phút với WP‑Firewall (Kế hoạch miễn phí)

Tiêu đề: Bảo vệ trang của bạn ngay lập tức — thử WP‑Firewall Basic (Miễn phí) hôm nay

Nếu bạn đang tìm kiếm sự bảo vệ nhanh chóng, hiệu quả trong khi cập nhật và điều tra, WP‑Firewall cung cấp các biện pháp bảo vệ tường lửa được quản lý được thiết kế đặc biệt cho các trang WordPress. Kế hoạch Basic (Miễn phí) của chúng tôi bao gồm một WAF được quản lý, lọc băng thông không giới hạn, quét phần mềm độc hại và các biện pháp bảo vệ giảm thiểu rủi ro OWASP Top 10 — chính xác là những loại phòng thủ có thể ngăn chặn các nỗ lực tấn công nhắm vào các tham số như ngày_check_in trước khi chúng đến ứng dụng của bạn.

Tại sao chọn kế hoạch Basic ngay bây giờ? Nó cung cấp:

Vá ảo ngay lập tức để chặn các mẫu khai thác đã biết.
Quy tắc được quản lý được điều chỉnh cho các vectơ tấn công phổ biến của WordPress.
Quét phần mềm độc hại liên tục để bạn có thể phát hiện các thay đổi đáng ngờ.
Không tốn chi phí để bắt đầu bảo vệ trang của bạn trong vòng vài phút.

Đăng ký kế hoạch WP‑Firewall Basic (Miễn phí) và kích hoạt bảo vệ cho trang của bạn tại:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Nếu bạn cần các tính năng nâng cao — loại bỏ phần mềm độc hại tự động, danh sách đen/trắng IP, vá ảo và báo cáo an ninh hàng tháng — chúng tôi cung cấp các cấp độ trả phí với các điều khiển bổ sung. Nhưng bắt đầu với kế hoạch miễn phí ngay lập tức giảm rủi ro trong khi bạn cập nhật.)

Những suy nghĩ kết thúc từ WP‑Firewall Security

Lỗ hổng JetBooking này là một lời nhắc nhở mạnh mẽ rằng ngay cả những plugin được xây dựng để thực hiện các tác vụ đơn giản (đặt chỗ và tìm kiếm ngày) cũng có thể gây ra các vấn đề bảo mật nghiêm trọng nếu các đầu vào không được xử lý một cách phòng ngừa. Nếu bạn điều hành các trang WordPress, hãy coi việc cập nhật plugin là ưu tiên hàng đầu — đặc biệt là đối với các lỗ hổng không xác thực cho phép tiêm SQL.

Hướng dẫn của chúng tôi cho các chủ sở hữu trang web:

Xác nhận xem trang web của bạn có bị ảnh hưởng hay không và cập nhật JetBooking lên phiên bản 4.0.3.1 hoặc mới hơn như là hành động đầu tiên của bạn.
Nếu việc cập nhật ngay lập tức là không khả thi, hãy kích hoạt các biện pháp bảo vệ WAF lọc ngày_check_in các mẫu đầu vào và giới hạn tốc độ yêu cầu.
Giám sát nhật ký, quét các chỉ số xâm phạm và chuẩn bị thực hiện phục hồi nếu cần thiết.
Đăng ký WP‑Firewall Basic để nhận được sự bảo vệ quản lý ngay lập tức trong khi bạn khắc phục.

Nếu bạn cần hỗ trợ đánh giá môi trường của mình, tăng cường thiết lập của bạn, hoặc triển khai các bản vá ảo, các kỹ sư bảo mật WP‑Firewall của chúng tôi sẵn sàng giúp phân tích nhật ký, tạo ra các quy tắc phù hợp với các mẫu lưu lượng của bạn, và hỗ trợ phản ứng sự cố.

Hãy giữ an toàn, cập nhật các plugin, và ưu tiên phòng thủ sâu.

— Nhóm bảo mật WP‑Firewall

Tài liệu tham khảo và đọc thêm:

CVE‑2026‑3496 (thông báo công khai)
Thông báo của nhà phát triển plugin (JetBooking) và nhật ký thay đổi plugin — kiểm tra trang chính thức của plugin để biết ghi chú phát hành
Tài liệu phát triển WordPress: $wpdb và các câu lệnh đã chuẩn bị; các chức năng làm sạch đầu vào

Thông báo lỗ hổng SQL Injection JetBooking//Xuất bản vào 2026-03-11//CVE-2026-3496

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

Mục lục

Chuyện gì đã xảy ra? Tóm tắt nhanh

Tại sao điều này quan trọng: tác động tiềm tàng

Cách thức hoạt động của lỗ hổng (mức độ cao)

Các hành động ngay lập tức cho chủ sở hữu trang web (từng bước)

Nếu bạn không thể vá ngay lập tức — các biện pháp giảm thiểu khẩn cấp

Các quy tắc WAF / bản vá ảo được đề xuất

Phát hiện và chỉ báo xâm phạm (IoC)

Phục hồi: cách đánh giá và dọn dẹp sau khi bị khai thác

Hướng dẫn cho nhà phát triển: cách sửa chữa plugin

Tăng cường và phòng ngừa (kiểm soát lâu dài)

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

Bảo mật trang WordPress của bạn trong vài phút với WP‑Firewall (Kế hoạch miễn phí)

Những suy nghĩ kết thúc từ WP‑Firewall Security

Tài liệu tham khảo và đọc thêm:

Nhận WP Security Weekly miễn phí 👋
Đăng ký ngay!!

Liên hệ với chúng tôi để lên lịch tư vấn bảo mật WordPress miễn phí

Thông báo lỗ hổng SQL Injection JetBooking//Xuất bản vào 2026-03-11//CVE-2026-3496

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

Mục lục

Chuyện gì đã xảy ra? Tóm tắt nhanh

Tại sao điều này quan trọng: tác động tiềm tàng

Cách thức hoạt động của lỗ hổng (mức độ cao)

Các hành động ngay lập tức cho chủ sở hữu trang web (từng bước)

Nếu bạn không thể vá ngay lập tức — các biện pháp giảm thiểu khẩn cấp

Các quy tắc WAF / bản vá ảo được đề xuất

Phát hiện và chỉ báo xâm phạm (IoC)

Phục hồi: cách đánh giá và dọn dẹp sau khi bị khai thác

Hướng dẫn cho nhà phát triển: cách sửa chữa plugin

Tăng cường và phòng ngừa (kiểm soát lâu dài)

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

Bảo mật trang WordPress của bạn trong vài phút với WP‑Firewall (Kế hoạch miễn phí)

Những suy nghĩ kết thúc từ WP‑Firewall Security

Tài liệu tham khảo và đọc thêm:

Nhận WP Security Weekly miễn phí 👋Đăng ký ngay!!

Liên hệ với chúng tôi để lên lịch tư vấn bảo mật WordPress miễn phí

Nhận WP Security Weekly miễn phí 👋
Đăng ký ngay!!