A Patched Vulnerability Is Not a Revoked Capability

What happened

Between April and July 2026, five vulnerabilities in on-premises Microsoft SharePoint Server were added to CISA’s Known Exploited Vulnerabilities catalog, one after another. In mid-July the agency warned that multiple flaws were under active exploitation, enabling remote code execution, malware deployment — and the theft of IIS machine keys.

Machine keys are worth pausing on. They are cryptographic material ASP.NET and SharePoint use to validate and, where applicable, decrypt application state such as ViewState — state the application may later process after its cryptographic checks succeed. If those keys are stolen and remain valid, the original vulnerability may no longer be needed: an attacker may be able to construct state objects that pass cryptographic validation, abusing the trust the application places in material signed with those keys. CISA’s own alert names the consequences — deserialization techniques, persistence — on servers whose keys have left the building.

Which is why the response guidance reads the way it does. Patch — but do not stop at patching. Hunt for intrusion artifacts first, explicitly including machine-key harvesting tools planted in the environment. Only then rotate the keys and restart the web server. CISA’s own framing concedes the central point: patching alone may not remove attacker persistence from an already-compromised server.

The usual reading

The standard vulnerability lifecycle is a repair story. A flaw is discovered; a fix is released; the fix is applied; the finding is closed. Every artifact of that process — the advisory, the patch verification, the compliance dashboard turning green — attests to one fact: the entry point no longer exists.

That fact is true, and it is the wrong fact to stop at.

Two different events

Trace what actually happened on a server compromised before it was patched, as two separate events rather than one incident.

The first event was an entry: the vulnerability was exercised, and an outsider gained execution on the server. The patch is aimed at this event. When correctly applied across the affected farm — including the configuration step that a binary install alone does not complete — it closes the known vulnerable path against future exploitation. What it does not do, by itself, is determine anything about what happened before the path was closed.

The second event was an acquisition: during the access, the server’s machine keys were read and exfiltrated. From that moment the attacker held a standing capability — the ability to produce state objects that pass the server’s cryptographic checks. This capability does not live in the vulnerable code. It does not live on the server at all. It lives in the copied keys, and the patch does not touch it.

The remediation record after patching says repaired. It says nothing about whether the trust material taken through the flaw has been revoked — because it measures a different object. One is a property of the software. The other is a property of who currently holds the material the software trusts.

Closing the entry point does not end the capability already acquired.

The check that trusts a stale fact

Consider what happens when a forged state object arrives at a patched server.

The server validates it — cryptographically, correctly. The signature verifies against the machine keys. Every check the request passes through is functioning exactly as designed. The failure is not in any check; it is in a premise underneath all of them: that the signing material is held exclusively by the server. That premise was true when the keys were generated. It stopped being true at the moment of theft. Nothing in the validation path re-examines it.

This is the shape worth extracting from the incident. Current authority, current state, current conditions, and the current operating environment must be re-bound at the execution boundary — and a signature check that treats key exclusivity as a permanent fact is binding today’s execution to a condition verified at key-generation time. The object is not evidence of a legitimate actor. It is evidence that someone holds the keys — and who that is has become an open question the server never asks.

Even revocation has preconditions

The most instructive line in the guidance is the ordering: hunt for harvesting tools before rotating keys.

The reason is precise. Attackers plant harvesters that wait for new keys to be generated and steal them immediately. An operator who rotates keys while a harvester remains resident may complete the revocation procedure while allowing the replacement capability to be captured again. The record will say the keys were rotated. Whether the acquired capability actually ended is a separate fact — and in that scenario, the answer is no.

So the remedial act itself is an execution with an eligibility condition: rotation ends the stolen capability only if the environment no longer contains the means to re-acquire it. Whether that condition currently holds is a question about the present state of the environment — and running the procedure without answering it produces exactly the artifact this whole incident warns about: a record of an action that no longer means what it says.

The proposition

The wave of exploited flaws will close the way most waves do — patches applied, catalog entries remediated, dashboards green. Each of those artifacts will be accurate about what it measures: the entry points are gone.

What none of them measures is the second event. A copied key remains useful for as long as the corresponding trust material remains valid — and patching the vulnerable code does not, by itself, shorten that lifetime. Ending it is a separate act with its own preconditions: the keys rotated, and every mechanism capable of stealing the replacements removed first. The question a patched server cannot answer about an arriving state object is not whether it validates — it does — but whether the material that produced it is still exclusively held, right now, by the system it claims to come from.

Repair is a verdict on the flaw. It is not a verdict on the capability that left through it — and asking that second question, at the moment a state object presents itself for trust, is where execution governance begins.