Ngày 6/8/2026, WordPress tung ra bản security release 7.0.3, vá tới 12 lỗ hổng bảo mật. Đáng chú ý nhất là lỗ hổng reflected XSS trên trang đăng nhập (login screen) có thể dẫn đến PHP code execution, được báo cáo bởi đội pwn.ai. Nếu site WordPress của bạn đang chạy phiên bản 7.0.x, mình sẽ hướng dẫn bạn cập nhật, kiểm tra dấu hiệu bị khai thác, và hardening từ A đến Z.
Đặc biệt, lỗ hổng XSS trên login screen này rất nguy hiểm vì không cần xác thực — bất kỳ ai cũng có thể gửi link độc hại cho admin, khi admin click và đăng nhập, attacker có thể chiếm quyền kiểm soát toàn bộ site. Mình sẽ đi qua từng bước: kiểm tra phiên bản, backup, cập nhật an toàn, scan dấu hiệu bị hack, và phòng thủ thêm sau khi cập nhật.
WordPress 7.0.3 Sua Nhung Lo Hong Mang Nao?
Bản cập nhật 7.0.3 vá 12 lỗ hổng bảo mật, trong đó 3 lỗ hổng nghiêm trọng nhất đáng chú ý. Thứ nhất là pre-auth reflected XSS trên login screen có thể dẫn đến PHP code execution, do đội pwn.ai phát hiện. Thứ hai là privilege escalation trên multisite network khi bật user registration, do Aikido Security báo cáo. Thứ ba là SSRF trong URL validation cho phép request đến link-local ranges, do Andrew Mohawk và nhiều reporter khác phát hiện.
Lo Hong XSS Tren Login Screen Nguy Hiem Ra Sao?
Đây là lỗ hổng nghiêm trọng nhất trong bản cập nhật này, mang mã CVE-2026-64638. Trang đăng nhập wp-login.php bị reflected XSS, nghĩa là attacker có thể chèn JavaScript độc hại vào URL của trang login. Khi admin hoặc editor click vào link độc hại và nhập thông tin đăng nhập, JavaScript chạy trong browser, có thể steal cookie session, hoặc nghiêm trọng hơn là dẫn đến PHP code execution trên server.
Điều khiến mình lo lắng nhất là lỗ hổng này pre-auth — không cần đăng nhập để khai thác, chỉ cần nạn nhân click link. Trên mạng xã hội, link có thể ngụy trang thành email reset password, link đăng nhập giả mạo, hoặc comment chứa link độc. Ai quản lý site WordPress đều là mục tiêu.
Cac Lo Hong XSS Khong Trong 7.0.3 Con Co Gi?
Ngoài XSS trên login screen, bản 7.0.3 còn vá 5 lỗ hổng stored XSS khác. Contributor+ stored XSS qua emoji settings element, do Asaf Mozes báo cáo. Contributor+ stored XSS trong Post Content block, do n05ec phát hiện. Contributor+ stored XSS trong Quick Edit trên site có nhiều user, do Naveen S và Ajmal Moochingal tìm ra. Contributor+ stored XSS trong Post Date block, do Alex Concha của WordPress Security Team báo cáo. Cuối cùng là Author+ CSS injection qua bypass safe CSS attribute filter, do Anthropic phát hiện.
Tất cả các lỗ hổng stored XSS này đều yêu cầu Contributor role trở lên để khai thác, nên nguy hiểm thấp hơn XSS trên login screen. Nhưng nếu site của bạn cho phép user đăng ký contributor hoặc author, attacker vẫn có thể leo thang quyền kiểm soát.
Lo Hong Privilege Escalation Multisite La Gi?
Lỗ hổng này chỉ ảnh hưởng khi bạn chạy WordPress Multisite Network và bật tính năng user registration. Khi đó, một user thông thường có thể tạo site mới trên network mà không cần quyền, từ đó truy cập vào admin panel của sub-site. Aikido Security là người báo cáo lỗ hổng này.
Nếu bạn không dùng Multisite, lỗ hổng này không ảnh hưởng. Nhưng nếu có, hãy kiểm tra ngay setting registration trong Network Admin > Settings. Tạm thời tắt “Both sites and user accounts can be registered” cho đến khi cập nhật xong.
SSRF Trong URL Validation Nguy Hiem Nhu The Nao?
Lỗ hổng SSRF (Server-Side Request Forgery) nằm trong hàm validation URL của WordPress, cho phép request đến link-local ranges — tức là địa chỉ IP nội bộ như 169.254.169.254 (AWS metadata) hoặc 10.x.x.x. Điều này có nghĩa là attacker có thể dùng server WordPress của bạn làm proxy để truy cập internal network, steal cloud credentials từ metadata endpoint, hoặc scan port nội bộ.
Trên AWS, GCP, Azure, địa chỉ 169.254.169.254 trả về temporary credentials của IAM role gắn với instance. Nếu attacker khai thác được SSRF này, họ có thể steal credentials và di chuyển sang tài nguyên cloud khác. Rất nguy hiểm nếu WordPress chạy trên EC2 hoặc Compute Engine.
Cac Phien Ban Nao Bi Anh Huong?
WordPress 7.0.3 ảnh hưởng đến tất cả phiên bản từ 7.0.0 trở lên. Các phiên bản cũ hơn cũng được backport fix về tận 4.7, nhưng bạn nên cập nhật lên phiên bản mới nhất. Cụ thể: WordPress 7.0.0, 7.0.1, 7.0.2 cần cập nhật lên 7.0.3. Nếu đang chạy nhánh 6.9.x, cập nhật lên phiên bản patch mới nhất của nhánh đó. Tương tự với 6.8.x.
Đội WordPress khuyến nghị cập nhật ngay lập tức vì đây là security release. Các site hỗ trợ auto background update sẽ tự cập nhật, nhưng mình khuyên bạn kiểm tra thủ công để đảm bảo.
Buoc 1: Kiem Tra Phien Ban WordPress Hien Tai
Trước tiên, kiểm tra phiên bản WordPress đang chạy. Đăng nhập wp-admin, nhìn góc dưới bên trái. Hoặc dùng WP-CLI nếu có SSH:
# Kiem tra phien ban WordPress
sudo -u www-data wp core version --path=/var/www/example.com/public_html
# Kiem tra trang thai cap nhat
sudo -u www-data wp core check-update --path=/var/www/example.com/public_htmlNếu kết quả trả về 7.0.3, site đã an toàn. Nếu là 7.0.2 trở xuống, bạn cần cập nhật ngay.
Buoc 2: Backup Truoc Khi Cap Nhat
Security release thường an toàn nhưng backup là bắt buộc. Đặc biệt nếu plugin cũ conflict với patch mới. Mình dùng WP-CLI cho nhanh:
# Backup database
sudo -u www-data wp db export /backup/wp-backup-$(date +%Y%m%d).sql \
--path=/var/www/example.com/public_html
# Backup files
tar -czf /backup/site-backup-$(date +%Y%m%d).tar.gz \
-C /var/www/example.com/public_html .
# Kiem tra backup co day du khong
ls -lh /backup/wp-backup-$(date +%Y%m%d).sql
ls -lh /backup/site-backup-$(date +%Y%m%d).tar.gzNếu bạn chưa có workflow backup, tham khảo bài hướng dẫn backup WordPress trên VPS bằng rsync + mysqldump mà mình đã viết chi tiết từ A đến Z.
Buoc 3: Cap Nhat WordPress Len 7.0.3
Cách nhanh nhất là WP-CLI. Đăng nhập SSH vào server, chạy:
# Cap nhat WordPress core
sudo -u www-data wp core update --path=/var/www/example.com/public_html
# Kiem tra lai phien ban
sudo -u www-data wp core version --path=/var/www/example.com/public_html
# Cap nhat database neu can
sudo -u www-data wp core update-db --path=/var/www/example.com/public_html
# Kiem tra core integrity
sudo -u www-data wp core verify-checksums --path=/var/www/example.com/public_htmlNếu bạn không có SSH, đăng nhập wp-admin, vào Dashboard > Updates, click “Update Now”. Quá trình mất khoảng 30 giây.
Trường hợp managed hosting lock auto-update, tải file wordpress-7.0.3.zip từ wordpress.org, giải nén, ghi đè wp-includes/ và wp-admin/, rồi vào wp-admin chạy database update.
Buoc 4: Cap Nhat Plugin Va Theme Sau Khi Update Core
Sau khi cập nhật WordPress core, hãy cập nhật luôn plugin và theme. Nhiều plugin cũng bị XSS và sẽ được patch trong bản mới:
# Liem ke plugin can cap nhat
sudo -u www-data wp plugin list --update=available \
--path=/var/www/example.com/public_html
# Cap nhat tat ca plugin
sudo -u www-data wp plugin update --all \
--path=/var/www/example.com/public_html
# Cap nhat theme
sudo -u www-data wp theme update --all \
--path=/var/www/example.com/public_htmlNếu một plugin cũ không tương thích và gây fatal error, tạm thời disable nó:
# Disable plugin gay loi
sudo -u www-data wp plugin deactivate ten-plugin \
--path=/var/www/example.com/public_htmlBuoc 5: Kiem Tra Site Da Bi Khai Thac XSS Chua
Lỗ hổng XSS trên login screen (CVE-2026-64638) tồn tại từ trước, có thể đã bị khai thác. Mình khuyên kiểm tra 4 dấu hiệu sau.
Kiểm tra access log tìm request độc đến wp-login.php:
# Tim XSS payload trong wp-login.php request
grep -iE "wp-login.php.*(%3C|<|%3E|>|script|onerror|onload|javascript)" \
/var/log/nginx/access.log | tail -30
# Tim request co base64 encode (thuong dung de hide payload)
grep "wp-login.php" /var/log/nginx/access.log | \
grep -iE "(eval|base64|concat|char)" | tail -20Kiem tra file PHP bat thuong trong wp-content:
# Tim file PHP trong uploads (khong nen co)
find /var/www/example.com/public_html/wp-content/uploads \
-name "*.php" -type f 2>/dev/null
# Tim file bi modify gan day (7 ngay)
find /var/www/example.com/public_html/wp-content \
-name "*.php" -mtime -7 -type f 2>/dev/nullKiem tra user admin bat thuong:
# Liem ke tat ca admin user
sudo -u www-data wp user list --role=administrator \
--fields=ID,user_login,user_email,user_registered \
--path=/var/www/example.com/public_htmlKiểm tra core file integrity:
# Verify checksums
sudo -u www-data wp core verify-checksums \
--path=/var/www/example.com/public_htmlNếu lệnh này báo Warning: File has changed, site có thể đã bị tamper. Cần reinstall WordPress core và kiểm tra kỹ từng file.
Buoc 6: Hardening Login Screen Sau Khi Cap Nhat
Sau khi cập nhật, thêm một lớp bảo vệ cho wp-login.php. Nếu bạn dùng Nginx, giới hạn truy cập theo IP:
# Nginx config: chi cho phep IP cu the truy cap wp-login.php
location = /wp-login.php {
allow YOUR_IP_ADDRESS;
deny all;
fastcgi_pass unix:/run/php/php8.4-fpm.sock;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}Nếu không giới hạn được IP (admin có IP động), dùng Cloudflare Turnstile hoặc Fail2Ban để block brute force và bot tự động. Mình đã có hướng dẫn chi tiết cả hai, áp dụng được cho mọi VPS.
Thêm nữa, nếu bạn dùng Cloudflare, bật WAF Managed Rules để filter XSS payload ở edge trước khi request đến server:
# Cloudflare WAF rule: Block XSS trong wp-login.php
(http.request.uri.path eq "/wp-login.php" and \
(http.request.uri.query contains "WordPress 7.0.3 Co Anh Huong Gi Den Plugin Va Theme?
Không. Giống như bản 7.0.2 trước đó, bản 7.0.3 là security release thuần túy, chỉ patch lỗ hổng trong core, không thay đổi API. Mọi plugin và theme chạy được trên 7.0.2 sẽ chạy bình thường trên 7.0.3. Bạn không cần test compatibility lại.
Đội WordPress bật auto-update cho bản này trên toàn bộ site hỗ trợ. Nếu site của bạn chưa tự cập nhật, nghĩa là đang bị lock bởi hosting hoặc file permission issue. Kiểm tra ngay.
Dac Biet Luu Y Cho Site Chay Tren AWS GCP Azure
Lỗ hổng SSRF trong URL validation cho phép request đến 169.254.169.254 — metadata endpoint của cloud. Nếu WordPress chạy trên EC2, Compute Engine, hoặc Azure VM, attacker có thể steal IAM credentials. Sau khi cập nhật 7.0.3, kiểm tra:
# Kiem tra AWS metadata endpoint co bi trigger khong
# (Chay tren EC2 instance)
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | head
# Kiem tra access log tim request den metadata
grep "169.254.169.254" /var/log/nginx/access.logNếu thấy request đến 169.254.169.254 trong access log, site có thể đã bị exploit. Rotate IAM credentials ngay và kiểm tra CloudTrail log để xem credentials có bị sử dụng trái phép không.
Ngoài ra, nếu đang dùng AWS, bật IMDSv2 (Instance Metadata Service Version 2) để yêu cầu token-based access, chặn SSRF đơn giản. Đây là best practice cho mọi EC2 instance chạy WordPress.
Tong Ket
WordPress 7.0.3 là security release quan trọng với 12 lỗ hổng được vá, trong đó XSS trên login screen có thể dẫn đến RCE là nghiêm trọng nhất. Kết hợp với SSRF đánh cắp cloud credentials, bản cập nhật này không thể trì hoãn. Nếu bạn đang chạy WordPress 7.0.x, hãy cập nhật ngay hôm nay.
Quy trình mình khuyên: backup đầy đủ (Buoc 2), cập nhật qua WP-CLI (Buoc 3), cập nhật plugin và theme (Buoc 4), kiểm tra dấu hiệu bị khai thác (Buoc 5), rồi hardening login screen (Buoc 6). Toàn bộ quá trình mất khoảng 20-30 phút cho một site.
Đặc biệt với site chạy trên cloud (AWS, GCP, Azure), hãy kiểm tra metadata endpoint log và bật IMDSv2. Lỗ hổng SSRF trên cloud có thể dẫn đến cuộc tấn công di chuyển ngang (lateral movement) nguy hiểm hơn nhiều so với việc mất một site WordPress.
Nếu quản lý nhiều site, dùng WP-CLI loop cập nhật hàng loạt. Không có lý do gì để chờ đợi một bản security release quan trọng như vậy.
