Your SharePoint 2016 got its last patch on 14 July

When a proof of concept lands and hours later there are attackers using it, the reflex is to ask whether it needed publishing at all. We think that is the wrong question, and not out of politeness: KEVintel's sensors date the first attempt against this flaw to 19 July, twenty-four days before the exploit existed on GitHub. What does change the problem is a different date: the patch shipped on 14 July, the same day SharePoint Server 2016 and 2019 stopped receiving them.

We are neither for nor against publishing exploit code on principle. We run client servers, and from that chair what counts is the twenty-nine days between the 14 July patch and the 12 August exploit: what got done with them. There is also a circumstance here that does not come around every month, and it is the reason this advisory deserves half an hour of your afternoon.

What the flaw does: a signature nobody checks

CVE-2026-55040 carries a Microsoft-assigned score of 9.1, with this vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Over the network, low complexity, no prior credentials, nobody has to click anything. Confidentiality and integrity high; availability, none. In plain terms: the server stays up while somebody reads and writes inside it pretending to be somebody else.

Rapid7's analysis describes four pieces failing in sequence, and not one of them is an exotic overflow. They are four checks that exist and that say yes:

The only thing the attacker has to supply is who they want to impersonate: the victim's Windows SID or UPN, which is very often their email address. With that they operate as that user —or as a site administrator— against the authenticated APIs. Point three is the one that most resembles real life: the check does not fail through carelessness, it fails because it is pointed the wrong way. It searches a list, does not find the certificate, and instead of rejecting it, waves it through.

The timeline, which is where the argument lives

The date to look at is 19 July, with a warning attached: it comes from a single source. KEVintel's sensors date the first attempt against this flaw there, and industry coverage —which places exploitation after the proof of concept— does not report it. It is also few events: as of 11 August the record itself counted barely a dozen. And CISA, in its 13 August assessment, still rates exploitation as "proof of concept" rather than "active". We do not treat it as settled; we treat it as enough to go and read July's logs, which is what half an hour buys. Because getting there does not take a nation-state: it takes somebody who can diff the pre-patch binary against the post-patch one, a textbook technique rather than a feat.

The usual argument, and why it does not hold here

The argument against publishing exploit code has a strong version, and it deserves stating in full: whoever was serious did not need it —they had had it for weeks— but a repository with the exploit inside turns anybody with a terminal into a capable attacker. There is data behind that here: the attempts sensors record cluster right after 12 August, and Defused's honeypots saw Rapid7's code used verbatim, the same day. Publishing has a measurable cost.

It still does not convince us, for a specific reason: the argument asks for time to patch, and here there is no time left to ask for. Delaying publication makes sense when a repair process is running —vendor fixes, customer applies, window closes. For a SharePoint 2016 or 2019, that process closed on 14 July and there is no ESU to buy, as we wrote when the date arrived. There, delay does not buy patching: it buys ignorance. Four more weeks of silence would not have fixed a single server; they would have kept the people running them believing a July advisory was already behind them.

And the part that does not flatter us should be said: we have an interest. We make a living running client infrastructure and deploying Microsoft 365, so a noisy advisory suits us. Read it with that in mind. What nobody's interest changes is the support calendar.

A contrast worth having in front of you

As things stand, CVE-2026-55040 does not appear in CISA's KEV catalog. The Cisco ASA flaw we wrote about this morning does: it went in on 11 August with a 14 August deadline, and it is a denial of service that leaks and alters nothing. This one lets somebody impersonate your intranet administrator. We already wrote about why somebody else's list always arrives with its own latency when the vCenter advisory landed; here it is enough to put the two cases side by side.

What we look at on a server like this

Three reflexes that end up costing you

The first is adding a WAF rule and calling it done. It works for this particular chain and for the pattern known today; the server behind it will still be receiving no fixes next month, and for the next flaw there will be no rule to copy from anybody.

The second is announcing the Microsoft 365 migration "for this month". Moving an intranet with years of inherited permissions, flows and customisations is not a weekend, and promising it is how you end up with both systems running and neither maintained. Cutting exposure today and migrating on a calendar are two separate decisions, and only one of them can happen this afternoon.

The third is filing it as one more flaw in the pile. July brought 622 patches in a single day and that volume invites batch treatment. This one differs from the other 621 in a basic way: there will be no next Tuesday to fix whatever comes after it.

What changed on 15 July

A server out of support is not a server with a higher risk: it is a server with a risk that no longer goes down. Until 14 July, every flaw that turned up in your SharePoint 2016 had a date ahead of it when it would be fixed. From the 15th, it does not. This CVE is the first to show that with a public exploit and attempts on the record, which is why it is worth looking at today: it teaches something about the ones coming behind it with no KB attached. It is worth knowing how much longer "we are patched" will mean anything on that machine.

With one honest caveat: Microsoft has broken its own rule at least twice, for XP and Server 2003 in 2017 over WannaCry and again in 2019 over BlueKeep, always for flaws able to spread on their own from machine to machine. This one is not. Planning around that exception is planning around a lottery ticket.

Sources (consulted on 14 August 2026): the 9.1 score, CVSS vector, official description, affected versions and fixed builds — the CVE-2026-55040 record at NVD, with the metric assigned by Microsoft and with CISA's 13 August SSVC assessment rating exploitation as "proof of concept"; the technical chain of four checks and the 14 July joint disclosure date — Rapid7's technical analysis; the KB numbers — KB5002891, KB5002883 and KB5002882 on Microsoft support; publication of the proof of concept and observation of its use on 12 August by Defused — Security Affairs and BleepingComputer, which is also the source of the count of more than 8,500 exposed servers attributed to Shadowserver; first attempt observed on 19 July, 367 cumulative attempts, 23 IP addresses, eight countries and "confirmed" confidence — the KEVintel record (telemetry from four private sensors: these are attempts they observed, not an industry census, and industry coverage places exploitation after the proof of concept); the CVE's absence from the known exploited vulnerabilities catalog — CISA KEV, checked against their public file on 14 August; end of extended support for SharePoint Server 2016 and 2019 on 14 July 2026 with no ESU programme — lifecycle pages for SharePoint Server 2016 and 2019 on Microsoft Learn. Photo: "Archive storage" by Samuel Zeller, public domain (CC0), via Wikimedia Commons.