SharePoint CVE-2026-65660 went from spoofing to code execution 16 days after release, filed as informational

A 6.5 that was an 8.8 all along

On 11 August 2026 Microsoft published CVE-2026-65660 as a SharePoint spoofing vulnerability with a CVSS 3.1 base score of 6.5. The vector was AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N: confidentiality high, integrity none, availability none. Sixteen days later, on 27 August, Microsoft changed the same record to a remote code execution vulnerability with the vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H and a base score of 8.8. Nothing about the software changed in those sixteen days. The only thing that moved was the two impact metrics, and with them the arithmetic: the impact sub-score rises from 3.6 to 5.9 while the exploitability sub-score stays at 2.8.

The fix did not move either. Both the 6.5 version of the record and the 8.8 version point at the same updates, released on 11 August, and at the same fixed build numbers. Any farm that installed the August updates on patch Tuesday was protected before the label was corrected. The exposure created by this episode belongs entirely to the organisations that read the first label and used it to decide when to act.

What this does not establish. It does not establish that anyone was attacked. There is no report of exploitation in the wild, the CVE is not in CISA's Known Exploited Vulnerabilities catalogue, and Microsoft's own exploitability assessment still reads Exploitation Less Likely. It also does not establish that Microsoft hid anything: the revision is published, dated and visible on the advisory page today. What it establishes is narrower and more useful. A patch decision made from the vendor's impact label on the day of release was, for sixteen days, a decision made from the wrong label, and the correction arrived carrying a note that told readers it did not matter.

What the record said, and when it said it

Microsoft is the CVE Numbering Authority for its own products, so the advisory, the CVE record and the entry that appears in the National Vulnerability Database all originate from the same source. That is why the change propagated everywhere at once. The NVD change history shows Microsoft's new description and vector arriving at 20:18 UTC on 27 August and replacing the old ones. The 8.8 score shown on the NVD page is Microsoft's score, not an independent NIST assessment; NVD has not added a score of its own.

CVE-2026-65660 as published and as revised. Source: Microsoft Security Update Guide revision history and NVD change history, both read on 22 September 2026.

Field	Version 1.0, 11 August	Version 1.1, 27 August
Title	Microsoft Office SharePoint Spoofing Vulnerability	Microsoft SharePoint Server Remote Code Execution Vulnerability
Impact	Spoofing	Remote Code Execution
Description verb	perform spoofing over a network	execute code over a network
CVSS 3.1 vector	C:H / I:N / A:N	C:H / I:H / A:H
Base score	6.5	8.8
Max severity	Important	Important
Weakness	CWE-94, code injection	CWE-94, code injection
Exploitability assessment	Exploitation Less Likely	Exploitation Less Likely
Fix	August 2026 updates	August 2026 updates, unchanged

Two rows deserve attention. The weakness classification never changed: CWE-94 is improper control of generation of code, a code injection weakness, and it was on the record from the first publication. So was the low-privilege requirement. A reader who ignored the impact word and read the weakness and the vector had, on 11 August, a code injection bug reachable over the network by an authenticated user with low privileges, described as spoofing. The second row is the severity: Microsoft rated this Important before the change and Important after it. The severity label carried no information about the correction at all.

Microsoft's FAQ now describes the mechanism in one sentence: an authenticated attacker with low-level access to an affected server could send a specially crafted request to execute code on the server, and user interaction is not required. That is the whole description this briefing needs. The researcher's technical write-up is public, and this site does not republish exploitation detail.

One sentence of revision text

The revision note for version 1.1 reads in full: "Updated Impact in the Security Updates table, CVE Title, and FAQs. This is an informational change only." The phrase at the end is standard Microsoft wording. It normally means that the update packages have not changed and customers who have already patched need do nothing, which is true here. It is also the phrase Microsoft uses when it corrects a spelling, adds an acknowledgement or removes an operating system from a table.

To see how much signal that phrase carries, we parsed Microsoft's machine-readable August 2026 release document and read every revision note attached to every entry in it. Seventy-three entries in that release carry a revision marked as an informational change only. Of those seventy-three, exactly one moved a vulnerability from one impact class to another: this one. One other changed a product severity. The remaining seventy-one are acknowledgements, titles, build numbers, package details and software tables.

So the phrase is honest about the binaries and useless as a triage signal. If your process treats a revision marked informational as noise, you filtered out the single revision in the month that would have changed a priority decision. That is not a Microsoft failure of disclosure. It is a mismatch between what the vendor means by informational, which is that the files did not change, and what a patch team hears, which is that nothing important changed.

