← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-28754 · CWE-79 · Disclosed 2026-04-03

Zohocorp ManageEngine Exchange Reporter Plus versions before 5802 are vulnerable to Stored XSS in…

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"This is admin-to-admin stored XSS with heavy real-world friction, not a fleet-wide fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Obtain Exchange-admin foothold

The attacker first needs valid access with Exchange administrative privileges in the target organization, per the vendor advisory. In practice this is not an internet spray-and-go bug; it is a follow-on move after credential theft, insider access, or an already successful compromise of Exchange admin workflows. Tooling here is usually ordinary admin access or stolen session reuse rather than a public exploit for this CVE.
Conditions required:
  • Authenticated access tied to the victim organization
  • Exchange administrative privileges
  • Ability to modify data that is rendered in the vulnerable report
Where this breaks in practice:
  • 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
Detection/coverage: No vuln scanner sees this step; identity telemetry, PAM logs, Exchange admin audit logs, and EDR around admin workstations are the controls that matter.
STEP 02

Seed the stored payload into Exchange-backed data

The attacker injects malicious script into content later rendered by the Distribution Lists report. The weaponized payload is just browser script embedded in a stored field, and the persistence is what matters: once saved, the script sits in the application data path waiting for someone else to render the report.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Version scanners can flag vulnerable builds, but they usually do not validate exploitability of the report path itself. Content inspection in Exchange object attributes and unusual characters in distribution-list metadata are better clues.
STEP 03

Wait for an admin to open the vulnerable report

Exploitation requires user interaction: a victim with access to Exchange Reporter Plus must browse to the Distribution Lists report and render the poisoned entry. This is classic stored-XSS friction; the bug does nothing until the right human opens the right page in the right app context.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Web logs and reverse-proxy logs can show access to the affected report URL, but they will not prove JavaScript execution. Browser telemetry, CSP reports if enabled, and anomalous session activity after report views are the best indicators.
STEP 04

Hijack the victim's ERP session or act in-browser

Once the script runs, it can perform actions in the browser context of the victim user, including session theft or admin action forgery against Exchange Reporter Plus. The impact is real, but it is mostly bounded to what the victim can do in that app and whatever trust exists between that console and adjacent admin workflows.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: This is hard for network scanners. Look for suspicious admin actions immediately after report views, unexpected session reuse, and browser-origin requests inconsistent with normal human navigation.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in the sources reviewed, and CISA KEV does not list CVE-2026-28754.
Public PoC availabilityNo public exploit located in GitHub / Exploit-DB searches reviewed; Tenable also states "No known exploits are available" for the related detection.
EPSSUser-provided EPSS is 0.00023; secondary sources reviewed show roughly 0.0002–0.0003, which is effectively very low expected exploitation probability.
KEV statusNot KEV-listed; no CISA due date applies.
CVSS disagreementVendor/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 versionsExchange Reporter Plus build 5801 and below are affected; NVD CPEs explicitly include 5800 and 5801 and a broader pre-5.8 range.
Fixed versionBuild 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 positionAuthenticated 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 coverageNessus 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 reachabilityShodan'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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.6/10)

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.

HIGH Affected version range and fixed build
HIGH Need for user interaction and report-specific trigger
MEDIUM Real-world exploitability in enterprise deployments
MEDIUM Internet exposure prevalence for this product

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# 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
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat this like an emergency mass-patching event unless your Exchange Reporter Plus console is broadly exposed or your Exchange admin tier is already suspect. For a LOW verdict, the noisgate mitigation SLA does not apply and the noisgate remediation SLA treats this as backlog hygiene; verify which servers are still on build 5801 or below, restrict access to the console if it is overly reachable, audit suspicious distribution-list metadata this cycle, and patch to 5802+ in the next planned ManageEngine maintenance window rather than burning an outage on it.

Sources

  1. ManageEngine advisory for CVE-2026-28754
  2. ManageEngine build 5802 release announcement
  3. NVD entry for CVE-2026-28754
  4. CISA Known Exploited Vulnerabilities Catalog
  5. Tenable Nessus plugin 305773
  6. Shodan CVE dashboard for ManageEngine Exchange Reporter Plus
  7. Tenable CVE page with EPSS and NVD-aligned scoring
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.