Ba lỗi ServiceNow đạt CVSS 10: có thể tấn công trước khi đăng nhập

Ngày 27/8/2026, ServiceNow công bố bản sửa cho bốn lỗ hổng ảnh hưởng Now Platform và ServiceNow AI Platform. Theo phân tích của Cloud Security Alliance, ba lỗi đạt điểm CVSS 10 và có thể bị khai thác khi chưa xác thực; ServiceNow đã cập nhật các instance do hãng lưu trữ, còn môi trường tự lưu trữ hoặc do đối tác quản lý phải áp dụng bản sửa.

Ba lỗi cần ưu tiên là CVE-2026-18885, CVE-2026-18886 và CVE-2026-74820. Báo cáo của CSO xác nhận chúng có thể dẫn tới thực thi mã, tạo hoặc sửa dữ liệu, nâng quyền và thực thi câu lệnh SQL mà không cần tương tác của người dùng; tại thời điểm phát hành cảnh báo, ServiceNow chưa biết trường hợp nào đang bị khai thác.

Ba CVE, ba đường xâm nhập và hậu quả khác nhau

Cùng đạt mức điểm tối đa nhưng ba lỗ hổng không phải các biến thể của một lỗi duy nhất. Chúng đi qua những thành phần khác nhau, vì vậy dấu vết cần tìm sau khi vá cũng khác nhau.

• CVE-2026-18885 — chèn mã trong GraphQL Composite Data API: người chưa xác thực có thể thực thi mã tùy ý, đồng thời truy cập hoặc sửa dữ liệu trong instance. Đây là đường tấn công trực tiếp vào lớp API mà tác nhân AI dùng để đọc và thao tác trên dữ liệu nền tảng.
• CVE-2026-18886 — kiểm soát truy cập không phù hợp: lỗi nằm trong bộ xử lý tải ảnh cấu hình hệ thống. Khai thác thành công có thể cho phép người chưa đăng nhập tạo hoặc thay đổi dữ liệu, rồi nâng đặc quyền trong instance.
• CVE-2026-74820 — SQL injection: đầu vào do kẻ tấn công kiểm soát có thể trở thành câu lệnh SQL chạy trên cơ sở dữ liệu nền, tạo khả năng đọc hoặc chỉnh sửa dữ liệu ngoài luồng nghiệp vụ thông thường.

Đợt công bố còn có CVE-2026-6876, một lỗi thoát sandbox được chấm 8,7. Vector của lỗi này yêu cầu đặc quyền thấp, nên nó không thuộc nhóm ba lỗ hổng trước xác thực đạt CVSS 10 trong tiêu đề.

Nhánh nào bị ảnh hưởng và mốc nào đã sửa

Thông báo CVE tháng 8 của ServiceNow là căn cứ để đối chiếu build thực tế. Các phiên bản đứng trước mốc sửa tương ứng trong từng tuyến phát hành được xem là bị ảnh hưởng:

• Xanadu: Xanadu Patch 11 Hot Fix 7a.
• Yokohama: Yokohama Patch 12 Hot Fix 3b hoặc Patch 13 Hot Fix 4, tùy tuyến đang sử dụng.
• Zurich: Patch 7b Hot Fix 3, Patch 8 Hot Fix 5, Patch 9 Hot Fix 6, Patch 10 Hot Fix 2m với nhánh m hoặc Hot Fix 3 với nhánh chuẩn, Patch 11 và Patch 12.
• Australia: Patch 2 Hot Fix 3, Patch 3 Hot Fix 2, Patch 3m, Patch 4 và Patch 5.

Danh sách này không có nghĩa mọi mốc đều áp dụng đồng thời cho một instance. Quản trị viên phải xác định đúng họ phát hành, tuyến patch và nhánh chuẩn hay nhánh m, sau đó so sánh toàn bộ tên build thay vì chỉ kiểm tra nhãn Xanadu, Yokohama, Zurich hoặc Australia.

Thông báo rằng các instance trên hạ tầng ServiceNow đã được cập nhật không bao phủ môi trường tự lưu trữ hoặc do đối tác vận hành. Với các môi trường đó, trạng thái an toàn cần được xác nhận trên từng production instance, clone, instance dự phòng và hệ thống thử nghiệm còn có thể truy cập từ mạng.

Hậu kiểm dữ liệu, API và danh tính đặc quyền

Cài bản sửa chỉ đóng đường khai thác từ thời điểm cập nhật; thao tác này không chứng minh dữ liệu và quyền hạn trước đó còn nguyên vẹn. Rủi ro đáng chú ý nằm ở vai trò trung tâm của ServiceNow: một instance có thể chứa yêu cầu ITSM, hồ sơ nhân sự, sự cố an toàn, CMDB và dữ liệu phê duyệt, đồng thời gọi hệ thống khác bằng API, token hoặc tài khoản dịch vụ.

1. Lập danh sách toàn bộ instance, ghi lại build đầy đủ, mô hình lưu trữ, thời điểm nhận bản sửa và bằng chứng cập nhật thành công.
2. Rà soát nhật ký trước và sau thời điểm vá để tìm yêu cầu bất thường tới GraphQL Composite Data API, hoạt động tải ảnh cấu hình không dự kiến và lỗi truy vấn có dấu hiệu chèn SQL.
3. Đối chiếu các bản ghi được tạo hoặc sửa với ticket thay đổi, tập trung vào cấu hình, danh tính, vai trò quản trị, dữ liệu nhân sự và hồ sơ sự cố.
4. Kiểm tra hành vi của tài khoản dịch vụ, OAuth token, API key và danh tính tác nhân AI. Nếu telemetry cho thấy truy cập đáng ngờ, cần thu hồi hoặc xoay vòng thông tin xác thực liên quan.
5. Xác minh quyền đọc, ghi và gọi hệ thống hạ nguồn của từng tích hợp. Khi phát hiện dấu hiệu xâm nhập, phạm vi điều tra phải theo các quyền thực tế của danh tính bị ảnh hưởng, không dừng ở riêng instance ServiceNow.

Việc xoay vòng toàn bộ khóa một cách máy móc không thay thế điều tra. Phạm vi xử lý nên dựa trên thời gian phơi nhiễm, endpoint đã truy cập, thay đổi dữ liệu quan sát được và những hệ thống mà tài khoản liên quan thực sự có quyền gọi.

Trạng thái đã biết sau khi phát hành bản vá

Trạng thái được xác nhận là bản sửa đã có, các instance do ServiceNow lưu trữ đã được cập nhật và khách hàng tự quản lý có các mốc build để đối chiếu. Tuyên bố chưa biết trường hợp khai thác chỉ phản ánh thông tin ServiceNow có tại thời điểm công bố ngày 27/8/2026, không phải bằng chứng rằng từng môi trường khách hàng không bị truy cập.

Phần còn chưa rõ là liệu chi tiết khai thác hoặc chỉ dấu xâm nhập đáng tin cậy có được công bố thêm hay không. Cho đến khi có dữ liệu mới, kết luận đối với từng tổ chức phải dựa trên hai bằng chứng riêng: instance đã đạt đúng mốc sửa và telemetry trước khi vá không cho thấy thay đổi bất thường trong API, dữ liệu, quyền hoặc các danh tính kết nối.

Đọc thêm:

• Tấn công mạng làm gián đoạn Boston Scientific: đơn hàng toàn cầu bị ảnh hưởng
• Mở Salesforce cho tác nhân AI: Sai quyền người dùng có thể thành quyền của bot
• Bluesky cho né Discover: bài đăng vẫn công khai nhưng bớt bị lan truyền