
| Tên plugin | Đăng nhập không mật khẩu OwnID |
|---|---|
| Loại lỗ hổng | Bỏ qua xác thực |
| Số CVE | CVE-2025-10294 |
| Tính cấp bách | Cao |
| Ngày xuất bản CVE | 2025-10-15 |
| URL nguồn | CVE-2025-10294 |
Lỗ hổng vượt qua xác thực nghiêm trọng trong Đăng nhập Không mật khẩu OwnID (<= 1.3.4) — Những gì chủ sở hữu trang WordPress phải làm ngay bây giờ
Tác giả: Nhóm bảo mật WP-Firewall
Ngày: 2025-10-15
Thẻ: WordPress, bảo mật, WAF, lỗ hổng, xác thực, phản ứng sự cố
Tóm tắt — Một lỗ hổng vừa được công bố (CVE-2025-10294) trong plugin Đăng nhập Không mật khẩu OwnID cho WordPress (các phiên bản <= 1.3.4) cho phép các tác nhân không xác thực vượt qua các kiểm soát xác thực. Vấn đề này được phân loại là “Xác thực bị hỏng” với điểm CVSS cao. Nếu bạn chạy WordPress và sử dụng plugin này (hoặc một quy trình xác thực không cần mật khẩu tích hợp với nó), hãy làm theo hướng dẫn dưới đây ngay lập tức để đánh giá, giảm thiểu và phục hồi nếu cần.
Tại sao điều này quan trọng (ngắn gọn)
Các luồng đăng nhập không mật khẩu rất hấp dẫn vì chúng giảm mệt mỏi về mật khẩu cho người dùng. Nhưng chúng cũng tập trung niềm tin vào một số phần chuyển động nhỏ hơn: một điểm cuối callback, xác thực token, xử lý nonce/state và tạo phiên. Khi bất kỳ kiểm tra nào trong số đó không hoàn chỉnh hoặc có thể bị vượt qua, một tác nhân không xác thực có thể có được quyền giống như một người dùng hợp pháp — bao gồm quyền truy cập cấp quản trị. Đó chính xác là rủi ro được báo cáo cho Đăng nhập Không mật khẩu OwnID <= 1.3.4.
Bài viết này giải thích rủi ro, những gì cần tìm và các bước thực tế để bảo vệ trang web của bạn ngay hôm nay. Hướng dẫn được viết từ góc độ của WP-Firewall (một đội ngũ tường lửa và bảo mật WordPress) và dành cho các chủ sở hữu trang web, nhà phát triển và đội ngũ lưu trữ.
Hành động nhanh — những gì cần làm ngay bây giờ (danh sách kiểm tra có thể hành động)
- Nếu bạn đã cài đặt Đăng nhập Không mật khẩu OwnID:
- Ngay lập tức vô hiệu hóa plugin cho đến khi có bản sửa lỗi đáng tin cậy từ phía trên.
wp plugin vô hiệu hóa ownid-passwordless-login(sử dụng WP-CLI)- Bảng điều khiển: Plugins → Plugins đã cài đặt → Vô hiệu hóa
- Ngay lập tức vô hiệu hóa plugin cho đến khi có bản sửa lỗi đáng tin cậy từ phía trên.
- Nếu bạn không thể vô hiệu hóa ngay lập tức, hãy hạn chế quyền truy cập vào wp-admin chỉ cho các IP đáng tin cậy và kích hoạt giới hạn tỷ lệ nghiêm ngặt ở lớp máy chủ web/WAF.
- Giám sát nhật ký để phát hiện hoạt động đăng nhập đáng ngờ hoặc tạo người dùng bất ngờ (xem phần Phát hiện bên dưới).
- Thực hiện vá ảo ngắn hạn với WAF của bạn: chặn các điểm cuối đáng ngờ và các tổ hợp tham số bất thường liên quan đến luồng không mật khẩu (xem các biện pháp giảm thiểu của WP-Firewall).
- Thay đổi bí mật và xem xét việc buộc đặt lại mật khẩu hoặc vô hiệu hóa tất cả các phiên hoạt động cho người dùng quản trị.
- Nếu bạn nghi ngờ bị xâm phạm, hãy theo dõi ngay phần Phản ứng sự cố & Dọn dẹp.
Thực hiện các bước này ngay bây giờ — đừng chờ đợi bản cập nhật plugin chính thức nếu trang web của bạn bị lộ.
Tổng quan về lỗ hổng
- Phần mềm bị ảnh hưởng: Plugin Đăng nhập Không mật khẩu OwnID cho WordPress
- Các phiên bản dễ bị tấn công: <= 1.3.4
- Loại lỗ hổng: Xác thực bị hỏng (OWASP A7)
- CVE: CVE-2025-10294
- Được báo cáo bởi: Jonas Benjamin Friedli (tín dụng nghiên cứu)
- Đặc quyền cần có: Chưa xác thực
- Phiên bản cố định: N/A (tại thời điểm công bố)
Mô tả cấp cao: Quy trình xác thực của plugin chứa một lỗi thực hiện cho phép kẻ tấn công vượt qua các kiểm tra xác thực dự kiến và có được một phiên đã xác thực trên một trang web mục tiêu mà không cần thông tin xác thực hợp lệ hoặc sự đồng ý. Vector khai thác chính xác phụ thuộc vào cách mà plugin xác thực dữ liệu callback và token trong quy trình không mật khẩu. Bởi vì cuộc tấn công không yêu cầu xác thực trước, bề mặt tấn công rất rộng và có thể bị khai thác từ xa.
Phân tích kỹ thuật (những gì có thể đang xảy ra)
Các quy trình xác thực không mật khẩu thường liên quan đến:
- Khởi tạo yêu cầu đăng nhập (người dùng hoặc khách hàng kích hoạt một thử thách không mật khẩu).
- Tạo một thử thách hoặc token ngắn hạn, ghi lại trạng thái và gửi yêu cầu xác minh ngoài băng đến người dùng (email/SMS/ứng dụng xác thực OS).
- Nhận một callback hoặc token xác minh từ nhà cung cấp xác minh hoặc từ khách hàng.
- Xác thực token đã trả về và phiên/trạng thái, sau đó thiết lập một phiên WordPress cho người dùng.
Một triển khai không mật khẩu đáng tin cậy phải:
- Sử dụng token được ký bằng mật mã với thời hạn nghiêm ngặt.
- Liên kết token với một người dùng cụ thể và một trạng thái đã lưu (nonce), ngăn chặn việc phát lại token hoặc hoán đổi token.
- Xác thực các URI nguồn/redirect và đảm bảo rằng các yêu cầu callback là hợp pháp.
- Ngăn chặn việc tạo trực tiếp hoặc nâng cao các phiên thông qua các điểm cuối không kiểm soát.
Trong trường hợp này, lỗ hổng cho thấy một hoặc nhiều bước xác thực đó bị thiếu, không đầy đủ hoặc được thực hiện không chính xác — ví dụ:
- Thiếu hoặc xác minh không đủ của token callback.
- Không đảm bảo rằng token được liên kết với người dùng hoặc trạng thái mong đợi.
- Thiếu kiểm tra nonce/CSRF trên các điểm cuối tạo phiên.
Bởi vì một kẻ tấn công có thể gọi điểm cuối dễ bị tổn thương mà không cần xác thực, họ có thể giả mạo một yêu cầu dẫn đến một phiên cho một người dùng tùy ý, có thể bao gồm cả quản trị viên.
Ghi chú: Đây là một mô tả kỹ thuật cấp cao để giúp các nhà phòng thủ. Tránh chia sẻ chi tiết PoC khai thác công khai — chúng sẽ giúp kẻ tấn công. Tập trung vào việc giảm thiểu.
Tác động — tại sao điều này là quan trọng
Một lỗ hổng vượt qua xác thực với quyền truy cập không xác thực có hậu quả nghiêm trọng:
- Chiếm quyền trang web: Kẻ tấn công có thể có quyền truy cập quản trị, sửa đổi nội dung, tạo cửa hậu hoặc cài đặt các plugin/theme độc hại.
- Đánh cắp dữ liệu: Truy cập vào dữ liệu người dùng, trang riêng tư và nội dung đã lưu trữ.
- Xâm phạm liên tục: Kẻ tấn công có thể tạo người dùng quản trị ẩn hoặc tác vụ theo lịch (cron) để duy trì quyền truy cập.
- Thiệt hại danh tiếng: Thay đổi giao diện, spam hoặc bị liệt vào danh sách đen bởi các công cụ tìm kiếm.
- Di chuyển ngang cho các máy chủ: Trong môi trường chia sẻ, một trang web bị xâm phạm có thể là điểm khởi đầu để tấn công các tài khoản khác nếu quyền truy cập được cấu hình sai.
Bởi vì lỗ hổng này cho phép truy cập không xác thực, xác suất khai thác hàng loạt tự động là cao. Kẻ tấn công quét web để tìm chữ ký plugin dễ bị tổn thương và cố gắng vượt qua đăng nhập một cách có hệ thống.
Cách phát hiện khai thác trên trang web của bạn
Các tín hiệu ngay lập tức để kiểm tra:
- Người dùng quản trị không mong đợi:
- WP-CLI:
wp user list --role=administrator - Bảng điều khiển: Người dùng → Tất cả Người dùng → lọc theo Quản trị viên
- Tìm kiếm các quản trị viên hoặc người dùng mới được tạo gần đây với địa chỉ email lạ.
- WP-CLI:
- Các lần đăng nhập thành công gần đây cho người dùng quản trị từ các địa chỉ IP không quen thuộc:
- Kiểm tra nhật ký truy cập máy chủ web của bạn (nginx/apache) cho các yêu cầu POST đến
wp-login.phphoặc đến các điểm cuối REST với phản hồi 200/302 xung quanh các dấu thời gian nghi ngờ. - Nếu bạn đã bật ghi nhật ký hoạt động (nhật ký kiểm toán), hãy kiểm tra các lần đăng nhập của quản trị viên ngoài giờ làm việc.
- Kiểm tra nhật ký truy cập máy chủ web của bạn (nginx/apache) cho các yêu cầu POST đến
- Thay đổi tệp và tệp mới:
- Tìm kiếm trong các thư mục plugin/theme và wp-content để tìm các tệp không mong muốn.
- Các chỉ số phổ biến: các tệp có tên tương tự như các tệp PHP hệ thống nhưng có dấu thời gian gần đây, các tệp chứa
đánh giá/base64_decode/gzuncompress. - Lệnh tìm mẫu (chạy từ thư mục gốc của trang):
tìm . -type f -mtime -14 -print
(Liệt kê các tệp đã được sửa đổi trong 14 ngày qua.)
- Thay đổi cơ sở dữ liệu:
- Kiểm tra các sửa đổi trong
wp_tùy_chọn(các mục tự động tải đáng ngờ), các tác vụ cron mới (wp_options->cron), hoặc các thay đổi nội dung không được phép. - Tìm kiếm PHP đáng ngờ trong các tùy chọn:
SELECT option_name, LENGTH(option_value) FROM wp_options WHERE option_name LIKE '%template%' OR option_name LIKE '%cron%';
- Kiểm tra các sửa đổi trong
- Lưu lượng truy cập ra ngoài bất thường:
- Kiểm tra tường lửa máy chủ hoặc nhật ký mạng để tìm các kết nối đến các IP/miền không xác định xuất phát từ máy chủ web của bạn.
- Mô hình hoạt động đăng nhập cụ thể cho các điểm cuối không có mật khẩu:
- Xem xét nhật ký truy cập cho các yêu cầu POST/GET đến các điểm cuối liên quan đến plugin hoặc cho các tham số đáng ngờ phù hợp với quy trình không có mật khẩu.
Giữ các bản sao chi tiết của nhật ký để điều tra và phân tích pháp y có thể.
Các tùy chọn giảm thiểu ngay lập tức (chủ sở hữu & quản trị viên trang)
Nếu bạn chạy plugin dễ bị tổn thương, hãy chọn lộ trình an toàn nhanh nhất:
- Ngay lập tức vô hiệu hóa plugin
- Giải pháp giảm thiểu ngắn hạn đáng tin cậy nhất.
- Sử dụng WP-CLI khi bạn có nhiều trang web để quản lý:
wp plugin deactivate ownid-passwordless-login --allow-root
- Nếu bạn không thể vô hiệu hóa:
- Hạn chế truy cập vào các điểm cuối liên quan thông qua quy tắc máy chủ web (cấm tất cả các IP ngoại trừ các IP quản trị viên đáng tin cậy).
- Thêm một đoạn mã .htaccess hoặc nginx để cấm truy cập vào các tệp PHP của plugin và các điểm cuối gây ra lỗ hổng.
- Ví dụ (nginx, chặn theo mẫu URI):
location ~* /wp-content/plugins/ownid-passwordless-login/ {
return 403;
}
- Ghi chú: Hãy cẩn thận — chặn theo đường dẫn có thể làm hỏng các tính năng hợp pháp. Ưu tiên vô hiệu hóa khi có thể.
- Sử dụng WAF của bạn để thực hiện vá ảo:
- Chặn các yêu cầu với các tham số tải trọng nghi ngờ đến các điểm cuối của plugin.
- Thực thi kiểm tra nguồn gốc và tham chiếu cho các yêu cầu thiết lập phiên.
- Thêm giới hạn tỷ lệ nghiêm ngặt để hạn chế tấn công brute-force và quét tự động.
- Thay đổi khóa và làm không hợp lệ các phiên:
- Buộc đặt lại mật khẩu cho người dùng quản trị:
wp user update --user_pass='' - Làm không hợp lệ các phiên bằng cách yêu cầu người dùng đăng xuất và/hoặc sử dụng các plugin hủy bỏ các phiên hoạt động.
- Đặt lại bất kỳ khóa API chia sẻ cấp trang nào được sử dụng bởi các luồng xác thực.
- Buộc đặt lại mật khẩu cho người dùng quản trị:
- Tăng cường quyền truy cập quản trị:
- Tạm thời hạn chế wp-admin chỉ cho các địa chỉ IP đáng tin cậy.
- Bật xác thực hai yếu tố cho tài khoản quản trị (nếu có thể).
- Di chuyển trang đăng nhập hoặc sử dụng một lớp truy cập yêu cầu một bí mật chia sẻ hoặc xác thực HTTP Basic cho wp-admin.
- Giữ bản sao lưu:
- Đảm bảo bạn có một bản sao lưu tốt đã được thực hiện trước bất kỳ sự xâm phạm nào bị nghi ngờ. Không ghi đè bản sao lưu bằng trạng thái bị xâm phạm.
Khuyến nghị vá ảo WP-Firewall (cách mà WAF có thể bảo vệ bạn ngay bây giờ)
Là một nhà cung cấp tường lửa WordPress, chúng tôi khuyến nghị các quy tắc WAF theo lớp sau (chung, không cụ thể cho khai thác) để giảm thiểu rủi ro cho đến khi có bản vá upstream:
- Chặn hoặc thách thức các yêu cầu đến các điểm cuối của plugin:
- Xác định các điểm cuối REST của plugin, các hành động admin-ajax và đường dẫn tệp của plugin.
- Chặn các yêu cầu POST đến các điểm cuối đó từ các dải IP không đáng tin cậy hoặc áp dụng một thách thức CAPTCHA/JavaScript.
- Thực thi kiểm tra tiêu đề HTTP:
- Yêu cầu một tiêu đề Origin và Referer hợp lệ cho các yêu cầu tạo phiên, và từ chối các yêu cầu có tiêu đề bị thiếu hoặc rõ ràng là giả mạo từ các khách hàng không đáng tin cậy.
- Xác thực các tiêu đề thông thường như Content-Type và không cho phép các loại không mong đợi.
- Giới hạn tỷ lệ các luồng nghi ngờ:
- Áp dụng giới hạn tỷ lệ nghiêm ngặt theo IP trên các điểm cuối tạo phiên để làm gián đoạn việc khai thác tự động.
- Cân nhắc các độ trễ tiến bộ hoặc chặn tạm thời sau một số lần thử nhỏ.
- Phát hiện các tổ hợp tham số bất thường:
- Tạo các quy tắc để khớp với các mẫu bất thường trong các tham số nhận dạng người dùng, trạng thái hoặc mã thông báo được sử dụng bởi các luồng không mật khẩu (ví dụ, các mã thông báo quá ngắn/dài hoặc chứa các ký tự bị lỗi).
- Bảo vệ khu vực quản trị bằng một lớp truy cập:
- Yêu cầu xác thực bổ sung hoặc danh sách trắng IP cho wp-admin và XML-RPC. Điều này ngăn chặn nhiều kỹ thuật di chuyển ngang ngay cả khi một kẻ tấn công quản lý để vượt qua plugin.
- Kiểm tra và cảnh báo:
- Tạo cảnh báo WAF cho các yêu cầu POST dẫn đến các hành động xác thực thành công mà không có thách thức trước đó hoặc giá trị trạng thái hợp lệ.
- Chuyển tiếp cảnh báo đến các quản trị viên trang web và đội ngũ lưu trữ để xem xét ngay lập tức.
Quan trọng: Không chỉ dựa vào các quy tắc WAF như một giải pháp lâu dài — chúng chỉ là biện pháp giảm thiểu. Plugin phải được cập nhật hoặc thay thế bằng một triển khai an toàn.
Chữ ký phát hiện và gợi ý ghi nhật ký cho WAF và máy chủ
Tạo quy tắc để ghi nhật ký và cảnh báo về các hành vi quan sát được sau:
- Các yêu cầu POST đến các điểm cuối cụ thể của plugin từ các khách hàng không có cookie phiên hợp lệ.
- Các phản hồi HTTP thành công (200/302) từ các điểm cuối tạo phiên ngay lập tức được theo sau bởi các yêu cầu đến
/wp-admin/hoặcadmin-ajax.phptừ cùng một IP. - Các nỗ lực lặp đi lặp lại để tạo hoặc sửa đổi tài khoản bằng cách sử dụng các điểm cuối của plugin.
- Khối lượng yêu cầu bất thường cho các điểm cuối không có mật khẩu từ một IP duy nhất hoặc một dải IP nhỏ.
Các trường ghi nhật ký cần ghi lại để tương quan:
- Dấu thời gian, IP nguồn, User-Agent
- URI yêu cầu và chuỗi truy vấn
- Tên tham số trong thân POST (tránh ghi nhật ký toàn bộ thân nếu chúng chứa các mã thông báo nhạy cảm)
- Mã phản hồi và kích thước phản hồi
- Trạng thái cookie và ID phiên (nếu có)
Lưu trữ nhật ký ngoài máy chủ nếu có thể để ngăn chặn việc can thiệp trong quá trình điều tra.
Phản ứng sự cố và dọn dẹp (nếu bạn nghi ngờ có sự xâm phạm)
Nếu bạn tìm thấy bằng chứng về sự xâm phạm, hãy làm theo quy trình dọn dẹp có cấu trúc:
- Cách ly trang web:
- Đưa trang web vào chế độ bảo trì hoặc đưa nó ngoại tuyến trong khi bạn điều tra và dọn dẹp.
- Nếu trên hosting chia sẻ, hãy thông báo ngay cho nhà cung cấp của bạn và yêu cầu họ cách ly tài khoản.
- Bảo quản bằng chứng:
- Sao chép nhật ký máy chủ web, bản sao cơ sở dữ liệu và ảnh chụp hệ thống tệp để điều tra pháp y. Không sửa đổi những bản sao này.
- Thay đổi thông tin đăng nhập và khóa:
- Thay đổi mật khẩu quản trị WordPress và bất kỳ khóa API nào được sử dụng bởi trang web.
- Thay đổi mật khẩu hosting và cơ sở dữ liệu.
- Gỡ bỏ plugin dễ bị tổn thương và thay thế:
- Vô hiệu hóa và xóa Đăng nhập không mật khẩu OwnID.
- Thay thế bằng một lựa chọn được đánh giá tốt chỉ sau khi xác minh và kiểm tra độc lập.
- Tìm kiếm và gỡ bỏ cửa hậu:
- Quét các tệp PHP bị tiêm chứa từ khóa:
đánh giá,base64_decode,preg_replacevới /e,create_function,gzinflate,hệ thống,exec,shell_exec. - Lệnh ví dụ để tìm các cách sử dụng đáng ngờ:
grep -R --exclude-dir=uploads -nE "eval\(|base64_decode\(|gzinflate\(|shell_exec\(|system\(" .
- Quét các tệp PHP bị tiêm chứa từ khóa:
- Kiểm tra cơ sở dữ liệu để tìm các thay đổi không được phép:
- Bảng người dùng (
wp_người dùng) cho các tài khoản không xác định. - Bảng tùy chọn cho mã độc hại tự động tải.
- Bảng bài viết cho các kịch bản bị tiêm.
- Bảng người dùng (
- Cài đặt lại lõi, plugin và chủ đề từ các nguồn đáng tin cậy:
- Đừng tin tưởng vào các tệp trên hệ thống tệp bị xâm phạm. Thay thế chúng bằng cách tải xuống các bản sao mới từ WordPress.org hoặc các trang của nhà phát triển.
- Khôi phục từ một bản sao lưu sạch:
- Nếu bạn có một bản sao lưu sạch được thực hiện trước khi bị xâm phạm, hãy khôi phục và sau đó áp dụng các biện pháp bảo mật.
- Giám sát sau khi phục hồi:
- Theo dõi nhật ký chặt chẽ trong 30+ ngày sau khi phục hồi để tìm dấu hiệu tái nhiễm.
- Xem xét một cuộc kiểm toán bảo mật chuyên nghiệp nếu trang web chứa dữ liệu nhạy cảm.
- Xem xét việc tham gia phản ứng sự cố chuyên nghiệp nếu bạn xử lý dữ liệu tài chính hoặc cá nhân quy mô lớn.
Tăng cường xác thực WordPress (dài hạn)
- Tránh các điểm thất bại đơn lẻ: Các quy trình không cần mật khẩu là tốt — nhưng đảm bảo chúng được thực hiện với các mã thông báo đã ký, ràng buộc nonce và xác thực nghiêm ngặt.
- Thực thi xác thực đa yếu tố cho người dùng quản trị.
- Giảm thiểu tài khoản quản trị — sử dụng nguyên tắc quyền hạn tối thiểu.
- Giữ cho các plugin và chủ đề được cập nhật và chỉ cài đặt các plugin từ các nguồn đáng tin cậy.
- Sử dụng một quy trình giám sát và vá lỗi trung tâm cho tất cả các trang bạn quản lý.
- Bật ghi nhật ký và cảnh báo cho các lần đăng nhập quản trị và các thay đổi tệp bất ngờ.
- Tăng cường quyền truy cập tệp và vô hiệu hóa thực thi PHP trong các tệp tải lên khi có thể:
<FilesMatch "\.php$"> Deny from all </FilesMatch> - Thực thi mật khẩu mạnh và xoay vòng định kỳ cho người dùng quản trị.
Khuyến nghị cho các nhà phát triển plugin (danh sách kiểm tra bảo mật theo thiết kế)
- Sử dụng các mã thông báo đã ký (JWT hoặc tương tự) với thời gian hết hạn ngắn và yêu cầu đối tượng.
- Ràng buộc các mã thông báo với trạng thái hoặc nonce được lưu trữ phía máy chủ và được xác thực khi gọi lại.
- Xác thực các URI và nguồn chuyển hướng một cách nghiêm ngặt.
- Luôn xác minh nhà phát hành và chữ ký cho các mã thông báo đến từ các nhà cung cấp bên thứ ba.
- Tránh tạo phiên hoặc nâng cao quyền trên các yêu cầu GET đơn giản.
- Triển khai bảo vệ CSRF/nonce cho bất kỳ điểm cuối nào có thể thay đổi trạng thái hoặc tạo phiên.
- Ghi lại các sự kiện xác thực quan trọng với ngữ cảnh đầy đủ (không tiết lộ bí mật).
- Tạo một quy trình tiết lộ có trách nhiệm và duy trì một lịch trình vá lỗi.
- Cung cấp hướng dẫn tăng cường cho chủ sở hữu trang web và khuyến nghị các quy tắc WAF khi phù hợp.
Đối với các máy chủ và cơ quan — khuyến nghị hoạt động
- Vá lỗi nhanh chóng và cung cấp vá lỗi ảo theo yêu cầu nếu một plugin được nhiều khách hàng sử dụng bị lỗ hổng.
- Cung cấp dịch vụ cách ly và quét trang web cho các khách hàng có thể bị ảnh hưởng.
- Chặn hoặc giới hạn tỷ lệ các mẫu quét và khai thác độc hại đã biết ở rìa.
- Thông báo cho khách hàng với các bước có thể thực hiện và cung cấp trợ giúp để thực hiện các biện pháp giảm thiểu (vô hiệu hóa, chặn, đặt lại phiên).
- Duy trì một quy trình sao lưu và phục hồi đã được kiểm tra và cung cấp phản ứng sự cố như một dịch vụ.
Thời gian & tài liệu tham khảo
- Ngày báo cáo: 15 tháng 10 năm 2025
- CVE: CVE-2025-10294
- Nghiên cứu được ghi nhận cho: Jonas Benjamin Friedli
Đối với tiết lộ kỹ thuật, xem mục CVE chính thức và bài viết của nhà nghiên cứu. (Chúng tôi không tái sản xuất mã khai thác ở đây để tránh tạo điều kiện cho kẻ tấn công.)
Những câu hỏi thường gặp
Q — Nếu tôi vô hiệu hóa plugin, người dùng có mất quyền truy cập vào tài khoản của họ không?
A — Vô hiệu hóa plugin sẽ tắt quy trình không cần mật khẩu do plugin đó cung cấp. Người dùng dựa vào nó sẽ cần đăng nhập qua tên người dùng/mật khẩu tiêu chuẩn hoặc phương thức xác thực khác có sẵn cho đến khi có một phiên bản thay thế an toàn hoặc đã được vá lỗi.
Q — Liệu trang web của tôi có bị xâm phạm tự động nếu tôi cài đặt plugin không?
A — Không phải tự động. Sự hiện diện của lỗ hổng cho thấy khả năng — việc xâm phạm thực tế phụ thuộc vào việc kẻ tấn công có phát hiện và khai thác thành công lỗ hổng trên trang web của bạn hay không. Bạn phải giả định rủi ro và hành động cho phù hợp.
Q — Khi nào sẽ có bản vá chính thức?
A — Tại thời điểm công bố có thể không có bản phát hành chính thức đã được sửa. Theo dõi kênh chính thức của plugin để cập nhật và áp dụng bản vá ngay khi được phát hành. Trong thời gian chờ đợi, hãy áp dụng các biện pháp giảm thiểu được mô tả ở trên.
Bảo vệ các trang WordPress của bạn — Kế hoạch WP-Firewall Basic (Miễn phí)
Bảo vệ mạnh mẽ hơn mà không tốn chi phí
Nếu bạn quản lý các trang WordPress, hãy tận dụng kế hoạch WP-Firewall Basic (Miễn phí) — được thiết kế để cung cấp bảo vệ thiết yếu, được quản lý mà không cần cam kết. Kế hoạch miễn phí bao gồm tường lửa được quản lý của chúng tôi, băng thông không giới hạn, một Tường lửa Ứng dụng Web (WAF) hoạt động, một trình 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. Đây là bước đầu tiên dễ dàng để giảm thiểu khoảng thời gian rủi ro từ các lỗ hổng plugin như thế này.
Đăng ký kế hoạch miễn phí và nhận ngay các quy tắc giảm thiểu ảo được áp dụng cho trang web của bạn: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Nếu bạn cần loại bỏ phần mềm độc hại tự động, kiểm soát danh sách đen/trắng IP, báo cáo bảo mật hàng tháng và vá ảo lỗ hổng, hãy xem xét các kế hoạch Standard và Pro của chúng tôi để biết thêm tính năng và hỗ trợ.)
Lời cuối — ưu tiên việc kiểm soát và xác minh
Việc bỏ qua xác thực này là một lỗ hổng có tác động cao vì nó không yêu cầu thông tin xác thực trước đó. Nếu trang web của bạn sử dụng Đăng nhập Không Mật khẩu OwnID (<=1.3.4), hành động ngay: vô hiệu hóa hoặc chặn plugin, áp dụng các biện pháp giảm thiểu WAF, và kiểm tra nhật ký để tìm dấu hiệu bị xâm phạm. Nếu bạn chạy nhiều trang WordPress, hãy tự động hóa các bước phát hiện và giảm thiểu với giải pháp tường lửa được quản lý để giảm thời gian phân loại thủ công và bảo vệ khách hàng trước khi bản vá chính thức được phát hành.
Nếu bạn cần giúp đỡ trong việc đánh giá một trang web hoặc triển khai vá ảo, hỗ trợ WP-Firewall có sẵn để hỗ trợ với các quy trình giảm thiểu và phục hồi nhanh chóng.
Hãy giữ an toàn,
Nhóm bảo mật WP-Firewall
