This is a bad note slipped into an admin report binder, not a master key to the building
CVE-2026-28754 is a stored XSS flaw in the Distribution Lists report of ManageEngine Exchange Reporter Plus, affecting build 5801 and below and fixed in build 5802. The vulnerable path is not generic unauthenticated web input; the vendor says an attacker must be authenticated and have Exchange administrative privileges within the Exchange organization to inject script that later executes when another user opens the affected report.
The vendor's HIGH 7.3 score is too hot for how this lands in enterprise reality. The decisive friction is the attacker prerequisite: needing Exchange admin already means this is mostly a post-initial-access / post-privilege-escalation move, and exploitation still depends on a second user viewing one specific report in a browser; that makes the reachable population and operational blast radius much narrower than the CNA vector suggests.
4 steps from start to impact.
Obtain Exchange-admin foothold
- Authenticated access tied to the victim organization
- Exchange administrative privileges
- Ability to modify data that is rendered in the vulnerable report
- This prerequisite already implies a serious prior compromise stage
- Most attackers never reach Exchange-admin in mature enterprises
- MFA, PAM, and admin segmentation should reduce the candidate population
Seed the stored payload into Exchange-backed data
- A controllable field reaches the Distribution Lists report output
- The product stores or reflects that field without adequate output encoding
- The target instance is running build 5801 or below
- The attacker needs a field that is actually shown in the report
- Payloads can break if the rendered context is narrower than expected
- Any custom sanitization or browser hardening can reduce reliability
Wait for an admin to open the vulnerable report
- A second user has access to Exchange Reporter Plus
- That user opens the Distribution Lists report
- The browser permits the payload to execute in the application's origin
- This is a narrow report-specific trigger, not any-page execution
- Some environments rarely use this report
- Report viewers may be a small subset of messaging admins
Hijack the victim's ERP session or act in-browser
- The victim session is active and privileged enough to matter
- The application lacks controls that block script-driven actions
- The attacker can exfiltrate or relay data from the browser context
- Impact is tied to victim privileges inside this product, not arbitrary server code execution
- Session controls, HttpOnly/SameSite cookie settings, and anti-CSRF features can blunt some payload goals
- EDR and browser isolation on admin workstations can catch follow-on abuse
The supporting signals.
| In-the-wild status | No public exploitation evidence found in the sources reviewed, and CISA KEV does not list CVE-2026-28754. |
|---|---|
| Public PoC availability | No public exploit located in GitHub / Exploit-DB searches reviewed; Tenable also states "No known exploits are available" for the related detection. |
| EPSS | User-provided EPSS is 0.00023; secondary sources reviewed show roughly 0.0002–0.0003, which is effectively very low expected exploitation probability. |
| KEV status | Not KEV-listed; no CISA due date applies. |
| CVSS disagreement | Vendor/CNA scores it 7.3 HIGH with PR:L, but NVD re-scored it to 4.8 MEDIUM with PR:H and S:C. That NVD direction matches the vendor narrative better because the vendor explicitly requires Exchange administrative privileges. |
| Affected versions | Exchange Reporter Plus build 5801 and below are affected; NVD CPEs explicitly include 5800 and 5801 and a broader pre-5.8 range. |
| Fixed version | Build 5802 fixes the issue; the vendor says it was fixed on 2026-03-19 and published in the advisory on 2026-04-03. |
| Required attacker position | Authenticated attacker with Exchange administrative privileges plus a victim opening the Distribution Lists report. That is a strong downgrade factor because it assumes the attacker is already deep inside the environment. |
| Scanner / detection coverage | Nessus plugin 305773 detects vulnerable instances by self-reported version and is a local Windows check; it does not actively prove exploitability of this report path. |
| Exposure / internet reachability | Shodan's CVE dashboard tracks the product family and the related April 2026 XSS cluster, but the reviewed sources provide no evidence of broad internet-scale exploitation for this specific CVE. Practical exposure is further narrowed because many Exchange Reporter Plus deployments sit behind VPN, admin subnets, or internal reverse proxies. |
noisgate verdict.
The single biggest severity suppressor is the attacker position requirement: the vendor says exploitation requires authenticated Exchange administrative privileges, which means this is not an initial-access bug. Add the need for a second user to open one specific report, and the exposed population collapses from "all vulnerable servers" to a much smaller admin-to-admin abuse case.
Why this verdict
- Start from vendor 7.3, then cut hard for attacker position: the advisory requires authenticated Exchange administrative privileges, which implies prior compromise or insider access rather than internet-origin initial exploitation.
- Cut again for trigger friction: this is stored XSS with UI:R in one named report, so the attacker still needs a privileged victim to open Distribution Lists before anything happens.
- Cut again for blast radius: successful execution acts in the victim's Exchange Reporter Plus browser context; this is harmful, but it is not server-side RCE or domain-wide unauthenticated takeover.
Why not higher?
It is not higher because the chain stacks multiple gating conditions: authenticated access, Exchange admin privileges, and victim interaction on a specific report. Each prerequisite narrows both the reachable population and the value of the bug as a standalone entry vector.
Why not lower?
It is not lower because stored XSS in an admin console can still steal sessions or drive privileged actions if the right operator opens the page. In organizations that expose ManageEngine admin tooling too broadly or share admin workstations, this can still become an effective lateral move.
What to do — in priority order.
- Restrict console reachability — Put Exchange Reporter Plus behind VPN, admin subnet ACLs, or an internal reverse proxy and remove broad user reachability. For a LOW verdict there is no formal mitigation SLA, so do this in the next normal change window if the console is more exposed than it should be.
- Tighten admin access — Reduce the number of users who can both administer Exchange objects and view Exchange Reporter Plus reports; enforce MFA and privileged access management for those roles. This shrinks the overlap needed for the attack chain and should be folded into routine hardening rather than emergency response.
- Audit distribution-list metadata — Review distribution-list names, aliases, descriptions, and any report-rendered fields for suspicious HTML or script-like content, especially where admin changes occurred near 2026-03-19 to 2026-04-03. This is the fastest way to remove a seeded payload if you cannot patch immediately.
- Monitor report access and session anomalies — Log and review access to the Distribution Lists report and correlate with odd follow-on admin actions, token reuse, or browser-origin requests. That gives you a compensating detective control while the issue rides through normal remediation.
- A perimeter WAF is weak here because the dangerous payload is stored inside legitimate application data and fires when an authenticated user renders a report.
- Server-side AV/EDR alone does not stop browser-executed XSS payloads unless it catches the follow-on behavior on the admin workstation.
- MFA after login does not save an already-active browser session from script-driven actions or session theft inside the same origin.
Crowdsourced verification payload.
Run this on the target Windows host where ManageEngine Exchange Reporter Plus is installed. Invoke it as powershell.exe -ExecutionPolicy Bypass -File .\check-cve-2026-28754.ps1; local admin is preferred for reliable registry and service-path access, though read access is often enough.
# check-cve-2026-28754.ps1
# Verifies whether ManageEngine Exchange Reporter Plus is below build 5802.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
param(
[int]$FixedBuild = 5802
)
$ErrorActionPreference = 'SilentlyContinue'
function Get-BuildFromString {
param([string]$Text)
if ([string]::IsNullOrWhiteSpace($Text)) { return $null }
# Prefer the last 4-5 digit token, which commonly represents a build number.
$matches = [regex]::Matches($Text, '(\d{4,5})')
if ($matches.Count -gt 0) {
return [int]$matches[$matches.Count - 1].Value
}
return $null
}
function Get-ProductCandidates {
$paths = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
$items = foreach ($path in $paths) {
Get-ItemProperty -Path $path | Where-Object {
$_.DisplayName -match 'ManageEngine.*Exchange Reporter Plus|Exchange Reporter Plus'
}
}
return $items
}
function Test-InstalledBuild {
$candidates = Get-ProductCandidates
foreach ($item in $candidates) {
$name = $item.DisplayName
$displayVersion = $item.DisplayVersion
$installLocation = $item.InstallLocation
$build = Get-BuildFromString -Text $displayVersion
if ($null -ne $build) {
return [PSCustomObject]@{
Source = 'UninstallRegistry'
Name = $name
VersionText = $displayVersion
InstallLocation = $installLocation
Build = $build
}
}
}
# Fallback: inspect likely service binary paths if version metadata exists.
$svc = Get-CimInstance Win32_Service | Where-Object {
$_.DisplayName -match 'Exchange Reporter Plus' -or $_.Name -match 'Exchange.*Reporter'
} | Select-Object -First 1
if ($svc -and $svc.PathName) {
$rawPath = $svc.PathName.Trim('"')
$exePath = ($rawPath -split '\s+')[0].Trim('"')
if (Test-Path $exePath) {
$fv = (Get-Item $exePath).VersionInfo.FileVersion
$build = Get-BuildFromString -Text $fv
if ($null -ne $build) {
return [PSCustomObject]@{
Source = 'ServiceBinary'
Name = $svc.DisplayName
VersionText = $fv
InstallLocation = Split-Path -Parent $exePath
Build = $build
}
}
}
}
return $null
}
$result = Test-InstalledBuild
if ($null -eq $result) {
Write-Output 'UNKNOWN - Could not locate ManageEngine Exchange Reporter Plus build information on this host.'
exit 2
}
if ($result.Build -lt $FixedBuild) {
Write-Output ("VULNERABLE - {0} appears to be build {1} (source: {2}; version text: {3})" -f $result.Name, $result.Build, $result.Source, $result.VersionText)
exit 1
}
else {
Write-Output ("PATCHED - {0} appears to be build {1} (source: {2}; version text: {3})" -f $result.Name, $result.Build, $result.Source, $result.VersionText)
exit 0
}
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.