CVE-2026-40361 (msrc.microsoft.com/update-gu…), patched today, is a critical 0-click UAF/RCE bug in Microsoft Outlook that I discovered back in Q1. You definitely want to patch this sooner rather than later. The danger of such 0-click bugs in Outlook is that they are triggered as soon as the victim reads or previews the email - no clicking of links or attachments is required. Since the bugs reside in Outlook's email rendering engine, it is difficult to mitigate or block (though specifically setting Outlook to render emails only in plain text format is a valid mitigation). Fun fact about the discovery: after the discovery of the #BadWinmail bug a decade ago, I wanted to run an experiment in Q1 to see if I could find another 0-click RCE in Outlook. The result? It wasn't easy — I even built a dedicated system for it — but I eventually found this one. :) To understand why such bugs are so critical, check out the #BadWinmail video demo I released a decade ago: youtube.com/watch?v=ngWVbcLD…. They share the same attack vector (though #BadWinmail was a working exploit, while this one was a PoC). Essentially, anyone could compromise a CEO or CFO just by sending an email. The threat perfectly bypasses enterprise firewalls and is delivered directly to the inbox. Furthermore, note that Outlook (Classic) lacks an application sandbox, making this attack vector even more dangerous. Regarding defense and detection: if you are concerned about Outlook 0-click 0-days, my EXPMON system (pub.expmon.com) provides cutting-edge detection against such advanced threats. When I designed the original system in 2020/2021, I developed this functionality specifically considering the impact of #BadWinmail. The system accepts .eml or .msg formats, and email samples are deeply tested within an Outlook sandbox. For enterprise users, emails can be "dumped" from the mail server, and EXPMON can be deployed in a private network. Contact me for more details. P.S. I just noted that the title of the Microsoft Security Update (msrc.microsoft.com/update-gu…) lists this as a Microsoft Word bug, which may or may not be entirely accurate. I demonstrated this bug to MSRC by showing that it works in a real, live Outlook Exchange Server environment. My bet is that because the bug resides in wwlib.dll — a shared DLL used heavily by both Outlook and Word — it likely affects both Outlook (via email) and Word (via a document file). Regardless of the title, it is a genuine Outlook 0-click RCE. #CVE-2026-40361 #PatchTuesday #Outlook #0click #EmailSecurity #EnterpriseSecurity #expmon #ThreatIntel #ExploitDetection

Whoa! This does seem to be a variant if you look at the Relations on VT, and this sample appeared on VT since 2025-11-28, (if confirmed) showing how long this advanced zero-day attack campaign has been ongoing! However, I don't have a VT account, could someone share the sample w/ me or just submit it to pub.expmon.com ? Thanks! x.com/greglesnewich/status/2…

