How do I know my server's OWA URL?

The address users sign in with in the browser for Outlook Web App, usually in the form https://mail.example.com/owa. The bare host name is also enough (mail.example.com), https:// and /owa are added automatically.

How do I determine the Exchange version from outside?

Via the OWA login page: Exchange puts its build number into the paths of the static assets (/owa/auth/ /...) and often into the X-OWA-Version header. This check reads both and maps the build to the version and update level.

Does the tool need a username or a password?

No. It only calls the public login page and a fixed list of known paths, entirely without a login attempt.

Why is no specific vulnerability named?

A reliable CVE mapping would need a continuously maintained list. This tool only shows whether and how far an update is missing; the details come from Microsoft's own Security Update Guide.

Does this also work with Exchange Online (Microsoft 365)?

Exchange Online has no build to determine, Microsoft patches it itself. The tool detects this and does no update comparison.

What does it mean if ECP or PowerShell are 'directly reachable'?

These paths allow admin or script access to Exchange. If they respond directly from Exchange instead of through an upstream protection, that is an independent risk regardless of how other paths are secured.

Exchange Server Check

Check the Exchange build of your OWA URL against Microsoft's build list.

An on-premises Exchange server unwillingly reveals its exact build on its public OWA login page (Outlook Web App), and outdated builds almost always contain known, actively exploited vulnerabilities. This check calls the OWA URL you enter once anonymously and answers the question of whether that server is at the current update level, without a login and without scanner behaviour.

What this tool checks

The path is fixed to /owa, it is not a general URL fetch. From a single response it derives: the exact build from the asset paths of the login page (/owa/auth/<build>/…) and additionally from the X-OWA-Version header (merged across all redirect hops), the TLS certificate, the offered auth methods (WWW-Authenticate: Basic Auth is unencrypted and should be off), an internal server name from X-FEServer or X-BEServer, the HSTS state and whether plain-text HTTP on port 80 is still open or redirects cleanly. In addition, a fixed list of further Exchange paths on the same host is checked (ECP, PowerShell, ActiveSync, EWS, OAB, RPC, MAPI, Autodiscover), at most four at a time.

Reading the result

The build is compared against Microsoft's bundled build table: current (green) or how many updates behind (warning, with a pointer to Microsoft's Security Update Guide, deliberately without a CVE mapping). A product family that is no longer supported (Exchange 2013/2016/2019 after end of support) is an error. For the further paths: a directly reachable ECP or PowerShell is an error (admin and script access), the other paths are a warning when directly reachable but not automatically wrong, ActiveSync and EWS are often deliberately open for mobile devices. If no Exchange signal is found at all, that appears at the very top as a note.

Background

Exchange and OWA are a Microsoft product, not an RFC protocol. Microsoft's official build numbers and support periods are used. For the transport and hardening checks the usual web standards apply: X.509 per RFC 5280, TLS per RFC 8446, HTTP Strict Transport Security per RFC 6797. An overview of Exchange versions, support periods and migration guides is in the article Exchange Versions on frankysweb.de (in German).

Common problems and how to fix them

Build is several updates behind. Install the current Cumulative Update and then the latest security update. Exchange has no partial patches: only the full CU plus SU level counts as protected.
Product family without support. Exchange 2013, 2016 and 2019 receive no more security updates after their respective end of support. Migrate to Exchange Subscription Edition or Exchange Online.
Basic Auth still active. The WWW-Authenticate: Basic transmits credentials Base64-encoded, so practically in the clear. Switch to modern methods and disable Basic Auth for the affected virtual directories.
ECP or PowerShell directly reachable. These paths belong behind pre-authentication (reverse proxy, Conditional Access) or on the internal network, not open to the internet. Often only /owa sits behind the protection and the other vDirs are directly reachable.
Plain-text HTTP open or no HSTS. Redirect port 80 cleanly to https via 301 and set a Strict-Transport-Security header with a sufficient max-age.

Common questions

How do I know my server's OWA URL?: The address users sign in with in the browser for Outlook Web App, usually in the form https://mail.example.com/owa. The bare host name is also enough (mail.example.com), https:// and /owa are added automatically.
How do I determine the Exchange version from outside?: Via the OWA login page: Exchange puts its build number into the paths of the static assets (/owa/auth/<build>/...) and often into the X-OWA-Version header. This check reads both and maps the build to the version and update level.
Does the tool need a username or a password?: No. It only calls the public login page and a fixed list of known paths, entirely without a login attempt.
Why is no specific vulnerability named?: A reliable CVE mapping would need a continuously maintained list. This tool only shows whether and how far an update is missing; the details come from Microsoft's own Security Update Guide.
Does this also work with Exchange Online (Microsoft 365)?: Exchange Online has no build to determine, Microsoft patches it itself. The tool detects this and does no update comparison.
What does it mean if ECP or PowerShell are 'directly reachable'?: These paths allow admin or script access to Exchange. If they respond directly from Exchange instead of through an upstream protection, that is an independent risk regardless of how other paths are secured.