Nếu bạn đọc bài viết trước của mình về lỗi miniOrange SAML SSO “một slug bảy edition” thì đã biết CVE-2026-61979 là lỗ hổng nghiêm trọng thế nào. Tin mới nhất tuần này: lỗi này không còn là lý thuyết nữa. Theo phân tích của Patchstack phối hợp DigitalOcean, kẻ tấn công đang quét và khai thác hàng loạt hai lỗ hổng CVE-2026-61979 và CVE-2026-15981 trên mọi site có cài plugin miniOrange SAML 2.0 SSO, bất kể edition hay phiên bản. Trong bài này, mình sẽ hướng dẫn bạn kiểm tra site đã vá chưa, rà soát dấu vết tấn công trong log, và dựng rule chặn ngay nếu chưa kịp cập nhật.
Có chuyện gì đang xảy ra với plugin miniOrange SAML SSO?
Kẻ tấn công đang “ném” exploit vào mọi site cài plugin miniOrange SAML 2.0 SSO mà không thèm kiểm tra site đó chạy edition nào, phiên bản nào. Đây là kiểu tấn công cơ hội (opportunistic) chứ không nhắm mục tiêu cụ thể. Hai lỗ hổng đều là authentication bypass cho phép đăng nhập với tư cách bất kỳ user nào, kể cả admin. Phiên bản miễn phí có hơn 10.000 site cài, chưa kể các bản trả phí và enterprise không có thống kê. Điều nguy hiểm nhất: nhà phát triển vá im lặng, không cảnh báo người dùng.
Vì sao đợt tấn công này nguy hiểm hơn bạn nghĩ?
Vấn đề nằm ở chữ “silent patch”. Bản miễn phí đã vá ở phiên bản 5.4.5, nhưng trong changelog chỉ ghi là “bugfix” chứ không phải security patch. Bản trả phí còn tệ hơn: người dùng không hề được thông báo, hệ thống versioning khác với bản miễn phí nên bạn gần như không thể biết site mình đã vá hay chưa nếu không tự kiểm tra tay. Patchstack nói rất đúng: kẻ tấn công không cần biết bạn chạy edition nào, nhưng bạn cần biết. Nếu bạn quản lý nhiều site khách hàng, đây chính là kịch bản tồi tệ nhất — dashboard không báo update, chủ site không biết, còn attacker thì cứ quét đều.
Kiểm tra site đã vá plugin miniOrange SAML SSO chưa?
Bạn làm theo 3 bước sau là xong. Bước 1, xác định phiên bản đang cài bằng WP-CLI:
wp plugin list --path=/var/www/site-cua-ban/public_html | grep miniorange-samlBước 2, so sánh kết quả. Bản miễn phí cần tối thiểu 5.4.5. Lưu ý: đừng tin ô “update available” trong dashboard, vì lỗi versioning giữa các edition khiến dashboard có thể báo sai. Bước 3, nếu dưới ngưỡng an toàn thì cập nhật ngay:
wp plugin update miniorange-saml-2.0-sso --path=/var/www/site-cua-ban/public_htmlLưu ý: nếu bạn dùng bản trả phí hoặc enterprise, hãy vào tài khoản miniOrange tải gói mới nhất rồi upload thủ tục. Slug của các edition giống hệt nhau nên WP-CLI update tự động đôi khi không áp dụng được cho bản license.
Cách rà soát dấu vết tấn công trong log server?
Nếu site bạn từng cài plugin này, đừng chỉ vá xong rồi thôi — hãy kiểm tra xem đã bị vào chưa. Kẻ tấn công khai thác qua endpoint SAML assertion của plugin, nên bạn tìm trong access log những request POST bất thường đến /wp-content/plugins/miniorange-saml-20-single-sign-on/ kèm dấu hiệu khai thác:
grep -Ei "mo-saml|ssoacs|assertionservice" /var/log/nginx/access.log | grep -v "200 GET"
grep -Ei "samlresponse" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20Tập trung vào 3 tín hiệu: request POST từ IP lạ đến endpoint SAML, các login của user admin vào giờ bất thường, và những user mới được tạo với role Administrator mà bạn không biết. Kiểm tra danh sách admin bằng lệnh:
wp user list --role=administrator --path=/var/www/site-cua-ban/public_htmlNếu thấy user lạ, khóa ngay bằng wp user update <user> --role=subscriber rồi đổi mật khẩu toàn bộ admin trước khi dọn dẹp tiếp.
Chặn tạm đợt tấn công khi chưa cập nhật được?
Có những trường hợp bạn không thể cập nhật ngay — site khách hàng, cần backup trước, hay bản enterprise phải chờ bên thứ ba. Lúc đó hãy chặn tạm ở tầng WAF. Nếu bạn dùng Cloudflare, tạo rule chặn POST đến endpoint SAML từ các IP không thuộc dải VPN SSO của công ty:
(http.request.method eq "POST" and http.request.uri.path contains "/miniorange-saml-20-single-sign-on/")Hoặc đơn giản hơn: tạm deactivate plugin nếu site không thực sự cần SSO ngay lúc đó:
wp plugin deactivate miniorange-saml-20-single-sign-on --path=/var/www/site-cua-ban/public_htmlTheo mình, với tính năng SSO thì tắt vài ngày để chờ vá đúng cách vẫn an toàn hơn nhiều so với để một lỗ hổng authentication bypass exposed ra internet. Nguyên tắc cũ mà luôn đúng: giảm bề mặt tấn công trước, tinh gọn chức năng sau.
Troubleshooting: các lỗi thường gặp khi xử lý?
Lỗi 1: Không tìm thấy plugin trong wp plugin list. Slug plugin có thể khác nhau nhẹ giữa các edition. Chạy wp plugin list không kèm grep và tìm bất kỳ plugin nào có chữ “saml” hoặc “miniorange”.
Lỗi 2: Update xong SSO không đăng nhập được. Khá phổ biến sau khi vá, vì plugin làm chặt kiểm tra certificate. Vào Settings của plugin, tải lại metadata IdP và kiểm tra trường X.509 certificate còn khớp với nhà cung cấp danh tính của bạn không.
Lỗi 3: Log quá lớn, grep chậm. Dùng zgrep cho file nén và giới hạn thời gian: zgrep -Ei "samlresponse" /var/log/nginx/access.log.*.gz | head -500. Nếu hosting shared không có quyền đọc log, yêu cầu nhà cung cấp xuất log 7 ngày gần nhất — đa số sẽ cung cấp nếu bạn nêu lý do bảo mật.
Kết luận: bài học rút ra từ đợt tấn công này?
Đợt khai thác miniOrange SAML SSO nhắc mình một điều mà nhiều người quản trị vẫn quên: đừng bao giờ tin changelog của plugin là toàn bộ sự thật. Một dòng “bugfix” có thể ẩn sau nó là lỗ hổng authentication bypass nghiêm trọng. Với mọi plugin liên quan đến đăng nhập, SSO, hay phân quyền, mình luôn treat mỗi bản update như bản security cho đến khi chứng minh ngược lại. Kiểm tra phiên bản plugin SSO trên toàn bộ site bạn quản lý hôm nay, rà log nếu từng cài, và dựng rule WAF làm lớp phòng thủ tạm. Mười phút kiểm tra hôm nay đỡ cho bạn hàng tuần dọn dẹp sau này.
