Repository navigation
[Regression - third occurrence] App-only Sites.FullControl.All writes to TenantWideExtensions fail again across multiple tenants #11062
Description
Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
SharePoint CSOM
Developer environment
None
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
No response
Describe the bug / error
As of 15 October 2026, we are experiencing the same issue described in #10976 again on multiple tenants. This is now the third occurrence of this bug, following the earlier reports and fixes.
Previous reports and confirmed resolution
- Earlier reports: Could not upload SPFx package to some MS365 tenants #10955 and Cannot write to Site Collection TenantWideExtensions List with app-only credentials (ClientId + Certificate) #10963.
- Previous recurrence: [Regression] App-only Sites.FullControl.All cannot create or update TenantWideExtensions after #10955/#10963 fix #10976.
- In this comment on #10976, Microsoft confirmed that an app catalog permission change had caused the issue and had been reverted/disabled.
- I confirmed that the issue was resolved, and [Regression] App-only Sites.FullControl.All cannot create or update TenantWideExtensions after #10955/#10963 fix #10976 was subsequently closed as resolved on 7 September 2026.
The same failure has now returned across multiple tenants.
Actual behavior and impact
App-only access with SharePoint Sites.FullControl.All can read the TenantWideExtensions list, but create/update operations fail with the same permission error documented in #10976:
HttpResponseCode: 500
Code: Microsoft.SharePoint.SPException
Message: Must have Manage Web Site permissions in order to add apps to site collection app catalog
Steps to reproduce
The reproduction is already documented in #10976, including the PowerShell reproduction script.
- Use an Entra ID application with certificate-based authentication and the SharePoint
Sites.FullControl.Allapplication permission, with admin consent granted. - Connect to the tenant app catalog in application context.
- Read the hidden
TenantWideExtensionslist. - Attempt to create a disabled extension entry using the reproduction in [Regression] App-only Sites.FullControl.All cannot create or update TenantWideExtensions after #10955/#10963 fix #10976, or update an existing entry through the production path described there.
- Observe the
Microsoft.SharePoint.SPExceptionrequiringManage Web Sitepermissions.
#10976 contains the original isolated CREATE test and production UPDATE failure, together with the permission and token checks already performed.
Expected behavior
Certificate-based app-only access with the SharePoint Sites.FullControl.All application role and admin consent should be able to create and update entries in the tenant app catalog's TenantWideExtensions list, as it could after the previous fix.
This functionality should continue to work consistently across tenants after SharePoint service updates.
Activity
m365-agent-toolkit-assistant commentedon Oct 15, 2026
👋 Hi Rene Nicolao (@nicolaor),
Thank you for reporting this issue. Here is an AI-generated initial response:
Classification: Bug — The reported app-only write failure is consistent with a recurrence of a previously confirmed SharePoint app-catalog permission defect; the cause of this occurrence is not yet confirmed.
TenantWideExtensionswith a certificate-based SharePointSites.FullControl.Allapplication token, but CREATE/UPDATE returnsMicrosoft.SharePoint.SPExceptionrequiring Manage Web Site. Microsoft’s guidance documents that permission for app-only SharePoint admin access.What to do now:
Useful links:
nicolaor commentedon Oct 15, 2026
Here are the failing request for some of the affected tenants. The Microsoft SharePoint correlation IDs below are the
SPRequestGuidvalues logged by PnP Core asClientRequestId.All timestamps are UTC, converted from Zurich local time (CEST, UTC+02:00).
03c21377-e301-4f02-ae7c-7c10b901a257f2da44a2-0016-f000-2a06-959486afef332026-10-14T17:42:36.765Z31a8ec5e-9da7-4c72-811e-df06f8ff2a8cbcdb44a2-104f-e000-2542-e09c137d111a2026-10-14T17:56:25.096Ze98ad26b-19bb-476a-9e97-83666ecd0839070545a2-3044-9000-9f59-ad6a2cd506512026-10-15T05:58:03.706ZAll three requests failed during an UPDATE of
TenantWideExtensionswith HTTP 500 andMicrosoft.SharePoint.SPException:Ashlesha-MSFT commentedon Oct 16, 2026
Hi Rene Nicolao (@nicolaor),
Thanks for the report and the details. We reproduced this on our end: certificate-based app-only access with SharePoint Sites.FullControl.All can read the TenantWideExtensions list, but creating an item fails with the same error, "Must have Manage Web Site permissions in order to add apps to site collection app catalog." It fails the same way whether we use PnP.PowerShell or call the SharePoint REST API directly.
We're raising a bug with the SharePoint engineering team and will post updates here.
VesaJuvonen commentedon Oct 20, 2026
Thank you Rene Nicolao (@nicolaor) on flagging this and this is indeed quite awkward and has now happened few times without clear communications - that's on Microsoft on dropping the ball on communications and direction with this feature 🙋♂️
Current change has been now reverted and things should be working normally - please confirm 🙏
We are working on a permission change here due a security hardening - to provide specific permission asks for the operations in the app catalog. This change was not however properly communicated which then caused the unexpected issue for you and others. That's on us, which is why the change was now reverted. We will be introducing a change here within upcoming months, with clear communications in blog post and message center update - you can start preparing for that already today: We will be requiring
SharePointTenantSettings.ReadWrite.Allfor any app which is modifying tenant wide extensions - when feature is enabled again (after clear communications),Sites.FullControl.Allis no longer sufficient.We are now working with the owning engineering team to have a clear communication plan and schedule for this change. You'll see an update on that in developer blog and in the message center - with clear dates on when the change is coming.
Let's get the current situation confirmed - everything should work again - and we'll close the issue after that ❓
nicolaor commentedon Oct 20, 2026
Hi Vesa Juvonen (@VesaJuvonen), thanks for addressing this and for the information about the upcoming permission change.
I’ve retested against our tenant and can confirm that creating and updating TenantWideExtensions entries now works again.
Thanks for your help!
nicolaor commentedon Oct 22, 2026
Vesa Juvonen (@VesaJuvonen) Just out of curiosity, will the upcoming permission change only affect TenantWideExtensions or will it also have an impact on uploading items to the app catalog ?
VesaJuvonen commentedon Oct 22, 2026
Rene Nicolao (@nicolaor) - We'll need to get full details on that - most likely it's for the whole app catalog, but working on full confirmation on the setup here. Will be properly communicated before enabled again - to avoid disruption.
bcameron1231 commentedon Oct 22, 2026
Any chance these permission changes could also affect creating new Site Collection App Catalogs? We're seeing instances of 500 errors coming from SharePoint when trying to provision App Catalogs recently.