📢 New post: Signed by Nobody: CVE-2026-55040 and the Thirty-Six Days Before the Clock Started · 📝 Also fresh: The Patch You Already Applied: CVE-2026-50522 and Evidence That's Filed by Build, Not by CVE · 🚦 Beacon — the FedRAMP 20x KSI emitter — see what it emits ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPConMonCISAVulnerability Management

Signed by Nobody: CVE-2026-55040 and the Thirty-Six Days Before the Clock Started

On August 18, CISA added CVE-2026-55040 to the Known Exploited Vulnerabilities catalog, with a federal remediation deadline of August 21. If you're reading this when it went up, that date is behind you.

It's a weak-authentication flaw — CWE-1390 — in on-premises SharePoint. Microsoft is the CNA and scored it themselves at CVSS 3.1 base 9.1, Critical, on the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. That's the only CVSS on the NVD record; NIST hasn't published a competing analysis, so unlike the July 14 SharePoint item there's no grader disagreement to argue about here.

Start with the good news, because it's real and it shortens the rest of this post considerably.

You have probably already fixed it

The builds that close CVE-2026-55040 are 16.0.5561.1001 for Enterprise Server 2016, 16.0.10417.20175 for Server 2019, and 16.0.19725.20434 for the Subscription Edition.

Those are the same builds that closed CVE-2026-56164 on a July 17 deadline and CVE-2026-50522 on a July 25 one. This is the third catalogued vulnerability riding a single July update. If a farm in your estate met either of those earlier dates, it was remediated for this one roughly five weeks before CISA asked.

The job of turning "we patched in July" into an artifact that proves which deadline it met is the subject of the CVE-2026-50522 post, and it hasn't changed. What's different this time is everything around the patch.

The dates don't line up

Pull the full record rather than the catalog row, and the sequence is strange enough to be worth writing down:

  • July 13 — CISA's own SSVC decision record for this CVE is timestamped, with exploitation marked active, automatability yes, and technical impact total.
  • July 14 — Rapid7 and Microsoft disclose the vulnerability in coordination. The CVE publishes to NVD. The fix builds ship.
  • August 11 — Rapid7 publishes a complete technical analysis, naming the flawed validation logic. Proof-of-concept exploit code goes public alongside it; NVD carries the repository as an exploit reference.
  • August 18 — the KEV listing appears, with a three-day fuse.

The catalog entry is the last thing to happen, by thirty-six days, and it told you nothing that wasn't already public. That inverts the case we wrote up on July 2, where the KEV listing was the disclosure — a due date wearing no explanation, with no vendor writeup or threat-intel post preceding it. Here the explanation arrived first, in detail, with working code attached, and the deadline followed a week later.

Both patterns break the same programs, from opposite directions. A pipeline that waits for the story before treating something as urgent misses the July 2 shape. A pipeline that waits for the catalog misses this one — and the exposure it misses is not theoretical, because for thirty-six days a publicly documented, publicly weaponized authentication bypass on a network-reachable farm sat below the trigger line. The KEV catalog is a compliance clock, not a discovery feed. It has never claimed otherwise. Using its date as the moment your exposure begins is a measurement error, and this CVE lets you measure exactly how large.

Why this one is hard to look for

The mechanism matters here in a way it usually doesn't, because it determines what your logs can tell you.

Rapid7's analysis describes a failure in SharePoint's JWT validation path: signed-token enforcement disabled, so a token declaring alg: none is accepted; a certificate thumbprint in the token header resolved without cryptographic verification; issuer validation that passes unconditionally when the certificate isn't found; and a signature check that confirms a signature is present rather than valid. The result is that an unauthenticated attacker forges a token and impersonates whoever it names, up to and including an administrator.

Sit with what that does to detection. The deserialization bugs in this SharePoint run — 45659, 58644, 50522 — produce something anomalous: a crafted payload, code executing under the application pool identity, often a dropped artifact. There is something out of place to find.

A forged token produces none of that. The request is well-formed. It carries a token the application accepted. It shows up in the logs as a legitimate authenticated session doing legitimate authenticated things, attributed to a real account that a real person also uses. A SIEM rule keyed on unauthenticated access to a vulnerable endpoint will not fire, because from the server's perspective the access was authenticated. The signal isn't unusual traffic — it's that a token nobody signed was honoured, and that fact lives in token-validation detail most farms weren't retaining.

So when CISA's required action for this entry points at the Forensics Triage Requirements under BOD 26-04, it's asking a question your ordinary tooling was not built to answer. CISA lists known ransomware campaign use as Unknown, which describes what CISA has observed and says nothing about your estate.

What the work looks like now

The scheduling problem is gone; the deadline expired on August 21. What remains divides cleanly.

The window you examine starts July 13, not August 18. That's the date on CISA's own exploitation determination, and it's the left edge that the required action's triage question implies — forty-four days back from today rather than the eight the catalog dates suggest. Log retention scoped to the KEV listing is looking at the wrong stretch of calendar, and on a farm patched in mid-July the entire exposure window sits in the part the catalog never mentions. Retention policy is the constraint that decides whether this is answerable at all, and that's worth knowing before an assessor asks rather than during.

What you're hunting for is trust, not intrusion. The material is your authentication and token-validation logging, read against privileged actions reaching back into July — the question being whether the account a session names can actually account for what that session did. If the retention isn't there, the honest artifact is a dated statement that the window can't be reconstructed and why, which is a finding, and a better one than a confident answer you can't support.

A deadline that expired still needs a disposition. For most estates the accurate one is that remediation preceded the requirement, evidenced by the build a scan or change record puts on that farm in July. Where a farm genuinely wasn't patched, the POA&M entry starts August 21 and writing it now with the real date is a far stronger position than reconstructing an explanation later. Either way the deliverable is dated and written down, because a boundary determination or a remediation claim that lives only in someone's memory is a claim rather than a record.

The part that keeps repeating

The recurring lesson in these posts is about inventory, and this entry sharpens it toward timing. Knowing what you run answers the patching question. Knowing when a fact about what you run became true answers this one — and the catalog is a poor clock for it, because it starts late and by its own design starts late.

That's the posture we build the Novaprospect audit engine around: exploitation determinations, vendor disclosures, and catalog listings landing against the same asset inventory with their own dates intact, so the question "how long were we exposed" resolves against a record instead of an argument about which date to use.

The next SharePoint item will arrive, and it may well ride the same cumulative update again. The question worth pre-answering isn't whether you'll patch it. It's which date your program will treat as the start of the problem — and how far that is from the date the attacker was already using.

Reference