Microsoft has patched an important-rated cross-site scripting vulnerability in Power BI Report Server that could allow an authenticated attacker to inject malicious scripts into the portal. The fix arrived on July 8, 2026, but the public advisory, CVE-2026-58647, didn’t appear until July 14. If you’ve already deployed a May 2026 update, you might still be vulnerable—only build 15.0.1121.120 or higher, corresponding to version 1.26.9682.1442, closes the hole.

The patch you might have missed

CVE-2026-58647 is an XSS flaw caused by improper neutralization of input during web-page generation. An attacker who already holds low-level privileges on the server can craft content that, when viewed by another user, executes script in that user’s browser session. The CVSS 3.1 base score sits at 8.0, with high impact across confidentiality, integrity, and availability. The attack vector is network-based, complexity is low, and only user interaction is required—no special privileges beyond a standard authenticated session.

Microsoft’s advisory labels the impact as “spoofing,” but that undersells the risk. Successful exploitation means an attacker can place untrusted code inside a portal that both people and browsers trust. A finance manager opening a shared report, a helpdesk agent following an internal link, or an admin reviewing a dashboard could all become victims. The malicious payload can steal session tokens, redirect actions, or present convincing phishing forms—all while appearing to come from the organization’s own Power BI server.

The vulnerable versions stretch from Power BI Report Server 1.6.0 through any build earlier than 15.0.1121.120. That includes the entire January 2026 branch (15.0.1120.x), the September 2025 branch, and, critically, several builds from the May 2026 branch itself. Three early May 2026 maintenance updates—build 15.0.1121.109 from May 21, build 15.0.1121.115 from June 12, and build 15.0.1121.116 from June 17—are all affected. Only the July 8 refresh, build 15.0.1121.120 (product version 1.26.9682.1442), includes the security fix.

Why authenticated doesn’t mean safe

Microsoft rates exploitation as “less likely” and confirms the flaw wasn’t publicly disclosed or exploited at the time of the advisory. That doesn’t make patching optional. Power BI Report Server typically sits inside corporate networks, hosting dashboards, paginated reports, and data models that aggregate sensitive financial, operational, and strategic information. The user viewing that data often has far more access than the low-privilege account needed to publish a malicious report.

The authentication prerequisite can be trivial in many organizations. Report publishers, analysts, service accounts, external consultants, and business-unit administrators all typically have some degree of write access. A single compromised identity in any of those pools gives an outsider the exact foothold needed. And because the portal is designed to encourage users to open shared items and follow internal links, triggering the victim’s interaction requires no suspicious behavior.

Environments that expose Power BI Report Server through reverse proxies, VPN portals, Microsoft Entra application proxies, or partner-facing gateways face additional risk. Authentication may block anonymous attacks, but it doesn’t stop attackers who have stolen credentials or who are legitimately authenticated external users. In those setups, the server is reachable over the network, exactly what the CVSS vector (AV:N) describes.

What to do right now

There is no documented configuration workaround for CVE-2026-58647. The only defensible response is to install the corrected build on every affected server.

1. Find every instance

Gather an inventory of all Power BI Report Server nodes, including those in scale-out deployments, test environments, and disaster-recovery sites. Don’t rely on the server’s “About” page alone; use the following SQL query against the report server database to pull the build and version:

SELECT ProductVersion, Edition, BuildNumber 
FROM ReportServer.dbo.ServerVersionInfo;

Or check the registry at HKLM\SOFTWARE\Microsoft\Power BI Report Server\CurrentVersion for the same values.

2. Compare against the fixed build

Look for these exact numbers on every node:

  • Product version: 1.26.9682.1442 or later
  • Server build: 15.0.1121.120 or later

If the product version is lower, or if the build number is one of the earlier May 2026 builds (15.0.1121.109, .115, or .116), the server is still vulnerable—even if you already installed a May update.

3. Upgrade immediately

Download the July 2026 servicing update from the Power BI Report Server download page or enable Microsoft Update to receive the patch automatically. The installer follows the same process as previous updates: run it on each server, migrate the database if prompted, and verify the version numbers afterward.

If you distribute patches through WSUS or another management tool, confirm that the specific July 8 build has been approved and has actually reached the target servers. A generic “May 2026” entry in your patch console doesn’t mean the security fix is in place.

4. Handle scale-out deployments with care

In a scale-out, every web-front-end node must run the fixed build. Leaving a single node on an older build preserves a complete attack path. Load balancer health checks might show all nodes as responsive without revealing the version mismatch. Use a script or management tool to query the build on each node after the upgrade.

5. Harden publisher access

Patching removes the vulnerability, but it’s also smart to review who can create, upload, or modify reports. Restrict publisher permissions to the smallest practical group. If you have service accounts that publish from automated pipelines, ensure they follow least-privilege principles and never browse the portal interactively with those credentials.

6. Look for signs of past abuse

Microsoft hasn’t published indicators of compromise for this CVE, so any investigation relies on behavioral clues. Examine browser and proxy logs for unusual script execution around report interactions, recently created content from dormant publisher accounts, or portal activity from privileged users at odd hours. If you find something suspicious, escalate to your security team.

How the building blocks fell into place

Power BI Report Server follows a quarterly feature release cadence, with security and quality servicing updates arriving roughly once a month between features. The May 2026 release (version 1.26.9682.0, build 15.0.1121.100) shipped on May 4, 2026, and was followed by three maintenance updates that fixed functional issues but did not address the XSS flaw.

Microsoft discovered the vulnerability through its internal security processes—no external researcher is credited—and prepared a servicing update that brought the product to version 1.26.9682.1442 on July 8. Even though the fix was ready, the company waited six days before publishing CVE-2026-58647, a common practice that allows coordinated disclosure and gives administrators a head start.

The delay also explains the peculiar version overlap: many admins had already moved to a May 2026 build, but the security fix arrived as a discrete servicing update rather than a full feature release. That’s typical for Microsoft’s stable products, where security patches land on top of the latest feature build. But it creates a false sense of security for anyone who assumes that the most recent feature update automatically includes every security fix.

The vulnerability’s classification as an XSS problem is straightforward, but its CVSS score of 8.0 requires explanation. The base score formula weights the attack vector, complexity, privileges, user interaction, scope, and impact. Here, an attacker with low privileges can strike over the network, and while user interaction is needed, the impact is complete compromise of the victim’s session. The “scope: unchanged” metric means the vulnerability affects only the vulnerable component, but within that session, confidentiality, integrity, and availability are all severely impacted, pushing the score high enough to land in the “important” band.

What comes next

No public proof-of-concept exploit is known, and Microsoft says exploitation is unlikely. But information about the flaw will spread in the coming days, and some security vendors routinely produce detection content for new CVEs. If you run an on-premises Power BI Report Server, patching now is far easier than chasing an active exploit later.

Watch for the next servicing update. The July build includes only the security fix, but future updates will also bundle new features and further quality improvements. Stick to the Microsoft Update channel if you want hands-off patching, or set a reminder to check the Power BI Report Server changelog for the latest build numbers.

The operational lesson from CVE-2026-58647 is clear: don’t trust a feature release label. When a security fix lands, check the exact build number against Microsoft’s advisory. A quick query can keep your reporting environment from becoming an attacker’s doorway.