Repository navigation
[Regression] App-only Sites.FullControl.All cannot create or update TenantWideExtensions after #10955/#10963 fix #10976
Description
Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
SharePoint CSOM
Developer environment
Windows
What browser(s) / client(s) have you tested
- 💥 Internet Explorer
- 💥 Microsoft Edge
- 💥 Google Chrome
- 💥 FireFox
- 💥 Safari
- mobile (iOS/iPadOS)
- mobile (Android)
- not applicable
- other (enter in the "Additional environment details" area below)
Additional environment details
- PowerShell 7.6.3
- PnP.PowerShell 3.1.0
- Authentication: Entra ID application with a certificate
- SharePoint application permission:
Sites.FullControl.All - Admin consent granted
- Tenant app catalog
Describe the bug / error
This appears to be a regression or an incomplete rollout of the fix associated with #10955 and #10963.
#10963 was closed on July 28, 2026 because #10955 was reported as fixed. On August 4, 2026, we reproduced the same failure using a newly created Entra application and certificate against our tenant app catalog.
Our production process fails while updating an existing TenantWideExtensions item through PnP.Core. A separate minimal PnP.PowerShell test also fails while creating a new disabled temporary item. Both operations fail with:
HttpResponseCode: 500
Code: Microsoft.SharePoint.SPException
Message: Must have Manage Web Site permissions in order to add apps to site collection app catalog
For the isolated reproduction we verified all of the following:
- The Entra application had the SharePoint
Sites.FullControl.Allapplication role. - Admin consent was granted.
- The issued SharePoint access token contained the
Sites.FullControl.Allrole. - Certificate-based application authentication succeeded.
- Application context successfully resolved the tenant app catalog.
- Application context successfully read the hidden
TenantWideExtensionslist. - CREATE of a disabled temporary extension failed with the permission exception.
- No list item was created, so the test could not proceed to UPDATE.
Question
Could the SharePoint engineering team confirm whether the fix for #10955 has reached all tenants and whether certificate-based application writes to TenantWideExtensions are still supported with the SharePoint Sites.FullControl.All application role?
The tenant identifiers, full raw transcript, and additional correlation information can be provided privately to Microsoft Support if required.
Steps to reproduce
- Create an Entra ID application and a certificate.
- Grant the application the SharePoint application permission
Sites.FullControl.All. - Grant tenant-wide admin consent.
- Connect to the SharePoint tenant app catalog using the application client ID and certificate.
- Read the hidden
TenantWideExtensionslist to confirm the application context can access it. - Attempt to create a temporary disabled extension entry using a new component GUID, for example:
$values = @{
Title = "App-only TenantWideExtensions repro"
TenantWideExtensionComponentId = [guid]::NewGuid()
TenantWideExtensionComponentProperties = '{"test":"create"}'
TenantWideExtensionLocation = 'ClientSideExtension.ApplicationCustomizer'
TenantWideExtensionDisabled = $true
TenantWideExtensionSequence = 65535
}
Add-PnPListItem -List "TenantWideExtensions" -Values $values -Connection $connection- Observe the HTTP 500
Microsoft.SharePoint.SPException.
Attached is a sample powershell script with which we can reproduce the issue on multiple tenants (all the ones we executed it against actually)
Test-TenantWideExtensionAppOnly.txt
Expected behavior
An Entra application holding the SharePoint Sites.FullControl.All application role should be able to create and update entries in the tenant app catalog's TenantWideExtensions list using certificate-based application context.
Actual behavior
Reading the list succeeds, but a write fails with an error requiring Manage Web Site permission even though the access token contains the SharePoint Sites.FullControl.All application role.
Exact output from the isolated test:
UTC time : 2026-08-04T14:28:57.7830390Z
PowerShell : 7.6.3
PnP.PowerShell : 3.1.0
Auth mode : Entra ID application + certificate
Permission : SharePoint Sites.FullControl.All (application)
Tenant app catalog resolved successfully.
TenantWideExtensions list read succeeded.
CREATE : starting
TEST RESULT : failed
Exception type : System.Exception
Message : Must have Manage Web Site permissions in order to add apps to site collection app catalog
Repro invocation failure: Must have Manage Web Site permissions in order to add apps to site collection app catalog
An occurrence from the production UPDATE operation returned:
HttpResponseCode: 500
Code: Microsoft.SharePoint.SPException
Message: Must have Manage Web Site permissions in order to add apps to site collection app catalog
ClientRequestId: d8ee2da2-e02f-1001-9d1b-20eb20714bb9
SPClientServiceRequestDuration: 97
X-SharePointHealthScore: 1
X-SP-SERVERSTATE: ReadOnly=0
Activity
Ashlesha-MSFT commentedon Aug 6, 2026
Hello Rene Nicolao (@nicolaor)
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.
Ashlesha-MSFT commentedon Aug 6, 2026
Hi Nick Pape (@nick-pape),
Could you please share the current status of this issue from the engineering side?
Developers seeing what appears to be the same behavior again after the mitigation for #10955/#10963. Specifically, app-only authentication with Sites.FullControl.All can successfully read the TenantWideExtensions list but still fails on create/update operations with the following error:
Could you confirm whether:
Any update on the current status or expected timeline would be greatly appreciated. Thank you!
nicolaor commentedon Aug 11, 2026
Following up on this — the issue is still unresolved and is becoming a major concern. We have live features deployed to hundreds of customers that depend on this, so a fix is becoming urgent. Could you please provide an update on the status?
NicolasMCAG commentedon Aug 11, 2026
Any news on this? Thanks.
ximoran-bot commentedon Aug 11, 2026
Facing the same issue. Please share the latest status.
czullu commentedon Aug 11, 2026
Looking forward for an Update on this Issue. Is there a known workaround beside using a service user?
VesaJuvonen commentedon Aug 14, 2026
Hi Rene Nicolao (@nicolaor), Nicolas Pizzorno (@NicolasMCAG), ximoran-bot & Christian Zuellig (@czullu) - This was unfortunate mistake on the permission changes on the app catalog. Change has been now reverted/disabled and would ask for confirmation that the issue is resolved. Thanks for that message advance.
czullu commentedon Aug 14, 2026
nicolaor commentedon Aug 14, 2026
Hi Vesa Juvonen (@VesaJuvonen) I confirm, the issue is resolved now. Thanks!
Ashlesha-MSFT commentedon Sep 7, 2026
As the issue has been confirmed as resolved, we’re closing this issue.