CTIPilot

Microsoft Exchange Server MRSProxy, missing channel-binding check, authentication bypass by capture-replay; public exploit code published 27 August 2026

cve · CVE-2026-62911

Coverage timeline
1
first 2026-08-29 → last 2026-09-01
Peak priority
high
1 high
Sources cited
6
6 hosts
Sections touched
1
trending-vulnerabilities
Co-occurring entities
2
see Co-occurring entities below
ATT&CK techniques
3
pinned v19.2 · see below

ATT&CK techniques

3 techniques observed across 1 entry, derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v19.2 · compare on the matrix · Navigator layer (JSON)

Initial Access TA0001

T1190Exploit Public-Facing Application×1

Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network. The weakness in the system can be a software bug, a temporary glitch, or a misconfiguration.

Evidence: 2026-08-29/exchange-mrsproxy-auth-bypass-cve-2026-62911-poc · ATT&CK page ↗

Privilege Escalation TA0004

T1068Exploitation for Privilege Escalation×1

Adversaries may exploit software vulnerabilities in an attempt to elevate privileges. Exploitation of a software vulnerability occurs when an adversary takes advantage of a programming error in a program, service, or within the operating system software or kernel itself to execute adversary-controlled code. Security constructs such as permission levels will often hinder access to information and use of certain techniques, so adversaries will likely need to perform privilege escalation to include use of software exploitation to circumvent those restrictions.

Evidence: 2026-08-29/exchange-mrsproxy-auth-bypass-cve-2026-62911-poc · ATT&CK page ↗

Credential Access TA0006

T1557Adversary-in-the-Middle×1

Adversaries may attempt to position themselves between two or more networked devices using an adversary-in-the-middle (AiTM) technique to support follow-on behaviors such as Network Sniffing, Transmitted Data Manipulation, or replay attacks (Exploitation for Credential Access). By abusing features of common networking protocols that can determine the flow of network traffic (e.g. ARP, DNS, LLMNR, etc.), adversaries may force a device to communicate through an adversary controlled system so they can collect information or perform additional actions.

Evidence: 2026-08-29/exchange-mrsproxy-auth-bypass-cve-2026-62911-poc · ATT&CK page ↗

Collection TA0009

T1557Adversary-in-the-Middle×1

Adversaries may attempt to position themselves between two or more networked devices using an adversary-in-the-middle (AiTM) technique to support follow-on behaviors such as Network Sniffing, Transmitted Data Manipulation, or replay attacks (Exploitation for Credential Access). By abusing features of common networking protocols that can determine the flow of network traffic (e.g. ARP, DNS, LLMNR, etc.), adversaries may force a device to communicate through an adversary controlled system so they can collect information or perform additional actions.

Evidence: 2026-08-29/exchange-mrsproxy-auth-bypass-cve-2026-62911-poc · ATT&CK page ↗

Story timeline

  1. 2026-08-29CVE-2026-62911, Microsoft Exchange Server MRSProxy: a missing channel-binding check lets a relayed Negotiate authentication take over every mailbox, public exploit code now live sixteen days after the patch
    trending-vulnerabilitiesA working public exploit for an Exchange mailbox-move endpoint lands sixteen days after Patch Tuesday, and MSRC's exploitability rating has not moved

Where this entity is cited

  • trending-vulnerabilities1

Source distribution

  • advisories.ncsc.nl1 (17%)
  • frankysweb.de1 (17%)
  • heise.de1 (17%)
  • msrc.microsoft.com1 (17%)
  • social.bund.de1 (17%)
  • vred.mbbank.com.vn1 (17%)

Co-occurring entities

Derived: referenced by the same focused operational entries (weekly summaries and report roundups don't count); ×N counts the shared entries.

Entries about Microsoft Exchange Server MRSProxy, missing channel-binding check, authentication bypass by capture-replay; public exploit code published 27 August 2026 (1)

2026-08-29 · view entry permalink →

HIGHCVE-2026-62911updatedNATOB2

CVE-2026-62911, Microsoft Exchange Server MRSProxy: a missing channel-binding check lets a relayed Negotiate authentication take over every mailbox, public exploit code now live sixteen days after the patch

CVE-2026-62911 (CWE-294, Authentication Bypass by Capture-Replay) was patched in Microsoft's 11 August 2026 Exchange Server security release, at the time rated "Exploitation Less Likely" (Microsoft Security Response Center, 2026-08-11). NCSC-NL revised its own advisory (NCSC-2026-0289) on 2026-08-28 specifically to record the public proof-of-concept and raised its likelihood/damage assessment from medium/high to high/high as a result (NCSC-NL, 2026-08-28). The flaw sits in the MRSProxy endpoint Exchange exposes for cross-server mailbox moves: MRSProxy accepts Negotiate authentication but never validates channel bindings, the check Extended Protection for Authentication depends on (Franky's Web, 2026-08-27). Without that check, an attacker who captures or coerces a Negotiate/NTLM authentication exchange can relay it to MRSProxy and be treated as the relayed account rather than as themselves; Microsoft's own FAQ confirms the resulting access lets an attacker "take over the mailboxes of all Exchange users... send emails, read emails, download attachments" (Microsoft Security Response Center, 2026-08-11). The flaw was discovered by Orange Tsai of DEVCORE Research Team and demonstrated at Pwn2Own Berlin 2026 as one link in a three-vulnerability chain that together achieved SYSTEM-level remote code execution on Exchange, reported to Microsoft through the Zero Day Initiative (Franky's Web, 2026-08-27). Working exploit code was published on GitHub around 27 August 2026 (sixteen days after the patch) and MSRC's exploitability rating has not been revised since its 11 August publication despite the public proof-of-concept (Franky's Web, 2026-08-27). Affected are all Exchange Server builds below the August 2026 cumulative/security update across Exchange Server SE, 2019 (CU14 and CU15) and 2016 (CU23); there is no workaround via Exchange Emergency Mitigation, so the update must be installed directly, and updates for Exchange 2016 and 2019 are available only through Microsoft's paid Extended Security Updates (ESU) program; organizations without a current ESU license will not receive the patch (Franky's Web, 2026-08-27). No in-the-wild exploitation has been reported as of this writing.

