TL;DR: If you are looking for the YARA rule to detect CVE-2026-21509, jump to the YARA section below.
A new 0-day vulnerability in MS Office
On the 26th January 2026, Microsoft published an advisory and a patch for a new vulnerability in MS Office, already exploited in the wild: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-21509
At the time, no technical details were provided except that the vulnerability can be exploited using MS Office documents, and that it can be mitigated by setting a specific key named {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B} in the registry.
How the exploit could look like
In the following days, I was looking how the exploit for this new vulnerability could look like, in order to detect it.
It turns out that EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B is a specific CLSID (class id), corresponding to the Shell.Explorer.1 COM object, which can be used to open the legacy Internet Explorer engine (aka Trident/MSHTML) from any application.
This type of object was already mentioned in an article from 2018 by Yorick Koster as a way to download and execute malicious files from a document.
So to exploit CVE-2026-21509 from MS Office files, I figured that one could either embed an OLE object of type Shell.Explorer.1 into a MS Office document, or insert an external relationship with a special URL that would trigger the use of the Internet Explorer engine, as it was the case for CVE-2021-40444 with “mhtml:” URLs.
To start hunting for potential exploits, I built a script using oletools which tries to identify both cases: OLE objects with that specific CLSID, or external relationships with special URLs that do not start with “http”. It works with most types of MS Office files: OpenXML, OLE/CFB and RTF: https://gist.github.com/decalage2/26b6
Important: this script can be used to hunt and analyse suspicious files in an attempt to identify CVE-2026-21509 samples, but it is by no means a foolproof detection method as it may catch other documents not related to the vulnerability.
Also note that it is not possible to do exactly the same thing just with YARA rules at least for OpenXML documents (docx, xlsx, pptx), because the standard YARA engine cannot decompress files from a zip archive before searching for strings. You would need an additional tool to decompress files and then use YARA rules. However, it would be possible to write a YARA rule to detect legacy OLE/CFB documents (doc, xls, ppt) or RTF files containing Shell.Explorer OLE objects.
Note: to test the script, I used Yorick Koster’s PoC from 2018 to build MS Office files containing Shell.Explorer.1 objects: https://gist.github.com/securifybv/9e085c93b330441576c883193166fcbe - The PoC creates a DOCX file, which can be easily converted to DOC and RTF formats.
Malicious samples in the wild
Samples which look like exploits for the recent MS Office vulnerability CVE-2026-21509 have been detected by CERT-UA and published today on MalwareBazaar. It turns out they can be detected by the olecheck tool I had released this week, and the last version of oletools: see below
The olecheck script shows that the samples are RTF documents containing “Shell.Explorer” OLE objects. For now the script is available here: https://gist.github.com/decalage2/26b6