The other signals did not move either

A mature triage process does not rely on one vendor field. It usually blends the vendor impact, the CVSS score, CISA's catalogue of exploited vulnerabilities and an exploit prediction score. On this CVE, each of those either repeated the vendor's first reading or said nothing.

What each triage input said on 22 September 2026, and what it does not establish. Sources: NVD change history, CISA KEV JSON feed version 2026.09.21, FIRST EPSS API.

Signal	What it says	What it does not establish
CISA SSVC, recorded 11 August	Exploitation none, automatable no, technical impact partial	Not a live assessment. It was recorded on release day and has not been revised since the impact changed
CISA KEV catalogue	CVE-2026-65660 is absent	Absence of evidence of exploitation, not evidence that exploitation is hard. CVE-2026-55040, a separate SharePoint flaw, went into KEV on 18 August
EPSS	0.807 per cent, 55th percentile	A 30-day model of observed exploitation activity. It rose only from 0.742 per cent on 28 August, the day after the relabel
Microsoft exploitability	Exploitation Less Likely	An assessment made at original publication. The advisory says so explicitly
Publicly disclosed flag	No	It was accurate at publication. The researcher published a full technical write-up on 22 September

The CISA entry is the one worth dwelling on. CISA's automated programme added a stakeholder-specific vulnerability categorisation at 20:38 UTC on 11 August, a few hours after publication, recording the technical impact as partial. Partial is the correct reading of a confidentiality-only spoofing flaw. It is not the reading you would expect for code execution on a server. The NVD change history shows no later revision from that source, so a team consuming that field today is consuming an assessment of the withdrawn description. Attribute it correctly when you do: that entry comes from CISA, not from Microsoft and not from NIST.

EPSS deserves a similar caution in the other direction. A score of 0.807 per cent is low, and it is low because the model has seen no exploitation activity. For comparison, CVE-2026-55040, the SharePoint authentication flaw that CISA added to KEV on 18 August, sits at 50.6 per cent. EPSS is a good input for ranking a backlog and a poor input for deciding whether a server that accepts authenticated requests from staff should be patched at all.

Affected builds, and the versions with nowhere left to go

Microsoft lists three affected products. The fixed builds and the knowledge base articles are the operational facts to check against your farms, because a build number cannot be misread the way a label can.

Affected products, fixed builds and support position. Sources: Microsoft Security Update Guide entry for CVE-2026-65660 and the Microsoft Lifecycle pages for each product, read 22 September 2026.

Product	Fixed build and KB	Support position
SharePoint Server Subscription Edition	16.0.19725.20522, KB5002893	Supported. Later updates exist, including the September update KB5002908
SharePoint Server 2019	16.0.10417.20198, KB5002894 and KB5002896	Extended support ended 14 July 2026. This fix arrived 28 days after that date
SharePoint Enterprise Server 2016	16.0.5565.1001, KB5002905 and KB5002906	Extended support ended 14 July 2026. Same position as 2019
SharePoint Server 2013	Not listed by Microsoft	Out of support since 11 April 2023. No update exists

The 2016 and 2019 rows are the uncomfortable ones. Both products passed their extended end date on 14 July 2026, yet received these security updates on 11 August. Microsoft's own SharePoint escalation engineer, Stefan Gossner, answered the obvious question in the comments on his servicing post on 1 September: the August update "contains fixes for security issues which were identified before end of life", and "No further updates are planned." Read that as it is meant. The August update is a gift, not a signal that patches will keep coming. For a 2016 or 2019 farm, this is very likely the last security update it will ever be offered, and the next SharePoint code execution flaw will have no fix for it at all.

Two further points on the FAQ, because they cost people time. The same knowledge base number covers SharePoint Server 2016 and SharePoint Enterprise Server 2016, so both need it. And where two KBs are listed for one product, a language-independent update and a language-dependent one, Microsoft's FAQ says to install all updates offered for the software you have, in any order.

What Microsoft does not say

Several things a defender would like to know are simply not on the record, and it is worth being explicit about which.

Stated and not stated on the vendor record for CVE-2026-65660, as read on 22 September 2026.

