Your patched Exchange is already compromised

1. Opening Claim

Microsoft has issued a warning that an Exchange zero-day flaw is being exploited in attacks. The specifics of the flaw, the threat actors involved, the scope of compromise, and the technical mechanism of the exploit are not confirmed in the statement under review. What is confirmed is the operational position: a previously undisclosed vulnerability in Exchange is in use against live targets, and no vendor patch was available at the point the warning was issued.

That position defines the current condition for every organisation running Exchange. The window between exploit weaponisation and remediation is the window of maximum exposure. The warning establishes that this window is open. It does not establish how long it has been open, how many environments are affected, or which Exchange components are reachable through the flaw. Each of those is not confirmed.

Treat the warning as a state declaration, not as advisory content. Exchange is, at this moment, an asset under active threat from a primitive for which no public patch is confirmed. The defender posture must reflect that condition. Anything less treats unconfirmed safety as confirmed safety, which is the failure mode that produces preventable compromise.

2. The Original Assumption

Most Exchange deployments operate on a baseline assumption that the platform is hardened by vendor patches, that exposed services sit behind appropriate network controls, and that telemetry will surface anomalies before escalation. That assumption holds when the threat is known and signatured. It does not hold when the threat is a zero-day. The category itself defines absence of the conditions the assumption depends on.

A second assumption is that compensating controls layered above Exchange (endpoint detection, mail filtering, identity protection) will absorb any single weakness in the underlying platform. Defence in depth gets treated as a substitute for primary control integrity. It is not. Compensating controls are designed to constrain an attacker who has already crossed a boundary. They are not designed to replace the boundary. When the primary boundary is the Exchange execution context itself, controls outside that context cannot enforce decisions made inside it.

The third assumption is dwell tolerance. Many programs operate as if early detection is sufficient even when prevention fails. Detection depends on the attacker producing signal that matches a known pattern. A zero-day by definition has no public pattern. Signature detection lags the exploit. Behavioural detection lags the technique. The assumption that the activity will be visible at the moment it occurs is not supported when neither the technique nor its observable behaviour is confirmed to the defender. Visibility is a property of the control, not a property of the environment.

3. What Changed

The warning changes one element of the threat model: exploitation is confirmed. Microsoft has stated the flaw is being used in attacks. That moves the vulnerability out of the theoretical category and into the active category. The technical chain, target selection, post-exploitation behaviour, and victim count are not confirmed in the input under review and must be treated as such. The change is in status, not in detail.

What is logically necessary from confirmed in-the-wild exploitation: at least one actor holds working capability against unpatched Exchange and is exercising it. The exposure window did not open with the warning. It opened when the capability became operational, which is not confirmed. The warning marks defender awareness. Attacker awareness preceded defender awareness by an interval that is not confirmed. Any planning that anchors on the warning date as the start of risk is anchored incorrectly.

The operational posture must shift accordingly. Exchange instances cannot be treated as routine infrastructure during this interval. Exposure surface, patch readiness, and the access boundaries around Exchange require active review rather than scheduled review. Any system that depends on Exchange behaving as a trusted service, including mailbox access, calendar integration, and authentication flows tied to Exchange identities, inherits the uncertainty of the underlying platform until a vendor patch is applied and the patched state is verified. Trust in Exchange is, for the duration of this window, not confirmed.

4. Mechanism of Failure or Drift

The mechanism is supplier-dependent boundary enforcement. Exchange operates as a privileged execution context inside the environment. The integrity of that context is defined by the vendor’s code, the vendor’s disclosure cadence, and the vendor’s patch availability. When the vendor has not released a fix, the defender has no mechanism to assert the boundary at the level the flaw operates. The control surface available to the operator, including network filtering, access policy, and monitoring, sits outside the code path where the flaw resides. That separation is the structural failure. The defender is asked to enforce a boundary using tools that do not reach the layer the boundary is actually drawn at.

