Microsoft has published CVE-2026-59118, an elevation-of-privilege vulnerability in Power Apps, but the advisory currently gives Power Platform administrators no build number, CVSS score, exploitability assessment, workaround, affected-feature list, or customer-installable patch to verify. The practical response is therefore to treat it as a cloud-service security change, confirm which Power Apps and Dataverse environments are business-critical, and watch the Power Platform admin center and Microsoft 365 Message Center for rollout notices rather than searching Windows Update or WSUS for a KB package.
The advisory appeared in Microsoft’s Security Update Guide on Thursday, August 6, 2026, at 7:00 a.m. Pacific time. Microsoft classifies the issue as “Microsoft Power Apps Elevation of Privilege Vulnerability.” That establishes the product area and impact category, but the record is unusually sparse at publication: Microsoft has not publicly described the vulnerable component, the permissions an attacker would need, whether cross-tenant access is possible, or whether exploitation occurred before disclosure.
For Windows administrators, the immediate point is simple: CVE-2026-59118 is not evidence of a missing Windows security update. Power Apps is primarily delivered as part of Microsoft’s managed Power Platform service. A Power Apps tenant can be affected even where every Windows endpoint is fully current, and a fully patched PC estate does not provide a useful remediation signal for this advisory.
Microsoft’s Security Update Guide is the authoritative primary record for the CVE, and it confirms the vulnerability’s existence and elevation-of-privilege impact. Yet the advisory does not currently identify an affected Power Apps release, a Power Platform environment build, a Power Apps Studio version, a player version, a Dataverse version, or a Knowledge Base article.
That gap has consequences. With a Windows CVE, an administrator can generally map an advisory to a cumulative update, build revision, servicing channel, or standalone package. With this Power Apps advisory, there is no equivalent “install this KB” instruction. The absence of a listed update package strongly indicates that Microsoft is handling remediation in the hosted service rather than asking customers to patch a local product installation.
Microsoft’s own Power Platform documentation describes a servicing model built around regular managed updates. Minor service updates are deployed weekly, region by region, and applied to customer environments asynchronously during regional maintenance windows. Microsoft also says that the date it applies a deployment to infrastructure is not necessarily the date the update reaches an individual environment. In other words, the August 6 publication date is a disclosure date, not proof that every Power Apps environment received the fix at the same time.
Microsoft has not stated the rollout scope for CVE-2026-59118. It has not said whether the fix is already global, moving through staged deployment stations, limited to particular geographies, or awaiting a future maintenance window. Administrators should avoid recording the advisory as “remediated” merely because Microsoft published it.
Those omissions should not be read as proof of low risk. “Elevation of privilege” covers a wide range of outcomes: gaining additional rights inside one app, becoming an environment-level administrator, accessing records beyond a user’s intended scope, or obtaining privileges that can be used to alter apps, connections, flows, or data. The distinction depends on the vulnerable service boundary, and Microsoft has not identified that boundary.
The advisory also does not say whether exploitation requires an authenticated Power Apps user, a maker role, a specific connector configuration, access to a model-driven app, or interaction with an application controlled by another user. Those are the facts that determine whether the issue belongs in a routine service-change queue or demands immediate incident review.
The supplied description accompanying the advisory discusses confidence in the vulnerability’s existence and the credibility of available technical detail. That language does not fill in the missing technical record. Microsoft’s publication is vendor confirmation that the vulnerability exists. It does not supply enough public information to independently validate an exploit path, assess preconditions, or reproduce the condition.
Exact-identifier searches of the public National Vulnerability Database and CVE Program record systems did not surface a corresponding independently detailed record on August 6. CISA’s Known Exploited Vulnerabilities catalog likewise did not return CVE-2026-59118. That is common on the first day of a Microsoft cloud-service disclosure, particularly when the vendor’s own entry is the only available technical source, but it means there is presently no independent public enrichment to rely on for severity, exploitation status, or remediation status.
This creates an evidence problem for security teams. A Power Platform administrator may see a normal environment build update after the CVE’s disclosure, but Microsoft has not associated CVE-2026-59118 with a particular build. That means build observation alone cannot prove that an environment has received the security remediation.
Microsoft’s public Power Apps release notes add little clarity. Recent portal and Power Apps Studio/player release entries frequently state that no specific fixes or improvements have been publicly disclosed. That is not evidence that a security fix was absent; it is evidence that normal product release notes are an incomplete substitute for Security Update Guide records and tenant-specific service communications.
The controls available to an administrator are therefore administrative and detective rather than patch-deployment controls:
Start with environments where makers can create or modify apps that use privileged service accounts, shared connections, premium connectors, on-premises data gateways, Azure resources, SharePoint sites, Exchange mailboxes, SQL databases, or business-critical Dataverse tables. Focus especially on shared credentials and ownership arrangements that blur accountability. A Power App may be shared with a large user population while its connection or flow runs under an account with much broader rights than an ordinary end user possesses.
This does not mean CVE-2026-59118 involves connectors, gateways, Dataverse, or service principals. Microsoft has not said that it does. The point is narrower: those dependencies are the places where a confirmed privilege escalation could have the greatest business effect, so they are the right places to validate least privilege while the technical details remain unavailable.
Organizations using managed environments should also verify that governance controls are active where licensing permits them. Microsoft lists capabilities such as data policies, IP Firewall, IP cookie binding, solution checker, pipelines, customer-managed keys, and Lockbox among managed-environment features. None should be presented as a Microsoft-approved mitigation for this CVE; no mitigation has been published. They are relevant because they can constrain exposure and improve accountability across a large Power Platform deployment.
The appropriate owner is the Power Platform or Microsoft 365 service administrator, with security operations involved if the organization has high-value Power Apps environments or reports of unusual privilege behavior. The closure criterion should be explicit: confirmation through Microsoft’s tenant communications or subsequent advisory revisions that the service remediation is complete for the organization’s environments. Until Microsoft adds affected versions, rollout information, mitigation guidance, or technical details, any stronger claim of local remediation would be unsupported by the public record.
Microsoft has confirmed the vulnerability, but it has not yet told customers enough to measure its severity or verify its deployment status. For now, the concrete task is to preserve evidence, reduce unnecessary Power Platform privilege, and track the advisory for the details that determine whether CVE-2026-59118 was a narrow service defect or a meaningful tenant-administration risk.
For Windows administrators, the immediate point is simple: CVE-2026-59118 is not evidence of a missing Windows security update. Power Apps is primarily delivered as part of Microsoft’s managed Power Platform service. A Power Apps tenant can be affected even where every Windows endpoint is fully current, and a fully patched PC estate does not provide a useful remediation signal for this advisory.
Microsoft’s advisory confirms the issue but withholds the operational details
Microsoft’s Security Update Guide is the authoritative primary record for the CVE, and it confirms the vulnerability’s existence and elevation-of-privilege impact. Yet the advisory does not currently identify an affected Power Apps release, a Power Platform environment build, a Power Apps Studio version, a player version, a Dataverse version, or a Knowledge Base article.That gap has consequences. With a Windows CVE, an administrator can generally map an advisory to a cumulative update, build revision, servicing channel, or standalone package. With this Power Apps advisory, there is no equivalent “install this KB” instruction. The absence of a listed update package strongly indicates that Microsoft is handling remediation in the hosted service rather than asking customers to patch a local product installation.
Microsoft’s own Power Platform documentation describes a servicing model built around regular managed updates. Minor service updates are deployed weekly, region by region, and applied to customer environments asynchronously during regional maintenance windows. Microsoft also says that the date it applies a deployment to infrastructure is not necessarily the date the update reaches an individual environment. In other words, the August 6 publication date is a disclosure date, not proof that every Power Apps environment received the fix at the same time.
Microsoft has not stated the rollout scope for CVE-2026-59118. It has not said whether the fix is already global, moving through staged deployment stations, limited to particular geographies, or awaiting a future maintenance window. Administrators should avoid recording the advisory as “remediated” merely because Microsoft published it.
The missing CVSS score limits risk prioritization
The Security Update Guide page currently does not provide a CVSS score or vector for CVE-2026-59118. Microsoft also has not publicly marked the issue as exploited or publicly disclosed before release, and it has not supplied a Microsoft Exploitability Index assessment.Those omissions should not be read as proof of low risk. “Elevation of privilege” covers a wide range of outcomes: gaining additional rights inside one app, becoming an environment-level administrator, accessing records beyond a user’s intended scope, or obtaining privileges that can be used to alter apps, connections, flows, or data. The distinction depends on the vulnerable service boundary, and Microsoft has not identified that boundary.
The advisory also does not say whether exploitation requires an authenticated Power Apps user, a maker role, a specific connector configuration, access to a model-driven app, or interaction with an application controlled by another user. Those are the facts that determine whether the issue belongs in a routine service-change queue or demands immediate incident review.
The supplied description accompanying the advisory discusses confidence in the vulnerability’s existence and the credibility of available technical detail. That language does not fill in the missing technical record. Microsoft’s publication is vendor confirmation that the vulnerability exists. It does not supply enough public information to independently validate an exploit path, assess preconditions, or reproduce the condition.
Exact-identifier searches of the public National Vulnerability Database and CVE Program record systems did not surface a corresponding independently detailed record on August 6. CISA’s Known Exploited Vulnerabilities catalog likewise did not return CVE-2026-59118. That is common on the first day of a Microsoft cloud-service disclosure, particularly when the vendor’s own entry is the only available technical source, but it means there is presently no independent public enrichment to rely on for severity, exploitation status, or remediation status.
Power Platform’s rollout model changes what admins can verify
Power Platform updates do not move in the same manner as a monthly Windows cumulative update. Microsoft says service fixes and improvements are deployed on a weekly cadence, region by region, with customer environments updated through subsequent maintenance windows. The company’s documentation also notes that an environment’s maintenance can occur on any day, although production customers can manage the preferred window for relevant application and database changes.This creates an evidence problem for security teams. A Power Platform administrator may see a normal environment build update after the CVE’s disclosure, but Microsoft has not associated CVE-2026-59118 with a particular build. That means build observation alone cannot prove that an environment has received the security remediation.
Microsoft’s public Power Apps release notes add little clarity. Recent portal and Power Apps Studio/player release entries frequently state that no specific fixes or improvements have been publicly disclosed. That is not evidence that a security fix was absent; it is evidence that normal product release notes are an incomplete substitute for Security Update Guide records and tenant-specific service communications.
The controls available to an administrator are therefore administrative and detective rather than patch-deployment controls:
- Review the Microsoft 365 Message Center and Power Platform admin center for notices tied to affected production and sandbox environments.
- Record each critical environment’s region, environment type, current build information where available, primary owners, Dataverse usage, and reliance on sensitive connectors.
- Verify that the smallest possible set of users hold Power Platform administrator, Dynamics 365 administrator, System Administrator, Environment Maker, and equivalent high-impact roles.
- Review recently created connections, custom connectors, application shares, role assignments, and solution imports in environments that hold regulated, financial, HR, customer, or operational data.
- Preserve relevant audit data before normal retention processes remove evidence, especially if suspicious app modifications, unexpected privilege grants, or unusual data access have been reported.
Privilege reviews are the only immediate customer-side action
The most useful near-term work is to examine the privileges that would amplify an elevation-of-privilege event. In Power Apps, a user’s effective reach may involve environment roles, Dataverse security roles, application sharing, Microsoft Entra identity groups, connector permissions, service principals, connection references, and downstream data sources. A vulnerability in one layer can matter more when the surrounding application is already allowed to act with broad access.Start with environments where makers can create or modify apps that use privileged service accounts, shared connections, premium connectors, on-premises data gateways, Azure resources, SharePoint sites, Exchange mailboxes, SQL databases, or business-critical Dataverse tables. Focus especially on shared credentials and ownership arrangements that blur accountability. A Power App may be shared with a large user population while its connection or flow runs under an account with much broader rights than an ordinary end user possesses.
This does not mean CVE-2026-59118 involves connectors, gateways, Dataverse, or service principals. Microsoft has not said that it does. The point is narrower: those dependencies are the places where a confirmed privilege escalation could have the greatest business effect, so they are the right places to validate least privilege while the technical details remain unavailable.
Organizations using managed environments should also verify that governance controls are active where licensing permits them. Microsoft lists capabilities such as data policies, IP Firewall, IP cookie binding, solution checker, pipelines, customer-managed keys, and Lockbox among managed-environment features. None should be presented as a Microsoft-approved mitigation for this CVE; no mitigation has been published. They are relevant because they can constrain exposure and improve accountability across a large Power Platform deployment.
Do not convert this into a Windows patch-compliance exception
Endpoint-management teams should document CVE-2026-59118 separately from Windows, Microsoft 365 Apps, and server patch compliance. There is no listed KB number, no Windows build number, and no Microsoft Update Catalog package associated with the advisory. Adding the CVE to a WSUS or Intune update-reporting workflow will produce an administrative dead end: those systems cannot confirm deployment of a fix Microsoft is applying to the service.The appropriate owner is the Power Platform or Microsoft 365 service administrator, with security operations involved if the organization has high-value Power Apps environments or reports of unusual privilege behavior. The closure criterion should be explicit: confirmation through Microsoft’s tenant communications or subsequent advisory revisions that the service remediation is complete for the organization’s environments. Until Microsoft adds affected versions, rollout information, mitigation guidance, or technical details, any stronger claim of local remediation would be unsupported by the public record.
Microsoft has confirmed the vulnerability, but it has not yet told customers enough to measure its severity or verify its deployment status. For now, the concrete task is to preserve evidence, reduce unnecessary Power Platform privilege, and track the advisory for the details that determine whether CVE-2026-59118 was a narrow service defect or a meaningful tenant-administration risk.
References
- Primary source: MSRC
Published: 2026-08-06T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: learn.microsoft.com
Power Apps version 26064 - Release Notes | Microsoft Learn
Version 26064 for Power Apps is now available in all regions. This article describes the updates, including the new features, and the fixes to existing functionality, which are included in this update.learn.microsoft.com - Related coverage: learn.microsoft.com
Power Apps version 26061 - Release Notes | Microsoft Learn
Version 26061 for Power Apps is now available in all regions. This article describes the updates, including the new features, and the fixes to existing functionality, which are included in this update.learn.microsoft.com - Related coverage: github.com
GitHub - microsoft/MSRC-Microsoft-Security-Updates-API: Repo with getting started projects for the Microsoft Security Updates API (msrc.microsoft.com/update-guide) · GitHub
Repo with getting started projects for the Microsoft Security Updates API (msrc.microsoft.com/update-guide) - microsoft/MSRC-Microsoft-Security-Updates-API
github.com
- Related coverage: msrc.microsoft.com
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: microsoft.com
Security Update Guide FAQs
Frequently asked questions on the Security Update Guidewww.microsoft.com
- Related coverage: microsoft.com
continuing-to-listen-good-news-about-the-security-update-guide-api
- Related coverage: github.com
Provide an API to get the CVRF for a single CVE (previously worked in old portal site) · Issue #94 · microsoft/MSRC-Microsoft-Security-Updates-API · GitHub
The old endpoints around the portal api used to provide a nice clean lookup by CVE: https://portal.msrc.microsoft.com/api/security-guidance/en-us/CVE/ Response: CVRF response in json or xml based on the headers used for the request. ie: ...
github.com
- Related coverage: deepwiki.com
MSRC API Reference | microsoft/MSRC-Microsoft-Security-Updates-API | DeepWiki
This document provides technical reference information for the Microsoft Security Response Center (MSRC) CVRF API that underlies the MsrcSecurityUpdates PowerShell module. This covers the REST API enddeepwiki.com - Related coverage: evs.com
- Related coverage: windowscentral.com
Microsoft Office Critical Security Flaws: How to Fix Them | Windows Central
Microsoft\u2019s March Patch Tuesday addresses two critical Office vulnerabilities, but don't let the "local access" label fool you into skipping these updates.www.windowscentral.com - Related coverage: vulnerabilities.ncsc.nl
- Related coverage: vulnerabilities.ncsc.nl
- Related coverage: cyber.gc.ca
Microsoft security advisory (AV26-489) - Canadian Centre for Cyber Security
Microsoft security advisory (AV26-489)www.cyber.gc.ca - Related coverage: linkedin.com
Announcing the CVRF API 3.0 upgrade | Microsoft Security Response Center
CVRF API 3.0 is here! It's faster and more secure. Update your PowerShell module with a few simple commands for an improved experience. Learn more in our blog post: https://lnkd.in/gws23XaHwww.linkedin.com
- Related coverage: advisories.ncsc.nl
- Related coverage: cert.europa.eu
- Related coverage: cirt.gy
- Related coverage: sra.io