Microsoft has fixed CVE-2026-58647, an Important-rated cross-site scripting vulnerability in Power BI Report Server that could let an authenticated attacker place deceptive content in another user’s browser session. Administrators should upgrade every affected server to build 15.0.1121.120 or later, including systems running older Power BI Report Server release branches.
Published by the Microsoft Security Response Center on July 14, 2026, the vulnerability carries a CVSS 3.1 base score of 8.0. Microsoft describes the impact as spoofing, but the underlying weakness is CWE-79: improper neutralization of input during web-page generation, better known as cross-site scripting or XSS.
The July 2026 security release identifies Power BI Report Server versions from 1.6.0 through builds earlier than 15.0.1121.120 as affected. Microsoft released the corrected May 2026 servicing build, version 1.26.9682.1442, on July 8—six days before publishing the CVE.
CVE-2026-58647 is not an unauthenticated server takeover. Microsoft’s CVSS vector says an attacker needs low-level privileges, can conduct the attack over a network, and must persuade another user to interact with the malicious content.
Those requirements produce the vector AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H. In practical terms, exploitation is remotely reachable and considered low complexity, but the attacker must already have some authorized access to Power BI Report Server and needs a victim to open or interact with affected content.
The high confidentiality, integrity, and availability impact ratings are why the score reaches 8.0 despite those prerequisites. Successfully executing attacker-controlled script within the Report Server portal could allow the content to operate in the security context of the targeted user’s browser session.
That distinction matters in enterprise deployments. A low-privilege report author, contractor, or compromised internal account may not have administrative access, but a crafted report or portal object could be presented to someone who does. The browser sees content delivered by the organization’s trusted Power BI Report Server, making malicious interface elements or prompts harder to distinguish from legitimate ones.
A spoofing classification can therefore sound less urgent than the technical condition warrants. Zero Day Initiative’s July security review characterized the issue as a Power BI Report Server XSS flaw and noted that it was neither publicly disclosed nor known to be exploited when Microsoft released the update.
Earlier May 2026 builds remain below the fixed boundary. These include 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. Administrators who installed the May 2026 feature release or one of its first maintenance updates are therefore not necessarily protected.
The January 2026 branch is also affected because its latest documented builds use the 15.0.1120 series. The same applies to September 2025, May 2025, and older supported installations that have not been brought forward to the corrected release.
This makes checking the actual build more reliable than checking whether a deployment was “recently updated.” An inventory entry that merely says “Power BI Report Server May 2026” does not establish that CVE-2026-58647 has been addressed.
Administrators should confirm that the installed server reports both of the following values or something newer:
That reduces the immediate emergency compared with July’s actively exploited Microsoft vulnerabilities, but it does not remove the operational case for prompt patching. Power BI Report Server is commonly used to place business intelligence, financial reporting, operational dashboards, and paginated reports behind an organization’s firewall. The users viewing those reports may have access to substantially more sensitive information than the account needed to submit malicious content.
The requirement for an authorized attacker should be interpreted as an access boundary, not a guarantee of trust. Enterprise reporting servers can include large populations of report publishers, analysts, service accounts, external consultants, and business-unit administrators. Compromising any one of those identities could give an outside attacker the initial privileges described by Microsoft’s scoring.
User interaction is similarly contextual. It may require nothing more suspicious than opening a shared report, following an internal portal link, or interacting with a page that appears to belong to the organization. Report portals are designed to encourage precisely that behavior.
Administrators should pay particular attention to servers exposed through reverse proxies, VPN portals, Microsoft Entra application proxies, or public-facing authentication gateways. Authentication may prevent anonymous exploitation, but it also places the vulnerable application within reach of stolen credentials and authenticated external partners.
The upgrade should still follow normal Report Server change controls. Back up the report server databases and encryption key, record custom authentication extensions and configuration changes, and test important reports, subscriptions, scheduled refreshes, embedded integrations, and scale-out nodes after installation.
A scale-out deployment requires special attention because leaving one web-front-end node on a vulnerable build can preserve an exploitation path. Load balancer health checks may show that every node is responding without revealing that they are running different Power BI Report Server builds.
After patching, security teams should review accounts permitted to create, upload, modify, or manage report content. That review will not replace the update, but it can reduce the pool of identities capable of reaching the vulnerability’s low-privilege prerequisite.
Browser and proxy telemetry may also provide useful evidence if administrators suspect prior abuse. Unexpected script execution, unusual report links sent to privileged users, newly created content from dormant publisher accounts, or anomalous portal activity deserve investigation. Microsoft has not published exploit-specific indicators, so these checks are behavioral rather than definitive.
The wording supplied under “Report Confidence” in Microsoft’s advisory is the standard CVSS explanation of that metric, not evidence that CVE-2026-58647 remains hypothetical. Microsoft is the assigning authority, has published affected-version data, and has provided an official corrected build; the vulnerability’s report confidence is effectively confirmed.
For Power BI Report Server operators, the actionable dividing line is unambiguous: servers below 15.0.1121.120 remain exposed, even if they already carry an earlier May 2026 update. The next maintenance window should end with a build check on every node—not merely confirmation that an installer ran.
Published by the Microsoft Security Response Center on July 14, 2026, the vulnerability carries a CVSS 3.1 base score of 8.0. Microsoft describes the impact as spoofing, but the underlying weakness is CWE-79: improper neutralization of input during web-page generation, better known as cross-site scripting or XSS.
The July 2026 security release identifies Power BI Report Server versions from 1.6.0 through builds earlier than 15.0.1121.120 as affected. Microsoft released the corrected May 2026 servicing build, version 1.26.9682.1442, on July 8—six days before publishing the CVE.
Spoofing Here Means Untrusted Code in a Trusted Portal
CVE-2026-58647 is not an unauthenticated server takeover. Microsoft’s CVSS vector says an attacker needs low-level privileges, can conduct the attack over a network, and must persuade another user to interact with the malicious content.Those requirements produce the vector AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H. In practical terms, exploitation is remotely reachable and considered low complexity, but the attacker must already have some authorized access to Power BI Report Server and needs a victim to open or interact with affected content.
The high confidentiality, integrity, and availability impact ratings are why the score reaches 8.0 despite those prerequisites. Successfully executing attacker-controlled script within the Report Server portal could allow the content to operate in the security context of the targeted user’s browser session.
That distinction matters in enterprise deployments. A low-privilege report author, contractor, or compromised internal account may not have administrative access, but a crafted report or portal object could be presented to someone who does. The browser sees content delivered by the organization’s trusted Power BI Report Server, making malicious interface elements or prompts harder to distinguish from legitimate ones.
A spoofing classification can therefore sound less urgent than the technical condition warrants. Zero Day Initiative’s July security review characterized the issue as a Power BI Report Server XSS flaw and noted that it was neither publicly disclosed nor known to be exploited when Microsoft released the update.
Build 15.0.1121.120 Draws the Security Boundary
Microsoft’s affected-version data places the correction at build 15.0.1121.120. That build corresponds to Power BI Report Server May 2026 version 1.26.9682.1442, released on July 8, 2026.Earlier May 2026 builds remain below the fixed boundary. These include 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. Administrators who installed the May 2026 feature release or one of its first maintenance updates are therefore not necessarily protected.
The January 2026 branch is also affected because its latest documented builds use the 15.0.1120 series. The same applies to September 2025, May 2025, and older supported installations that have not been brought forward to the corrected release.
This makes checking the actual build more reliable than checking whether a deployment was “recently updated.” An inventory entry that merely says “Power BI Report Server May 2026” does not establish that CVE-2026-58647 has been addressed.
Administrators should confirm that the installed server reports both of the following values or something newer:
- The Power BI Report Server product version should be 1.26.9682.1442 or later.
- The corresponding server build should be 15.0.1121.120 or later.
Authentication Lowers Exposure, Not the Cost of Compromise
Microsoft assesses exploitation as less likely, and the vulnerability was not listed as publicly disclosed or exploited on July 14. There was also no public proof-of-concept accompanying the advisory.That reduces the immediate emergency compared with July’s actively exploited Microsoft vulnerabilities, but it does not remove the operational case for prompt patching. Power BI Report Server is commonly used to place business intelligence, financial reporting, operational dashboards, and paginated reports behind an organization’s firewall. The users viewing those reports may have access to substantially more sensitive information than the account needed to submit malicious content.
The requirement for an authorized attacker should be interpreted as an access boundary, not a guarantee of trust. Enterprise reporting servers can include large populations of report publishers, analysts, service accounts, external consultants, and business-unit administrators. Compromising any one of those identities could give an outside attacker the initial privileges described by Microsoft’s scoring.
User interaction is similarly contextual. It may require nothing more suspicious than opening a shared report, following an internal portal link, or interacting with a page that appears to belong to the organization. Report portals are designed to encourage precisely that behavior.
Administrators should pay particular attention to servers exposed through reverse proxies, VPN portals, Microsoft Entra application proxies, or public-facing authentication gateways. Authentication may prevent anonymous exploitation, but it also places the vulnerable application within reach of stolen credentials and authenticated external partners.
Patch First, Then Review Who Can Publish
Microsoft has not documented a configuration workaround in the public CVE information. The defensible remediation is therefore to install the corrected Power BI Report Server release rather than trying to block individual request patterns at a web application firewall.The upgrade should still follow normal Report Server change controls. Back up the report server databases and encryption key, record custom authentication extensions and configuration changes, and test important reports, subscriptions, scheduled refreshes, embedded integrations, and scale-out nodes after installation.
A scale-out deployment requires special attention because leaving one web-front-end node on a vulnerable build can preserve an exploitation path. Load balancer health checks may show that every node is responding without revealing that they are running different Power BI Report Server builds.
After patching, security teams should review accounts permitted to create, upload, modify, or manage report content. That review will not replace the update, but it can reduce the pool of identities capable of reaching the vulnerability’s low-privilege prerequisite.
Browser and proxy telemetry may also provide useful evidence if administrators suspect prior abuse. Unexpected script execution, unusual report links sent to privileged users, newly created content from dormant publisher accounts, or anomalous portal activity deserve investigation. Microsoft has not published exploit-specific indicators, so these checks are behavioral rather than definitive.
The wording supplied under “Report Confidence” in Microsoft’s advisory is the standard CVSS explanation of that metric, not evidence that CVE-2026-58647 remains hypothetical. Microsoft is the assigning authority, has published affected-version data, and has provided an official corrected build; the vulnerability’s report confidence is effectively confirmed.
For Power BI Report Server operators, the actionable dividing line is unambiguous: servers below 15.0.1121.120 remain exposed, even if they already carry an earlier May 2026 update. The next maintenance window should end with a build check on every node—not merely confirmation that an installer ran.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Official source: learn.microsoft.com
Change log for Power BI Report Server - Power BI | Microsoft Learn
This change log is for Power BI Report Server and lists new items along with bug fixes for each released build.learn.microsoft.com - Related coverage: sqlserverversions.com
- Related coverage: wordfence.com