MSRC's own CVSS vector scores the precondition as PR:L/UI:R, an "authorized attacker" with some user interaction (Microsoft Security Response Center, 2026-08-11), but Franky's Web's technical description, Germany's CERT-Bund and the Dutch NCSC-NL all independently characterise the flaw as exploitable by an attacker with no authentication at all. CERT-Bund states the public exploit "enabl[es] the complete remote takeover of systems without authentication" (CERT-Bund, 2026-08-28), and NCSC-NL's own advisory states plainly that the flaw "allows an unauthenticated attacker to execute arbitrary code" (NCSC-NL, 2026-08-28). A third-party technical reconstruction of the exploit chain narrows what "coerce or capture" requires in practice: MB VRED's own most plausible hypothesis (not a confirmed finding) is that the attacker needs an existing foothold on the internal, domain-joined network to issue an MS-EFSR (PetitPotam-style) coercion call against one Exchange server, capturing its machine-account authentication and relaying it to the MRSProxy endpoint on a different Exchange server ("The attacker sits inside the network, especially inside a domain-joined PC!") and the technique needs at least two Exchange servers in the environment, since "the captured hash cannot be relayed to itself." MB VRED frames this as requiring "lot of non-realistic conditions to be exploited in the real world", specifically, outbound connectivity from an Exchange server and inbound access on ports domain users do not normally reach it on, closing with "So, for the defensive guys, don’t be panic!" (MB VRED, 2026-08-13). Weighing two independent national CERTs' plain "unauthenticated" characterization against both the vendor's own CVSS labelling and this single, uncorroborated hypothesis about the network position it may actually require, any Exchange server below the August 2026 build should still be patched on the CERTs' own stated urgency, but MB VRED's own caveats are a reason for caution before assuming this is exploitable from the open internet without any existing foothold on the target's network. Detection concept: authentication and session telemetry for MRSProxy/EWS access running under the Exchange server's own machine-account context but originating from unexpected source hosts, a legitimate mailbox move originates internally, not via relayed external traffic, with Windows Security Event 4624 Logon Type 3 network logons in that account context as the platform-specific anchor.

Working exploit code has surfaced for the critical Exchange vulnerability CVE-2026-62911 from the August update.

This endpoint accepts Negotiate authentication but does not check the so-called channel bindings. It is precisely this check that enforces Extended Protection.

Franky's Web 2026-08-27

Authentication bypass by capture-replay in Microsoft Exchange Server allows an authorized attacker to elevate privileges over a network.

What privileges could be gained by an attacker who successfully exploited the vulnerability? The attacker would be able to take over the mailboxes of all Exchange users, attackers can send emails, read emails, download attachments.

Microsoft Security Response Center 2026-08-11

A PoC exploit has been published for the critical vulnerability CVE-2026-62911 in Microsoft Exchange, enabling the complete remote takeover of systems without authentication. (translated from German)

CERT-Bund (BSI) 2026-08-28

This vulnerability allows an unauthenticated attacker to execute arbitrary code. (translated from Dutch)

NCSC-NL

Currently, however, around 85% of on-premises Exchange servers in Germany are still vulnerable to this vulnerability. (translated from German)

CERT-Bund (BSI) 2026-08-28

Currently, however, we are only aware of 9 Exchange servers 2016/2019 in Germany on which patches issued under ESU are installed. (translated from German)

BSI, via heise Security

The attacker sits inside the network, especially inside a domain-joined PC!

This one works only for multiple Exchange servers setup because the captured hash cannot be relayed to itself!

It requires lot of non-realistic conditions to be exploited in the real world:

So, for the defensive guys, don’t be panic!

MB VRED 2026-08-13
Updaterun 2026-09-01T0411Z-intelsourcesevidenceactionscvessourcing_notebody

Following a press inquiry, Germany's CERT-Bund (part of the BSI) disclosed on 2026-08-28 that most of the country's on-premises Exchange population had still not applied the August patch: "Currently, however, around 85% of on-premises Exchange servers in Germany are still vulnerable to this vulnerability" (translated from German) (CERT-Bund, 2026-08-28). BSI states it has been proactively notifying German network operators about still-vulnerable systems in their networks since 2026-08-14 (heise Security, 2026-08-31). For the small population of Exchange 2016/2019 installs still supported only through the paid Extended Security Updates program, BSI says it is aware of only nine servers in Germany with the ESU patch installed (BSI, via heise Security, 2026-08-31). BSI's standing advice is unchanged: restrict internet-facing access to an Exchange server's web-based services to trusted source IP ranges, or place it behind a VPN.

This is the operationally important delta for any DACH-region on-prem Exchange operator, including Swiss cantonal and communal administrations running Exchange on-premises: German telemetry indicates that most operators in a comparable environment have not applied a two-week-old patch against a pre-auth, mailbox-wide takeover chain with public exploit code. "We applied the August patch" should be verified against the actual installed build number, not assumed from a routine patch-cycle checklist.

vulnerability29 Aug 04:09Zmulti-sourceOpen finding ↗