Question	Stated on the record	Not stated
Is SharePoint Online affected?	Nothing. No cloud product appears in the affected list	Whether the service was ever vulnerable, or was fixed separately. The absence of a product is not a statement of safety
Is SharePoint 2013 affected?	Not listed as affected	Whether it is vulnerable. The researcher says all versions including 2013 are affected. Microsoft does not list out-of-support products either way
What privileges does the attacker need?	An authenticated attacker with low-level access, PR:L in the vector	Which SharePoint permission level counts as low-level, or whether read access to one site is enough
Why did the impact change?	Impact, title and FAQs were updated. An informational change only	What prompted the correction, or whether the original classification was a process error
Was anyone told?	The revision is published on the advisory page	Whether any customer notification went out. The machine-readable record marks the revision as not needing notification

The SharePoint Online row is the one most likely to be misread in a meeting. The honest position is that Microsoft's advisory covers server products and says nothing about the service, and that Microsoft patches its own service without publishing customer-facing CVEs for it in most cases. Treating silence as a clean bill of health is a guess. Treating it as evidence of exposure is also a guess. If your risk register needs an answer, the only route to one is to ask Microsoft directly and record the reply.

Switched off is not the same as patched

There is a second change in flight that will confuse anyone reading only their own change tickets. The August updates carry a notice that the ToolPane feature, the web part editing interface, is being retired from the default configuration. For Subscription Edition the September 2026 update KB5002908 states that ToolPane is disabled starting with that update, and gives administrators the Enable-SPToolPane cmdlet to turn it back on per site collection, Disable-SPToolPane to turn it off again, and Get-SPToolPaneEnabledSites to list where it is on. The 2016 and 2019 August articles carry a softer notice that the feature might be disabled in the future.

This matters in two directions. First, a farm where the feature is off is not a farm that has been patched, and re-enabling it for a site collection that needs web part editing does not reintroduce a fixed vulnerability if the August update is installed. Second, the researcher notes that the fixed function is not the only code path of its kind in SharePoint. Feature removal is a hardening measure that reduces how much of the product is reachable; the patch is what fixes the flaw. Do not let a change ticket that says ToolPane disabled close a ticket that says August update pending.

One detection note worth carrying into the hunt. AMSI integration with SharePoint Server is mandatory from the September 2025 update, but scanning of request bodies, as opposed to headers, is a Subscription Edition capability introduced with version 25H1. A 2016 or 2019 farm with AMSI enabled is not inspecting request bodies. That is a gap to record rather than a conclusion, because Microsoft has published no detection guidance specific to this CVE.

Important is not a priority, and informational is not a control

The friendly-name fallacy in this story is not one word but four, and each of them is a real Microsoft field that a triage process can lean on without noticing how little it carries.

Spoofing sounds like a phishing-adjacent nuisance. In Microsoft's taxonomy it is a broad category that in this release covered cross-site scripting, server-side request forgery, credential handling and, in at least one other August SharePoint entry, deserialization of untrusted data. Thirteen of the thirty SharePoint entries in the August release are labelled spoofing. The label describes the effect Microsoft chose to record, not the class of bug.

Important is the ceiling for most SharePoint code execution flaws. It did not change when the impact did. If your process escalates on Critical alone, this flaw never reached you at any point in its life.

Exploitation Less Likely is an assessment made at original publication, and the advisory says so in the heading above it. It is not revised as circumstances change, and it was not revised here.

An informational change only means the update packages are unchanged. It does not mean the information is unimportant, which is precisely the reading it invites.

None of these labels is dishonest. Each one is a compressed summary written for a different purpose than yours. The failure mode is the same one that shows up in every patch-triage post mortem: a team built a rule on a field that was never designed to carry the weight of the decision, and the field did exactly what it always does.

What to do, in order

# Farm build, run on any SharePoint server in the farm
(Get-SPFarm).BuildVersion

# Per-server patch status
Get-SPProduct -Local

# Subscription Edition, after the September 2026 update:
# list the site collections where ToolPane has been re-enabled
Get-SPToolPaneEnabledSites

The question this leaves

The correction here worked. Microsoft revised its own record, in public, sixteen days after release, and the fix had been available the whole time. Nothing in the evidence suggests concealment, and there is no sign that anyone was attacked through the gap.

The uncomfortable part is what the episode reveals about the machinery on the receiving end. A patch decision taken on 11 August, using the vendor impact label, CVSS, KEV and EPSS together, would have produced a low priority on all four inputs, and three of those four still produce that answer today. The fourth changed quietly in a revision that told readers it was informational.

So the question for your own process is not whether Microsoft should have got the label right first time. It is this: when a vendor corrects itself after you have triaged, what in your pipeline notices? If the honest answer is a person who happens to read the news, then the label was never the control. The reading was.

Key facts