Với định danh CVE-2020-17008, lỗ hổng bảo mật mới này đã được báo cáo cho Microsoft vào ngày 24/9/2020. Theo chính sách của Project Zero, các chi tiết về lỗ hổng sẽ được công khai 90 ngày sau đó, tức là vào cuối năm 2020, mặc dù Microsoft đã bỏ lỡ thời hạn vá lỗi.

Lỗ hổng trước đó có định danh CVE-2020-0986, được tiết lộ vào tháng 5/2020. Lỗ hổng này ban đầu được báo cáo cho Microsoft vào tháng 12/2019 và bản vá được phát hành vào tháng 6/2020. Các cuộc tấn công nhắm vào lỗ hổng bảo mật này đã xuất hiện vài ngày sau khi nó được tiết lộ.

Vào tháng 8/2020, công ty bảo mật Kaspersky đã công bố thông tin về các cuộc tấn công sử dụng lỗ hổng CVE-2020-0986 với một lỗ hổng zero-day trong trình duyệt Internet Explorer, như một phần của chiến dịch tấn công được gọi là Operation PowerFall.

Kaspersky giải thích trong một bài viết hồi tháng 9/2020, bằng cách sử dụng lỗ hổng này, tin tặc có thể thao túng bộ nhớ của tiến trình splwow64.exe để thực thi mã tùy ý trong tiến trình và thoát khỏi hộp cát (sandbox) của trình duyệt Internet Explorer 11 vì splwow64.exe đang thực thi với mức toàn vẹn trung bình.

Cũng là một lỗ hổng leo thang đặc quyền trong splwow64.exe, lỗ hổng CVE-2020-17008 có thể bị lạm dụng đơn giản bằng cách thay đổi phương pháp khai thác CVE-2020-0986, một lỗ hổng tham chiếu con trỏ tùy ý ảnh hưởng đến API của GDI Print/Print Spooler.

Nhà nghiên cứu Maddie Stone thuộc nhóm bảo mật Project Zero của Google giải thích rằng, lỗ hổng CVE-2020-17008 thực sự gần giống với CVE-2020-0986, điểm khác biệt duy nhất là đối với CVE-2020-0986, tin tặc đã gửi một con trỏ và với CVE-2020-17008 là một offset.

Trên Twitter, bà Stone lưu ý rằng bản sửa lỗi của Microsoft là không đúng vì nó chỉ đơn giản là thay đổi các con trỏ thành các offset, không ngăn được kẻ tấn công kiểm soát “các hàm args và memcpy”.

Nhà nghiên cứu cũng công bố mã nguồn bằng chứng khái niệm (PoC) nhắm tới lỗ hổng CVE-2020-17008, lưu ý rằng cách khai thác này được tham khảo từ PoC mà Kaspersky phát hành cho CVE-2020-0986.

Bà Stone cho hay, lỗ hổng trong hàm memcpy bị kích hoạt hai lần: đầu tiên là để rò rỉ địa chỉ heap nơi lưu trữ thông điệp và phần offset được thêm vào để tạo ra các con trỏ và sau đó là thực thi mã ở nơi chỉ định.

Microsoft đã ghi nhận lỗ hổng này một ngày sau khi nhận được báo cáo về nó và từng lên kế hoạch phát hành bản vá vào tháng 11/2020, nhưng đã hoãn do các vấn đề được phát hiện trong quá trình thử nghiệm. Microsoft cũng đã đặt mục tiêu giải quyết lỗ hổng này vào tháng 01/2021.