CVE-2026-21509 | MS Office | SFB
| Field | Details |
|---|---|
| Vulnerability | CVE-2026-21509 |
| Type | Microsoft Office Security Feature Bypass. NVD describes it as “reliance on untrusted inputs in a security decision” and maps it to CWE-807. |
| Severity | CVSS v3.1: 7.8 (High) with vector AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. This means exploitation still needs a user to open a crafted file, but no privileges are required beforehand. |
| Exploitation Status | Microsoft published an advisory and patch on January 26, 2026, and the Decalage write-up states the issue was already exploited in the wild at disclosure time. CISA also added CVE-2026-21509 to its Known Exploited Vulnerabilities catalog the same day. |
| Root Cause / Core Primitive | The technical pivot identified by the detection repo and Decalage analysis is the COM class Shell.Explorer.1, whose CLSID is {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}. This object can instantiate the legacy Internet Explorer / Trident / MSHTML engine from an Office document. |
| Observed Exploit Structure | According to the Decalage analysis, the known malicious samples were normal RTF documents containing Shell.Explorer.1 OLE objects configured with a URL. When the document is opened, Word instantiates the OLE object, which loads the legacy IE engine to open that URL. |
| Payload Delivery Behavior | The Decalage analysis says the discovered malicious samples used URLs that pointed to LNK files, and those LNK files were automatically executed without prompting the user, enabling the next-stage payload to run. The write-up characterizes this as a bypass of Office security controls that should have blocked insecure file downloads or execution paths. |
| Document Traits in Known Samples | The Decalage write-up states that the known in-the-wild samples it examined were RTF files containing Shell.Explorer.1 OLE objects, and that these samples could all be detected by the repo’s detection logic. The repo README also says its YARA rule detects all samples uploaded to MalwareBazaar under the CVE-2026-21509 tag. |
| Key Detection Indicator | In RTF, the Shell.Explorer.1 CLSID appears hex-encoded as C32AB2EAC130CF11A7EB0000C05BAE0B. The Decalage write-up says this encoding is stable enough in RTF to support YARA detection. |
| YARA Rule Logic | The main YARA rule, SUSP_RTF_with_potential_CVE_2026_21509_exploit, requires three conditions: RTF header at offset 0 ({\rt), presence of \objdata, and the hex-encoded CLSID for Shell.Explorer.1. This is a very targeted signature for RTF-based exploit documents. |
| OpenXML Detection Logic | For OpenXML files, the script: 1) identifies files via ftguess, 2) iterates zip parts, 3) looks for parts whose name contains oleObject, 4) opens those embedded OLE objects and reads the root CLSID, 5) scans XML parts for the raw CLSID string, and 6) enumerates external relationships with oleobj.find_external_relationships, flagging non-HTTP targets as worth checking. That last check was inspired by earlier Office exploitation patterns such as mhtml:-style relationships in CVE-2021-40444. |
| OLE / CFB Detection Logic | For legacy OLE/CFB files, the script enumerates streams and storages with ole.listdir(...), pulls CLSIDs via ole.getclsid(part), and flags any object whose CLSID matches EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B. |
| RTF Detection Logic | For RTF files, the script parses objects with rtfobj.RtfObjParser, then prints object offset, class name, and CLSID for OLE objects. Any object matching the Shell.Explorer.1 CLSID is flagged as potentially related to CVE-2026-21509. |
| Detection Confidence / False Positives | Both the repo README and the Decalage write-up say there is no good reason for a legitimate document to embed Shell.Explorer.1, because that object is used to embed the Internet Explorer engine into another application. The author therefore expects very few false positives, especially for the RTF YARA rules. |
| Detection Limitations | The Decalage write-up explicitly notes that standard YARA cannot decompress ZIP-based OpenXML files before string matching, so a pure YARA approach is not enough for DOCX/XLSX/PPTX. That is why the repo combines YARA for RTF with a Python parser-based detector for OpenXML, OLE/CFB, and RTF. |
| Impact | Officially, Microsoft/NVD class this as a security feature bypass rather than direct RCE. In practice, the Decalage analysis shows the bypass can be used to make Office instantiate legacy browsing functionality and retrieve attacker-controlled content, which in the observed campaign led to automatic LNK execution and follow-on payload delivery. |
| Mitigation / Patching | Microsoft released patches on January 26, 2026. A Microsoft support article confirms at least Office 2016 received a dedicated security update for this vulnerability. The Decalage write-up also notes that Microsoft initially documented a mitigation involving the CLSID key {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}, which aligns with the technical indicator used in the detection content. |
| Useful Detection Artefacts | High-value hunting artefacts from the linked materials are: Shell.Explorer.1, CLSID {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}, RTF hex form C32AB2EAC130CF11A7EB0000C05BAE0B, \objdata in RTF, embedded OLE object parts named like oleObject, and suspicious external relationships whose target does not start with http. |
| Sources | - https://decalage.info/CVE-2026-21509/ - https://github.com/decalage2/detect_CVE-2026-21509 - https://raw.githubusercontent.com/decalage2/detect_CVE-2026-21509/main/CVE-2026-21509_RTF.yar - https://raw.githubusercontent.com/decalage2/detect_CVE-2026-21509/main/CVE-2026-21509_RTF_nows.yar - https://raw.githubusercontent.com/decalage2/detect_CVE-2026-21509/main/olecheck.py - https://nvd.nist.gov/vuln/detail/CVE-2026-21509 |