The drift compounds when Exchange is treated as a service rather than as an exposed application. Service-class treatment assumes that the vendor underwrites the threat model. The defender contributes operational posture, the vendor contributes platform integrity. In a steady state, that division functions. In a zero-day state, the division collapses. The vendor is not yet able to deliver platform integrity. The defender has not retained the capability to enforce the boundary independently. Both halves of the model are in deficit at the same time. Nothing in the input under review confirms that this division was reconsidered before the warning. The operating assumption was a steady state. The current state is not steady.

The third mechanism is observability asymmetry. The defender’s signal set was built against known techniques. The technique used against this flaw is not confirmed. Detection content, EDR coverage, mail flow inspection, and identity anomaly scoring are each calibrated against patterns derived from prior disclosures. None of those calibrations can be assumed effective against the current primitive. Effectiveness against the active threat is not confirmed. Operating as if existing detection covers the current threat treats prior coverage as present coverage. It is not. Coverage is a property of what the control was designed to see. If the technique is outside that design, the control is silent. Silence is not safety.

5. Expansion into Parallel Pattern

The pattern is consistent across any platform where the security boundary is enforced by vendor code that the defender cannot inspect, replace, or substitute. Exchange is one instance of this class. Identity providers, edge VPN appliances, mail security gateways, file transfer platforms, and management consoles for hypervisors and storage systems share the same structure. A flaw inside the trusted execution context of any of these resets the defender’s exposure to whatever interval exists between vendor awareness and vendor remediation. That interval is not under defender control. The defender inherits the vendor’s disclosure cadence as their own exposure cadence whether they accept that condition or not.

The pattern extends to platforms reachable from outside the perimeter that hold credentials, tokens, or session state for users inside the perimeter. The flaw does not need to deliver direct code execution to be material. Any capability that yields access to authentication material, mailbox contents, or the routing of trusted communication delivers a primitive the defender did not authorise. The boundary that mattered was inside the platform. The controls the defender operates sit outside the platform. The asymmetry is the same one Exchange exhibits in this window. Whether that asymmetry is currently being exercised against any specific environment is not confirmed.

The same mechanism appears every time a single vendor product holds a category of trust the rest of the environment depends on. The platform becomes a concentration of risk that is not proportional to its operational footprint. One product, one disclosure, one window, one interval of exposure replicated across every environment running that product. The pattern is not specific to Exchange. Exchange is the current instance of the pattern that is in the active state. The next instance will be whichever vendor-controlled trust dependency carries the next disclosure. The defender posture that handles this Exchange window is the same posture required for that next instance. Building the posture per-incident is rework. Holding the posture as a permanent condition is the only configuration that closes the asymmetry.

6. Hard Closing Truth

Exchange, during the active exploitation window, is not a trusted service. It is a system under live threat from a capability the defender cannot identify, cannot signature, and cannot patch. Treat it accordingly. Operate with the position that the platform may be acting outside defender policy at any moment within this window. Anything the defender is not directly enforcing on top of Exchange is, for this interval, not enforced. Trust that is not enforced is assumed trust. Assumed trust is the condition the attacker is operating against.

Identity is the boundary. Exchange identities, including service accounts, hybrid connectors, delegated mailbox permissions, and application registrations tied to Exchange, are the boundary objects most directly exposed by a flaw inside the platform. Every credential, token, and trust relationship anchored in Exchange must be treated as potentially exercisable by an unauthorised party until the platform is patched and the post-patch state is validated. Continued validity of those credentials past the window is not confirmed. Any system that accepts an Exchange-issued assertion as proof of identity inherits the uncertainty of the issuer for the duration of that uncertainty.

The vendor advisory is the start of the defender’s work, not the end of it. The patch, when released, closes the disclosed flaw. It does not close the interval during which the flaw was usable. It does not produce evidence that the defender’s instance was not touched. That evidence has to be generated by the defender against the environment they operate. If it has not been generated, the state of the environment is not confirmed. Operate from that condition until the evidence exists. Absence of alert is not presence of safety. The control either enforced the boundary or it did not. If enforcement is not confirmed, the boundary is not confirmed. Anything beyond that is noise.