Also, the original sample you found has a PCAP on VT that gets a cipher text payload but not the key :( Uploaded traffic here: gist.github.com/g-les/05f6ed…

Great work! Maybe a related sample for ya: virustotal.com/gui/file/5407…

A "wild" submission on EXPMON! On January 17, a suspicious RTF sample was submitted to EXPMON (pub.expmon.com). pub.expmon.com/analysis/3112… While the EXPMON system didn't immediately flag it as "Malicious", it reported multiple highly suspicious Indicators — such as the "suspicious process started from users folder", and the "suspicious process created by main". These Indicators allowed me (and other researchers) to quickly zero in on and investigate the sample. Upon analysis, I've confirmed that it triggered an unpatched crash on the latest version of WPS Office. Since I found no suspicious payload within the sample, I reported it as a potential vulnerability via the ZDI program. Thanks to the ZDI researchers, it was confirmed last week that the crash is technically non-exploitable. Therefore, I am now disclosing the full details. The sample is available for download here (password: "infected"): drive.google.com/file/d/1zBr…, so other researchers can investigate this interesting crash. The crash looks like the following attached picture shows. This case once again demonstrates EXPMON's capabilities — not only in detecting in-the-wild zero-day exploits but also in identifying minor suspicious behaviors from an exploit/vulnerability perspective. I have also updated the Detection Logic for WPS to ensure immediate reporting when a suspicious WPS application crash is detected. You can view the re-submission of the sample here: pub.expmon.com/analysis/3149…. Some interesting points regarding this submission.. 1. This is the first WPS crash that EXPMON detected since EXPMON covered the WPS Office software in January (justhaifei1.blogspot.com/202…). 2. This is not a normal sample, but a manmade/crafted one, a crash PoC. 3. While this is probably not exploitable, it still looks ugly (an integer overflow?). If you're the vendor (WPS), you may want to patch it. 4. No idea who submitted this, and EXPMON does not track any submitter information. And, yeah, I noted the string message in the sample.. Anyway, thanks for testing EXPMON, I guess.. #expmon #zeroday #0day #wps #threatintel

Someone submitted the real CVE-2026-21509 sample to EXPMON last night! Check out this submission: pub.expmon.com/analysis/3116… The SHA256 of the sample, it's a RTF file: c91183175ce77360006f964841eb4048cf37cb82103f2573e262927be4c7607f While EXPMON didn't report the 0day immediately - this is well expected, it reported various highly suspicious Indicators, including the key Indicator named "activex compatibility shellexplorer registry key accessed". I shared how to use this key Indicator on EXPMON to hunt the 0day just days ago: x.com/HaifeiLi/status/201634…. That's enough to investigate it manually in your local env, and I have just confirmed this is indeed the CVE-2026-21509 zero-day exploit! My quick analysis showed that this is the initial attack vector sample in a full attacking chain. Thanks to EXPMON logs, I quickly found that the RTF file was trying to load the IE engine (the "ieframe.dll") while also trying to connect to the threat actor controlled server, one of the url is "\\wellnesscaremed[.]com\davwwwroot\venezia\Favorites\blank.doc" (see the pic attached) - all activities are automatic, meaning as soon as the victim open the Word document, the victim could be pwned. There're not just one but quite serveral OLE objects in the RTF which are, to be honest, quite sophisticated, showing the sophistication of the zero-day attack. Full details haven't been fully understood in such a short time. The same sample was also listed/confirmed by the Ukrainian CERT cert.gov.ua/article/6287250 independently, there're more details in that article please go check out. What a wild story! Thank you very much to the person who submitted the sample (and I received your message about adding the "unzip" feature:))! Once again it confirmed the effectiveness of the EXPMON system when it comes to detecting unknown 0day exploits. Quickly, for defenders: 1. Please research all the things starting from the sample, this is the confirmed CVE-2026-21509 0day intinal attack vector sample, and add detections (currently the detection ratio on VT is pretty low) in the full chain. 2. If you're an Microsoft Office user, please apply Microsoft's official patch or workarounds ASAP msrc.microsoft.com/update-gu…, as now the attacking exploit is well known so attacks are expected to increase rapidly. For me, there's more work to do, including an EXPMON update for determinate detection against this 0day exploits. In the meantime, if you see the "activex compatibility shellexplorer registry key accessed" Indicator on EXPMON, please be cautions because that's likely the 0day sample/variants. #CVE-2026-21509 #expmon #0day #zeroday #exploit #threatintel

A quick update for hunting the CVE-2026-21509 0day sample.. Weird (and good) stuff! - my EXPMON system has an existing Indicator Logic specifically detecting "shellexplorer" (the same {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}, "shellexplorer" is the progid name) OLE/COM/ActiveX object, which is the key to look for potential CVE-2026-21509 0day! And I have forgotten why I wrote that detection logic in the first place, really..😅 But anyway, if you spot a sample which was detected with such an Indicator on @EXPMON_ , then it could be a very good candidate! See this example pub.expmon.com/analysis/3115…, the Indicator's name is "activex compatibility shellexplorer registry key accessed". Please note that even the sample is not detected ("Undetected"), as long as it's detected w/ such Indicator, it could still be the 0day. You then test in an unpatched env to see what's going on. Please note that you should not connect your testing VM to the Internet because once you connect to the Internet Office will get patched automatically with some server-side configuration which is already deployed according to Microsoft's advisory. Or, you can let me know your submission, I have a VM ready for testing. Happy hunting! :)