Microsoft says 1,094 CVEs in November, its file held 1,342 entries, now 1,362; the one exploited flaw is rated Moderate
Microsoft's release notes say 1,094 CVEs, its CVRF file held 1,342 entries at first read and holds 1,362 now, and three outlets print 1,235, 1,094 and 1,093. The one flaw flagged exploited, an Outlook NTLMv2 hash leak, is the only Moderate among 1,093 Microsoft assigned entries (derived).
By Parminder Kumar Sharma · LinkedIn · · 21 min read
Update, 11 November 2026: Microsoft's file now holds 1,362 entries, 20 more than this article counted
This article counted Microsoft's machine readable file for the November release at revision 167, whose last revision is dated 10 November at 08:00 in the file, as it was served on the morning of 11 November. Read again later that morning, the same address serves revision 192, whose last revision is dated 11 November at 01:07 in the file. It holds 1,362 entries, each with its own CVE id (derived): 20 more than the 1,342 counted here.
What the 20 are. None is assigned by Microsoft. By the assigning authority printed in the file they come from VulnCheck (9), Red Hat (6), PSF (2), EEF (1), OpenJS (1) and GitHub (1). Eighteen have a first revision dated 11 November between 01:01 and 01:07, and two have one dated 10 November at 14:44 and 14:45. Three entries already in the file also gained a revision, with no change to their severity, impact or assigning authority (derived).
What did not change. Microsoft's release notes still read "This release consists of 1094 Microsoft CVEs". The entries Microsoft assigned and first published on 10 November are still 1,093: 63 Critical, 1,029 Important and 1 Moderate, the Outlook entry that is flagged exploited (derived). The entries with a first revision dated 4 to 9 November are still 248. The count of Microsoft assigned entries in the whole file is unchanged.
What did change. The total of the file, and one reproduction in this article. At revision 167, 1,094 was exactly the number of entries first dated 10 November. At revision 192 that number is 1,096, because two of the new entries are dated 10 November, so that rule no longer gives Microsoft's figure and this article does not claim it does. BleepingComputer's stated rule, excluding 108 entries, gives 1,234 at revision 167 and 1,254 at revision 192 (derived); its printed 1,235 was published on 10 November, and which revision it counted is not stated.
Why it matters. A count of the file is a count at a revision. Microsoft revises the file after the Tuesday, and the entries that arrive late are the third party ones, so a total that includes them moves while the figure for Microsoft's own entries stays put. Say which revision you counted.
What changed in this article: the headline, standfirst, excerpt and search description, a table cell, a paragraph and a column heading on severity totals, two key facts and a checklist item now say which revision they count. The figures drawn into the hero image and the count diagram are as read at revision 167. A dataset built from revision 192 is on the Patch Tuesday browser.
1,094 CVEs, 1,342 entries, and one Moderate
Microsoft's release notes for 10 November 2026 say the release "consists of 1094 Microsoft CVEs". The machine readable file for the same release, the CVRF at revision 167, holds 1,342 entries, and each has its own CVE id (derived). BleepingComputer prints 1,235, SecurityWeek 1,094 and Krebs on Security 1,093. Each figure reproduces from a counting rule applied to Microsoft's file except one: BleepingComputer's stated rule gives 1,234 (derived), one fewer than it prints.
The second fact sits inside the first. Of the 1,093 entries that Microsoft assigned itself and first published on 10 November, 63 are Critical, 1,029 are Important, and exactly one is Moderate. That one is CVE-2026-124194, the Outlook flaw that Microsoft's own data flags as exploited (derived). A queue sorted by Microsoft's label puts it last of 1,093.
What this does not establish. It does not show that any outlet is wrong: each counted something real, and the CVRF prints no total of its own. It does not show that Moderate is a mistake, because the file prints no rule for its labels. It says nothing about who is exploiting the flaw, against whom, or since when: neither Microsoft nor CISA states it.
Read between 06:47 to 07:05 UTC on 11 November 2026: Microsoft's CVRF (revision 167, release date 2026-11-10T08:00:00 in the file, which gives no time zone), the CVE record, the National Vulnerability Database entry, CISA's Known Exploited Vulnerabilities catalogue (release 2026.11.10) and Microsoft's Office release notes page, plus the three outlets' own pages. Figures marked derived are this site's arithmetic on those files; the script and its output are kept with the factcheck file. Microsoft sells the Office, Microsoft 365 and Windows products these updates cover, and the severity labels and exploited flags are its own assessments.
Who counted what, and the rule that reproduces each figure
The table gives each total, what its publisher says it covers, and the rule that reproduces it from Microsoft's file. Only BleepingComputer states a rule; Microsoft's table and the other two do not, so the rules for them are this site's reconstruction, and they are labelled derived. The test for a rule is whether it gives the printed figure exactly.
Totals for the November 2026 release, what each covers, and the rule that reproduces it. Read 11 November 2026; rules are derived unless the source states them.
| Source and figure | What the source says it counts | Rule that reproduces it (derived) | What it leaves out |
|---|---|---|---|
| Microsoft CVRF file, revision 167: 1,342 entries | No total printed; one entry per CVE id | Every entry; 1,342 distinct CVE ids | Nothing; includes 248 entries first dated 4 to 9 November |
| Microsoft release notes: 1,094 | "This release consists of 1094 Microsoft CVEs"; table rows add to 1,094 | Entries whose first revision is dated 10 November: 1,094. One of them is assigned by VulDB, not Microsoft | The 248 earlier entries; the notes separately say 165 non-Microsoft CVEs are republished, Chrome not listed |
| SecurityWeek: 1,094 | Microsoft's figure; also says Microsoft republished 165 third party CVEs | Same as the release notes | The same 248 |
| Krebs on Security: 1,093 | No rule stated | The 10 November entries assigned by Microsoft: 1,093 | The one VulDB assigned entry, and the 248 |
| BleepingComputer: 1,235 | "we only count vulnerabilities released by Microsoft on Patch Tuesday itself"; excludes 108: 1 Entra, 82 Mariner, 25 Edge | 1,342 less 108 is 1,234, one fewer than printed. The file has 1 Entra entry, 82 Mariner family entries and 25 Edge entries dated 4 November | The 108. It keeps 141 Edge entries that the file dates 5 November |
Three points about that table. First, Microsoft's 1,094 is not the number of entries in its own file, because 248 entries, 18.5 per cent (derived), carry an earlier first revision date. The notes also say 165 non-Microsoft CVEs are republished, and the file's Edge entries assigned by Chrome number exactly 165 (derived), all dated 4 or 5 November. Second, the one VulDB assigned entry among the 1,094 is a third party component rated Moderate, so "Microsoft CVEs" is not quite what the heading says: the Microsoft assigned set is 1,093, which is Krebs's figure. Third, BleepingComputer's own exclusion list matches the file's groups exactly, and so does its 66 Critical: the file has 68, less the Chromium memory corruption entry dated 4 November and the Entra entry (derived). The single unexplained entry is in its total, and its Edge row prints 142 where the file gives 141 entries dated 5 November (derived).
Entries in the CVRF by the date of their first revision (revision 1.0), counted by this site. The release is dated 10 November.
| First revision dated | Entries | Assigned by Chrome (Edge) | In the Mariner family |
|---|---|---|---|
| 4 November 2026 | 55 | 24 | 30 |
| 5 November 2026 | 154 | 141 | 12 |
| 7 to 9 November 2026 | 39 | 0 | 39 |
| 10 November 2026 | 1,094 | 0 | 1 |
Other counts agree with the file only loosely. BleepingComputer calls its category figures approximate: it prints 536 elevation of privilege, 296 remote code execution and 157 information disclosure, where the file's impact rows give 535, 297 and 157 across all 1,342 entries (derived). Krebs prints 535 elevation of privilege flaws beside a total of 1,093, but 535 is the figure for all 1,342 entries; the 1,093 set has 534 (derived). Neither difference matters for patching, and both show how easily one count drifts into another.
The label ladder: 63 Critical, 1,029 Important, one Moderate
Microsoft's file gives every entry a severity label. Across all 1,342 entries at revision 167 the split is 68 Critical, 1,117 Important, 110 Moderate and 47 Low (derived). That split mixes Microsoft's own entries with third party ones, such as the Chromium entries Microsoft republishes for Edge, which carry their own ratings. Restricted to the 1,093 entries Microsoft assigned and first published on 10 November, the ladder is far steeper, and Moderate appears once.
Severity labels in the CVRF: all entries against the 1,093 Microsoft assigned entries first published on 10 November, and how many carry the Exploited:Yes flag. Counted by this site.
| Label | All 1,342 entries (revision 167) | Microsoft assigned, 10 November (1,093) | Flagged Exploited:Yes |
|---|---|---|---|
| Critical | 68 | 63 | 0 |
| Important | 1,117 | 1,029 | 0 |
| Moderate | 110 | 1 | 1 |
| Low | 47 | 0 | 0 |
So the one entry in Microsoft's own data flagged exploited is also the only Moderate among Microsoft's 1,093 (derived). In a list sorted by label it sits at position 1,093. In a list sorted by CVSS base score it is also in the lower part: 860 of the 1,084 Microsoft assigned entries with a base score have a higher one than its 6.5, and 59 share it (derived). The label does not follow the base score alone. Microsoft's Important covers base scores from 3.3 to 9.9 in this set, and 164 Important entries score below 6.5 (derived). Thirty entries share the Outlook flaw's exact base vector; the other 29 are all Important (derived). The file prints no rule that explains the difference, and this site did not read Microsoft's severity documentation for this brief, so it does not say why.
Microsoft's file carries a second field that does track exploitation. Each entry has a flags string, and for the Outlook flaw it marks Exploited as Yes and Publicly Disclosed as No, with the exploitability value Exploitation Detected (the exact string is under Technical details). Among the 1,093, that exploitability value appears once; Exploitation More Likely appears 42 times, on 5 Critical and 37 Important entries; Exploitation Less Likely 978; Exploitation Unlikely 58; and 14 read N/A (derived). A queue sorted on that field would have put the Outlook flaw first. A queue sorted on the label put it last. Both fields are Microsoft's.
Krebs's 63 Critical and BleepingComputer's 66 are both right for what they counted: 63 is the 10 November set, and 66 adds the three Chromium use after free entries the file dates 5 November (derived). The file's own 68 adds two more. Krebs says "nearly half" of the Critical flaws are remote code execution; in the file 48 of those 63 carry that impact, 76 per cent (derived), and BleepingComputer's text says 48 of its 66. BleepingComputer and the file agree on 48; Krebs's sentence does not fit either.
The Outlook flaw as Microsoft's file and the CVE record print it
CVE-2026-124194 is titled "Microsoft Outlook Spoofing Vulnerability" by Microsoft. The weakness is CWE-356, Product UI does not Warn User of Unsafe Actions. Microsoft's FAQ says an unauthenticated attacker could send a specially crafted message file and convince a user to open it; opening it could make Outlook connect to an attacker-controlled network location without the usual external-content warning, potentially disclosing authentication information. Microsoft adds that it discloses the user's NTLMv2 hash, which the attacker could use to authenticate as the user. The Preview Pane is not a vector, and the CVSS metrics require user interaction.
CVE-2026-124194 as printed in Microsoft's CVRF (revision 167), the CVE record and the NVD entry, read 11 November 2026.
| Field | What is printed | Where |
|---|---|---|
| Title and impact | Microsoft Outlook Spoofing Vulnerability; impact row Spoofing; severity Moderate | CVRF |
| Weakness | CWE-356: Product UI does not Warn User of Unsafe Actions | CVRF, CVE record |
| CVSS 3.1, assigned by Microsoft | Base 6.5, temporal 6.2; confidentiality High, integrity and availability None, no privileges, user interaction required, exploit code maturity High | CVRF, CVE record; NVD lists only Microsoft's base vector, as a Secondary source |
| Flags | Publicly Disclosed:No; Exploited:Yes; Exploitation Detected; Customer Action Required: Yes | CVRF |
| Products | Microsoft Office LTSC 2021, Office LTSC 2024 and Microsoft 365 Apps for Enterprise, each in 32 bit and 64 bit rows (six rows) | CVRF |
| Fixed builds | 16.0.14334.21048 (LTSC 2021), 16.0.17932.21140 (LTSC 2024); for Microsoft 365 Apps the CVRF gives a link to Microsoft's Office security releases page, not a build | CVRF, CVE record |
| Credit | Two lines. One names a reporter handle; the other says the reporter used an AI model, Claude, with Anthropic | CVRF |
| CISA's name for it | Microsoft Office Outlook Missing User Interaction for Potentially Unsafe Action Vulnerability, product Office | KEV |
Two notes on that table. The credit line that names an AI model is printed as Microsoft prints it; the file does not say what the model did, and it does not say who found the in-the-wild use. The file also does not say whether any other Office app, or the Preview Pane in another product, is involved.
Microsoft's Office release notes page lists a block for 10 November 2026 with the builds in the table below, and under Outlook it lists CVE-2026-124194. The page lists CVEs per release block, not per channel, so it does not by itself show that every listed build contains this fix, and it lists Office 2019 although the CVRF lists no Office 2019 product for this CVE. Where a Microsoft 365 Apps build lacks the fix is therefore a question for the inventory of the organisation, not for these pages.
Dates attached to CVE-2026-124194, as printed. Elapsed times are derived. Times are UTC where the source gives a zone.
| Event | Date and time | Source |
|---|---|---|
| CVE id reserved | 6 November 2026, 22:09 UTC | CVE record |
| CISA SSVC assessment stamp: Exploitation active, Automatable no, Technical Impact partial | 9 November 2026, 00:00 UTC, 40 hours before Microsoft's public date (derived) | CVE record, CISA data |
| CVRF revision 1.0 | 10 November 2026, 08:00:00, no time zone given | CVRF |
| Microsoft public date | 10 November 2026, 16:00 UTC | CVE record |
| CVE record published | 10 November 2026, 18:22 UTC | CVE record |
| CISA catalogue release 2026.11.10, which lists it | 10 November 2026, 19:03:29 UTC, 3 hours 3 minutes after the public date (derived) | KEV |
| KEV date added and due date | Added 10 November 2026; due 24 November 2026, 14 days later (derived) | KEV |
| NVD entry published | 10 November 2026, 19:20 (no zone printed) | NVD |
The SSVC stamp is a field date on CISA's assessment. It is earlier than the CVE record's public date, the record does not explain why, and a stamp does not say when CISA first knew of exploitation. CISA's catalogue also prints known ransomware campaign use as Unknown and forensic triage as No, and gives no actor, victim count or start date, and neither does Microsoft. Microsoft's file says exploitation was detected before release; it does not say how, by whom or how often.
Friendly labels doing the work of a control
Three labels in this release carry more weight than the facts under them. "Moderate" reads as a flaw to schedule, and Microsoft used it once for its own 1,093 entries, on the flaw already used in attacks. "Spoofing" is the impact row, while the CVSS vector says confidentiality is the loss and nothing is changed; the harm in the FAQ is a hash an attacker could use to authenticate as the user. "Zero-day" is BleepingComputer's and SecurityWeek's word, and BleepingComputer writes that Microsoft classifies a zero-day as publicly disclosed or actively exploited when no official fix is available. The CVRF prints neither the word nor that definition, and it lists fixed builds for this flaw at release (the earlier brief on October's release, linked below, made the same point about fix information).
The same file shows the hash leak is not unique to Outlook. NTLM appears in the notes of four entries (derived search of the note text). The one used in attacks has the lowest label of the four, and the one for Windows describes the attacker's next step, relay, in its FAQ: "which an attacker can then relay to another service and authenticate as the victim". That sentence is about CVE-2026-121680, not about the Outlook flaw, and it describes a capability, not observed use. The file does not say whether the Windows NTLM update changes the Outlook path.
The four CVRF entries whose notes mention NTLM hashes. Label, base score and exploitability value are Microsoft's, as printed.
| Entry | Label and CVSS base (temporal) | Exploitability value |
|---|---|---|
| CVE-2026-124194, Outlook Spoofing, UI required | Moderate, 6.5 (6.2) | Exploitation Detected |
| CVE-2026-121680, Windows NTLM Spoofing, no user interaction | Important, 7.5 (6.5) | Exploitation Less Likely |
| CVE-2026-119976, Visual Studio Code pull requests extension, information disclosure, UI required | Important, 6.5 (5.7) | Exploitation Less Likely |
| CVE-2026-119905, Windows DNS Spoofing, privileges required | Important, 4.9 (4.3) | Exploitation Less Likely |
This does not show those three are mislabelled. It shows the label is not the evidence: what separates the Outlook flaw is a flag that says it was used. This site reported on October's release in the same way, where one flagged CVE sat among seven different totals: Microsoft's October Patch Tuesday has seven totals.
What Microsoft and CISA state, and what they do not
Stated and not stated for CVE-2026-124194 and the release, from Microsoft's CVRF, the CVE record, NVD and CISA's catalogue, read 11 November 2026.
| Question | Stated | Not stated |
|---|---|---|
| Is it exploited? | CVRF: Exploited:Yes, Exploitation Detected. CISA: in the catalogue from 10 November; SSVC Exploitation active | Who, how many targets, since when, how it was detected |
| How does it work? | A crafted message file the user opens; Outlook connects out without the usual external-content warning; NTLMv2 hash disclosed | How the file is delivered beyond "send"; whether any other app or protocol is involved |
| What can the hash do? | "to authenticate as the user" | Whether captured hashes were relayed or cracked in the wild. CISA: known ransomware use Unknown |
| Which products? | Six rows: Office LTSC 2021, Office LTSC 2024 and Microsoft 365 Apps for Enterprise, 32 and 64 bit | Office 2019 and Office 2021 or 2024 retail builds are not listed for this CVE, and the file does not say they are unaffected |
| What is the fix? | LTSC builds 16.0.14334.21048 and 16.0.17932.21140; Microsoft 365 Apps by channel build on Microsoft's Office release notes page | A per channel statement that each build contains this fix; a count of exposed devices |
| Is AI behind the volume? | Krebs says Microsoft credits advances in artificial intelligence; BleepingComputer says Microsoft continues to use AI. The CVRF names an AI vendor or tool in the credit lines of six entries (derived) | Any statement in the CVRF release notes that AI contributed to the count, or how |
| What is the total? | Release notes: 1094 Microsoft CVEs; 165 non-Microsoft CVEs republished | A total for the file; a reason for the 1,342 |
Where the sources differ
Differences between sources, kept as differences. Pages read 11 November 2026; each outlet's date is from its own page data.
| Point | One source | Another source |
|---|---|---|
| Is November a record? | BleepingComputer (page data 10 Nov, 14:07 ET): "record-breaking 1,235 flaws", and in the same article calls October's 1,411 "record-breaking" | SecurityWeek (page data 10 Nov, 19:19 UTC): "The November release is smaller than October's", a record 1,413. Krebs (10 Nov): last month more than 1,400. The file's 1,342 is below October's 1,758 CVE ids, which the earlier brief derived |
| Critical flaws that are remote code execution | Krebs: "Nearly half" | CVRF: 48 of 63 (76 per cent, derived); BleepingComputer: 48 of 66 |
| Elevation of privilege count | Krebs: 535, beside a total of 1,093 | CVRF: 535 across all 1,342 entries, 534 in the 1,093 set (derived) |
| KEV additions this year | Krebs quotes an Ivanti executive: only 217 added so far this year | The saved CISA catalogue has 295 entries with a 2026 date added (derived); the quote does not say what it counts |
| Name of the flaw | Microsoft: Microsoft Outlook Spoofing Vulnerability; BleepingComputer: an NTLM credential disclosure flaw | CISA: Missing User Interaction for Potentially Unsafe Action; CWE-356: Product UI does not Warn User of Unsafe Actions |
What to do, in the order worth doing
Take this with you
Ranked actions
- Install the 10 November Office update first: it is the only entry in Microsoft's data flagged exploited. Fixed builds in the CVRF are 16.0.14334.21048 for Office LTSC 2021 and 16.0.17932.21140 for Office LTSC 2024; Microsoft 365 Apps follows the channel builds on Microsoft's Office release notes page.
- Find Outlook installations that lack it (this site's suggestion). The CVRF names six product rows, but your inventory decides which builds are present, including any Office 2019 or retail builds the CVRF does not list for this CVE.
- Block or restrict outbound SMB and NTLM authentication to untrusted networks, and review which accounts can still authenticate with NTLM (this site's suggestion; no Microsoft page read for this brief prints that mitigation, so test the effect on your own file sharing first).
- Look back for outbound connections to external addresses from mail clients, for example file sharing protocols, from before the update (this site's suggestion; Microsoft and CISA print no indicator or detection query, and exploitation preceded the release).
- Treat accounts whose users opened unexpected message files from outside before the update as possibly exposed, and decide whether a password reset is proportionate (this site's suggestion and inference; neither Microsoft nor CISA says hashes were captured in any organisation).
- Do not triage the other 1,300 or so entries by label alone. Microsoft's exploitability field marks 42 of the 1,093 as Exploitation More Likely, 5 of them Critical and 37 Important; use it beside severity (this site's suggestion).
- Agree internally which count you quote, and say which rule it is: 1,094 for entries first dated 10 November, 1,093 if third party entries are removed, 1,342 for the file at revision 167, 1,362 at revision 192 (this site's suggestion).
Technical details
Everything below is copied from the primary records. Neither Microsoft nor CISA prints an indicator, a file hash, a sample, a message file, a network address, a detection query or exploit detail for this flaw, so this section has none, and nothing here is a proof of concept. The first block is what Microsoft's FAQ says; a defender uses it to explain the flaw to a user and to scope a hunt. Quoted fields are copied exactly; where this site shortened a field name, the value is exact.
Q: How could an attacker exploit this vulnerability?
A: An unauthenticated attacker could send a specially crafted message file and
convince a user to open it in an affected version of Microsoft Outlook.
Opening the file could cause Outlook to connect to an attacker-controlled
network location without displaying the usual external-content warning,
potentially disclosing authentication information that could be used to
impersonate the user. Exploitation requires network connectivity and user
interaction.
Q: Is the Preview Pane an attack vector for this vulnerability?
A: No, the Preview Pane is not an attack vector.
Q: According to the CVSS metric, user interaction is required (UI:R). What
interaction would the user have to do?
A: An attacker must send a user a malicious Office file and convince them to
open it.
Q: According to the CVSS metrics, successful exploitation of this
vulnerability could lead to major loss of confidentiality (C:H). What does
that mean for this vulnerability?
A: This vulnerability discloses a user's NTLMv2 hash to the attacker who could
use this to authenticate as the user.
The next block holds the fields of the same entry that decide patching: the flags string, the labels, the vector and the fixed builds. A defender compares installed Outlook and Office builds with the three fixed build values.
Title: Microsoft Outlook Spoofing Vulnerability
CVE: CVE-2026-124194
CWE: CWE-356 Product UI does not Warn User of Unsafe Actions
Threat (type 1): Publicly Disclosed:No;Exploited:Yes;Latest Software Release:Exploitation Detected
Threat (impact): Spoofing
Threat (severity): Moderate
CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N/E:H/RL:O/RC:C
BaseScore 6.5, TemporalScore 6.2
Customer Action Required: Yes
FixedBuild (Office LTSC 2021): 16.0.14334.21048
FixedBuild (Office LTSC 2024): 16.0.17932.21140
FixedBuild (Microsoft 365 Apps for Enterprise): https://aka.ms/OfficeSecurityReleases
Revision 1.0: 2026-11-10T08:00:00, Information published.
The CVE record carries the same weakness, vector and product ranges under Microsoft's name as the assigner. For Microsoft 365 Apps the version limit is a link, not a build number.
title: Microsoft Outlook Spoofing Vulnerability
descriptions: Product ui does not warn user of unsafe actions in Microsoft Office Outlook allows an unauthorized attacker to perform spoofing over a network.
problemTypes: CWE-356: Product UI does not Warn User of Unsafe Actions
cvssV3_1 vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N/E:H/RL:O/RC:C
cvssV3_1 baseScore: 6.5
cvssV3_1 baseSeverity: MEDIUM
affected: Microsoft 365 Apps for Enterprise, version 16.0.1, lessThan https://aka.ms/OfficeSecurityReleases
affected: Microsoft Office LTSC 2021, version 16.0.1, lessThan 16.0.14334.21048
affected: Microsoft Office LTSC 2024, version 16.0.0, lessThan 16.0.17932.21140
datePublic: 2026-11-10T16:00:00.000Z
Microsoft's Office release notes page lists these builds under 10 November 2026, and lists CVE-2026-124194 under Outlook in that block. Compare them with the build shown in Outlook, then follow the channel the device is on.
November 10, 2026
Current Channel: Version 2610 (Build 20527.20196)
Monthly Enterprise Channel: Version 2610 (Build 20527.20194)
Monthly Enterprise Channel: Version 2609 (Build 20430.20264)
Monthly Enterprise Channel: Version 2608 (Build 20326.20320)
Semi-Annual Enterprise Channel (receives Monthly Enterprise Channel builds): Version 2610 (Build 20527.20192)
Semi-Annual Enterprise Channel (receives Monthly Enterprise Channel builds): Version 2609 (Build 20430.20262)
Semi-Annual Enterprise Channel (receives Monthly Enterprise Channel builds): Version 2608 (Build 20326.20318)
Office 2024 Retail: Version 2610 (Build 20527.20196)
Office 2021 Retail: Version 2610 (Build 20527.20196)
Office LTSC 2024 Volume Licensed: Version 2408 (Build 17932.21140)
Office LTSC 2021 Volume Licensed: Version 2108 (Build 14334.21048)
Office 2019 Volume Licensed: Version 1808 (Build 10417.20236)
CISA's catalogue entry and the SSVC data on the CVE record are below. The required action text is long; the part that matters is the due date, which is 14 days after the date added (derived).
cveID: CVE-2026-124194
vendorProject: Microsoft
product: Office
vulnerabilityName: Microsoft Office Outlook Missing User Interaction for Potentially Unsafe Action Vulnerability
dateAdded: 2026-11-10
dueDate: 2026-11-24
knownRansomwareCampaignUse: Unknown
forensicTriage: No
cwes: CWE-356
catalogVersion: 2026.11.10
role: CISA Coordinator
version: 2.0.3
timestamp: 2026-11-09T00:00:00+00:00
Exploitation: active
Automatable: no
Technical Impact: partial
kev dateAdded: 2026-11-10
The question the counts leave open
If one flaw in 1,093 was used in attacks before the update existed, and Microsoft's own label put it last, what in your patching report would have put it first: the severity column, the release total, or the exploited flag, and who in your organisation checks which of the three the report is sorted by?
Key facts
Sources
- PrimaryCVRF document 2026-Nov, revision 167, release date 2026-11-10T08:00:00: 1,342 entries, severity, impact and exploited flags, FAQ, fixed builds, release notes with the 1094 heading. JSON copy parsed in full. Microsoft sells the products it ratesMicrosoft Security Response Centeraccessed 2026-11-11
- PrimaryCVE record for CVE-2026-124194: Microsoft container (CWE-356, CVSS 3.1, affected ranges) and the CISA ADP container (SSVC, KEV date)CVE Programaccessed 2026-11-11
- PrimaryNVD entry for CVE-2026-124194: Microsoft's base vector as a Secondary source, no NVD assigned score as read, CISA fieldsNIST National Vulnerability Databaseaccessed 2026-11-11
- PrimaryKnown Exploited Vulnerabilities catalogue, version 2026.11.10 released 2026-11-10 19:03:29 UTC: the CVE-2026-124194 entry, due date, ransomware and forensic triage fieldsCISAaccessed 2026-11-11
- PrimaryRelease notes for Microsoft Office security updates: the 10 November 2026 block with channel builds and the CVEs listed under OutlookMicrosoft Learnaccessed 2026-11-11
- Reported byMicrosoft November 2026 Patch Tuesday fixes 1,235 flaws, Outlook zero-day (page data 2026-11-10 14:07 ET): its counting rule and 108 exclusions. Secondary; used to find the primaryBleepingComputeraccessed 2026-11-11
- Reported byExploited Outlook Zero-Day Among 1,094 Flaws Patched by Microsoft (page data 2026-11-10 19:19 UTC). SecondarySecurityWeekaccessed 2026-11-11
- Reported byMicrosoft Fixes Nearly 1,100 Security Vulnerabilities (page data 2026-11-10 20:05 ET): 1,093 and 63 Critical, the AI attribution, an Ivanti quote. SecondaryKrebs on Securityaccessed 2026-11-11
