CVE-2026-62911

The CVSS 8 on this capture-replay vulnerability in Exchange tells you the damage potential. The EPSS 0.00732 tells you exploitation is conditionally hard. The gap between these numbers isn't a scoring failure — it's the metrics doing their jobs, and if you react only to the CVSS, you'll misallocate defensive resources. Capture-replay flaws require the attacker to already possess valid authentication artifacts or intercept them mid-flight. This is fundamentally different from injection flaws or memory corruption where the vulnerability itself is the foothold. The "authorized attacker" qualifier in the CVE description isn't filler — it means this isn't about stopping initial access. It's about limiting what someone who already has credentials can do with them. Your threat model needs to account for insiders, compromised service accounts, and lateral movement scenarios where capture-replay becomes the expansion mechanism rather than the initial compromise. The specific authentication path matters enormously here. NTLM token capture, cookie replay, and OAuth flow exploitation each have different detection signatures. An organization running certificate-based authentication with proper token binding faces a fundamentally different risk profile than one on basic Windows auth with predictable session tokens. Before prioritizing the patch alone, determine which authentication mechanism your Exchange deployment actually uses — the patch addresses one instantiation of a broader class, and understanding your exposure requires knowing which path is vulnerable in your environment. The historical record should inform your prioritization. Capture-replay vulnerabilities have recurred across authentication implementations for decades — NTLM relay followed this exact arc, repeatedly rediscovered and repatched. The pattern isn't malice or ignorance, but a systematic choice across the ecosystem to make the secure path the harder path. The question to ask isn't just "have we patched this CVE?" but "have we tracked whether previous capture-replay vulnerabilities in our environment were actually remediated, or did we patch the specific CVE and treat the class as closed?" Your logging posture is the compensating control that matters most if the patch is delayed. Can your SIEM detect replay attempts — abnormal authentication patterns, duplicate session tokens, authentication from unexpected source addresses for known users? If you're relying on the patch to protect you while your detection infrastructure sees nothing, you're in a double-blind exposure window: the attacker knows the vulnerability exists and can probe for it, but you have no signal. The EPSS isn't just telling you this specific CVE is hard to exploit. It's telling you the ecosystem hasn't solved the underlying problem, which means your threat model needs to account for iterative exposure to the same vulnerability class across your entire authentication surface, not just this specific instantiation in Exchange.

Reviewed through automated stages and approved by a human before publication.