SharePoint security fixes released with July 2026 PU and offered through Microsoft Update

33 Comments

1. 

   Mahesh
   On 22. July 2026 Permalink

   Dear Stefan,
   Good Morning !

   For Critical SharePoint REC CVE- 2026-50522,reported today. Can you please check and let me know July 14 patches are suitable for this Vulnerability or any other patches will release by Microsoft.

   Regards,
   Mahesh D

   Reply
   1. 

      Stefan Goßner
      On 22. July 2026 Permalink

      Hi Mahesh,
      yes – see here:
      https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2026-50522
      Cheers,
      Stefan

      Reply
2. 

   Andre F.
   On 27. July 2026 Permalink

   Hi Stefan, related to the July (or recent) SharePoint Subscription CU, this past weekend, we were unable to complete our migration from SP16 to SPSE.

   We ran into an issue accessing any app we newly deployed to the app catalog.

   Our research indicates issues with Safe Controls, along with ULS errors containing “WebPartPageUserException. This page has encountered a critical error”

   I realize there were security enhancements, but how do we resolve this, if you are familiar?

   Anything to do woth:
   AddGenericAllowedListValue(“AllowedTagPrefixesWhichAreNotWebControlsList?

   Insight is VERY MUCH appreciated!

   Reply
   1. 

      Stefan Goßner
      On 27. July 2026 Permalink

      Hi Andre,
      my recommendation would be to analyze the ULS log and share the specific log entries (including event tags and detailed messages)
      Cheers,
      Stefan

      Reply
      1. 

         Andre F.
         On 27. July 2026 Permalink

         Thank you Stefan — the specific ULS entries after the APP/Addin generates the UI error is:

         Microsoft.SharePoint.WebPartPages.WebPartPageUserException: This page has encountered a critical error. Contact your system administrator if this problem persists.
         at Microsoft.SharePoint.ApplicationRuntime.SafeControls.IsSafeControl(Boolean isAppWeb, String virtualPath)
         at Microsoft.SharePoint.ApplicationRuntime.SPPageParserFilter.AllowVirtualReference(String referenceVirtualPath, VirtualReferenceType referenceType)
         at System.Web.UI.BaseTemplateParser.GetReferencedType(VirtualPath virtualPath, Boolean allowNoCompile)
         at System.Web.UI.BaseTemplateParser.GetUserControlType(VirtualPath virtualPath)
         at System.Web.UI.MainTagNameToTypeMapper.ProcessUserControlRegistration(UserControlRegisterEntry ucRegisterEntry)
         at System.Web.UI.BaseTemplateParser.ProcessDirective(String directiveName, IDictionary directive)
         at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding)

         Have tried to apply the below, to no avail — but this seems to point at recent CU updates:

         $f=Get-SPFarm;
         “asp”,”SharePoint”,”Utilities”,”WebPartPages”,”wssuc” | % { $f.AddGenericAllowedListValue(“AllowedTagPrefixesWhichAreNotWebControlsList”,$_) };
         $f.Update();

         iisreset /noforce

         Reply
         1. 

            Stefan Goßner
            On 27. July 2026 Permalink

            Hi Andre,
            thanks!
            This is the last and final ULS log entry – there should be one or more with a specific information which control got rejected.

            For SPSE at least the following settings need to be applied:

            Farm setting:

            // add required entry
            PS C:> $farm = Get-SPFarm
            PS C:> $farm.AddGenericAllowedListValue(“AllowedTagPrefixesWhichAreNotWebControlsList”, “xsl:template”)
            PS C:> $farm.Update()

            Entry the web.config:

            <SafeControl Assembly=”Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” Namespace=”Microsoft.SharePoint.WebPartPages” TypeName=”DataFormParameter” Safe=”True”
            AllowPropertiesTraversal=”True” />

            If this is not sufficient you need to check the ULS log for specific entries before the one you showed in the same correlation which highlights the controls or control elements it rejects to allow-list them.

            Cheers,
            Stefan

            Reply
            1. 

               Andre F.
               On 27. July 2026 Permalink

               Thanks Stefan, gave this a go, and moved to another error. Here is the first ULS entry on this one:

               Safe mode did not start successfully. Microsoft.SharePoint.WebPartPages.WebPartPageUserException: This page has encountered a critical error. Contact your system administrator if this problem persists.
               at Microsoft.SharePoint.ApplicationRuntime.SafeControlsList.GetSafeControlsListFromPath(SPWebApplication app, SPUrlZone zone)
               at Microsoft.SharePoint.ApplicationRuntime.SafeControlsList..ctor(SPWebApplication app, SPUrlZone zone)
               at Microsoft.SharePoint.ApplicationRuntime.SafeControls..ctor(SPWebApplication app, SPUrlZone zone)

               Followed by:

               Getting Error Message for Exception System.Web.HttpParseException (0x80004005): This page has encountered a critical error. Contact your system administrator if this problem persists. —> System.Web.HttpParseException (0x80004005): This page has encountered a critical error. Contact your system administrator if this problem persists. —> Microsoft.SharePoint.WebPartPages.WebPartPageUserException: This page has encountered a critical error. Contact your system administrator if this problem persists.
               at Microsoft.SharePoint.ApplicationRuntime.SafeControls.IsSafeControl(Boolean isAppWeb, String virtualPath)
               at Microsoft.SharePoint.ApplicationRuntime.SPPageParserFilter.AllowVirtualReference(String referenceVirtualPath, VirtualReferenceType referenceType)
               at System.Web.UI.BaseTemplateParser.GetReferencedType(VirtualPath virtualPath, Boolean allowNoCompile)
               at System.Web.UI.BaseTemplateParser.GetUserControlType(VirtualPath virtualPath)
               at System.Web.UI.MainTagNameToTypeMapper.ProcessUserControlRegistration(UserControlRegisterEntry ucRegisterEntry)
               at System.Web.UI.BaseTemplateParser.ProcessDirective(String directiveName, IDictionary directive)
               at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding)
               at System.Web.UI.TemplateParser.ProcessException(Exception ex)
               at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding)
               at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding)
               at System.Web.UI.TemplateParser.ProcessException(Exception ex)
               at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding)
               at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding)
               at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath)
               at System.Web.UI.TemplateParser.ParseInternal()
               at System.Web.UI.TemplateParser.Parse()
               at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType()
               at System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(BuildProvider buildProvider)
               at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders()
               at System.Web.Compilation.BuildProvidersCompiler.PerformBuild()
               at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath)
               at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
               at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
               at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean throwIfNotFound)
               at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp)
               at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
               at System.Web.HttpApplication.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
               at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
               at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

            2. 

               Stefan Goßner
               On 27. July 2026 Permalink

               Hi Andre,
               important would be to look at ULS log entries BEFORE these entries which – usually – highlight which controls or control elements are causing the problem.
               Cheers,
               Stefan

3. 

   Noorul Ahmed
   On 28. July 2026 Permalink

   Hi,
   We have performed the upgrade for Sharepoint 2019 with the latest patches KB5002883/KB5002885. Post installation, we started to receive error messages in the Event Viewer that the timer service is unable to access the Logs folder and we received the errors in the event viewer as follows:

   The Execute method of job definition Microsoft.SharePoint.Administration.SPUsageImportJobDefinition (ID a6020e4c-fb20-4a78-b031-c9b63deff49d) threw an exception. More information is included below.

   Access to the path ‘C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\LOGS’ is denied.. (Correlation=44582ba2-f62c-400f-49c5-8af21b1ee825)

   We have manually applied the permissions again, and this issue went away. Is this a common issue and can we fix it automatically post patch update?

   Waiting for your advice.

   Regards,

   Reply
   1. 

      Stefan Goßner
      On 28. July 2026 Permalink

      Hi Noorul,
      I have not seen any reports for this issue.
      What permissions did you have to add?
      Cheers,
      Stefan

      Reply
   2. 

      Andre F.
      On 28. July 2026 Permalink

      We experienced this in SPSE for all servers as well. We added Modify permissions for the WSS_WPG group to the default SharePoint logs folder to resolve.

      Reply
      1. 

         Stefan Goßner
         On 28. July 2026 Permalink

         Hi Andre,
         this is interesting. WSS_WPG has read and write permission in my farms on the LOGS folder in the SPSE installation und
         c:\program files\common files\microsoft shared\web server extensions\16\LOGS

         Did you maybe configure a different LOGS directory?
         Cheers,
         Stefan

         Reply
         1. 

            Andre F.
            On 28. July 2026 Permalink

            Hi Stefan, can confirm this is the correct folder we had to add modify permissions for that group, and we saw ULS errors gone, and the logs correctly writing.

            C:\Program Files\common files\microsoft shared\web server extensions\16\LOGS

            Reply
            1. 

               Stefan Goßner
               On 28. July 2026 Permalink

               Hi Andre,
               in general there should not be a need to modify permissions.
               On my farms with July 2026 CU the WSS_WPG and the WSS_ADMIN_WPG groups already have read and write permissions.
               If one of these permissions is missing, then you should add them – but would be interesting to understand why they got lost.
               Cheers,
               Stefan

4. 

   Noorul Ahmed
   On 28. July 2026 Permalink

   We added read-write and execute permissions for on the Logs folder for the service account running the timer service. It appeared on all the SP 2019 servers.

   Reply
   1. 

      Stefan Goßner
      On 28. July 2026 Permalink

      Hi Noorul,
      why did you have to add execute permissions?
      This directory should not contain any executables.
      Cheers,
      Stefan

      Reply
   2. 

      Stefan Goßner
      On 28. July 2026 Permalink

      Hi Noorul,

      the WSS_ADMIN_WPG group should already have Read and Write permissions on this directory. Additionally, the farm service account – which is configured to run both the SharePoint Timer Service and the Central Administration application pool – must be a member of this group.

      My recommendation would be to verify your configuration based on this.

      Cheers,
      Stefan

      Reply
      1. 

         Noorul Ahmed
         On 29. July 2026 Permalink

         Thanks, I ll check that.

         Reply
      2. 

         Noorul Ahmed
         On 30. July 2026 Permalink

         Hi,
         We checked the farm, the access for WSS_ADMIN_WPG group to the logs folder was removed post patching activity. We manually added it back.

         Regards,
         Noorul Ahmed

         Reply
5. 

   Andre F.
   On 28. July 2026 Permalink

   Stefan, circling back on the issue we were having with the apps not working in our SPSE environment. Our development team found an older post/fix in the January 2022 (KB5010126) CU for SP16.

   This settings is configured for our SP16 farm (but not in SPSE):
   Add-PSSnapin Microsoft.SharePoint.PowerShell
   $farm = Get-SPFarm
   $farm.SkipUpdateWebConfigPermission = $true
   $farm.Update()

   We manually granted the WSS_WPG group permissions to the web.config file that the SafeControls/configuration is read from, and this resolved the issue.

   Is it recommended this workaround be used in SPSE in order to support custom apps/addins?

   Appreciate your insight!

   Reply
   1. 

      Stefan Goßner
      On 28. July 2026 Permalink

      Hi Andre,
      this should only be required if custom code implemented in this app is trying to access the web.config file.
      Is this the case in your scenario?
      Cheers,
      Stefan

      Reply
6. 

   Sergey
   On 31. July 2026 Permalink

   Dear colleagues, good day!
   After installing the July 2019 update on several SharePoint SE and SharePoint 2019 systems, errors occurred when running PowerShell scripts for adding photos to user profiles.
   The “Update-SPProfilePhotoStore -createthumbnailsForImportedPhotos $true -MySiteHostLocation xxx” command ends with an error:
   Update-SPProfilePhotoStore : The property value was invalid. This could be caused by invalid non-text characters.

   Similar notifications are also found in the ULs logs
   UserProfile.Commit failed with the following reason: Microsoft.Office.Server.UserProfiles.InvalidValueException: Url is not safe: https://…

   Also, changing the “PictureURL” property of a user profile results in the same error – The property value was invalid. This could be caused by invalid non-text characters.

   This script hasn’t changed and has been working successfully for a long time. When filling out a field in the admin center interface, it successfully populates with the same data that it can’t update through PowerShell.
   Colleagues, could you please check how it works for you?

   Reply
   1. 

      Stefan Goßner
      On 31. July 2026 Permalink

      Hi Sergey,
      ok – you are the second one who reports this here on my blog.
      My suggestion would be to open a support case with Microsoft to ensure this is properly analyzed.
      Cheers,
      Stefan

      Reply
      1. 

         Brian Roche
         On 11. August 2026 Permalink

         We’re experiencing the same regression, namely in the ULS logs after running the “Update-SPProfilePhotoStore -createthumbnailsForImportedPhotos $true -MySiteHostLocation xxx” command we get in the ULS logs: EditUserProfile_Commit Failure: Microsoft.Office.Server.UserProfiles.InvalidValueException: Url is not safe: https://mysitetest.yourcorporation.com:443/User Photos/Profile Pictures/auser_MThumb.jpg at Microsoft.Office.Server.UserProfiles.UserProfile.Commit(Boolean allowUnsafeUpdates).

         Reply
   2. 

      Stefan Goßner
      On 1. August 2026 Permalink

      Hi Sergey,
      I just sent you some sample code to evaluate by email.
      Please let me know if this resolves the issue.
      Cheers,
      Stefan

      Reply
      1. 

         Sergey
         On 2. August 2026 Permalink

         Hi Stefan!
         many thanks, but it not resolve my problem
         I sent mail with ULS log file

         Reply
         1. 

            Sandro
            On 13. August 2026 Permalink

            Hi Sergey

            I’m facing the same issue.
            Were you able to solve it?

            Reply
7. 

   Farid
   On 4. August 2026 Permalink

   Hello Stefan,

   I am currently facing an issue on a SharePoint 2019 environment.

   Since the July patching, we have been seeing several “System.UnauthorizedAccessException” errors on the intranet, especially during REST API calls such as:

   /_api/web/Lists?$select=Title

   or:

   /_api/search/postquery

   In addition, on the Office Online Server side, when opening a document, users receive the following yellow warning popup:

   “UPLOAD FAILED: You are required to sign in to upload your changes.”

   Do you have any recommendations, known workarounds, or corrective actions that could help resolve this issue?

   Please also note that the environment is deployed behind a Powell Manager layer and uses Microsoft Entra ID authentication.

   In this configuration, the SharePoint web application is extended, and AzureCP is used for the integration with Microsoft Entra ID.

   Best regards,
   Farid

   Reply
   1. 

      Stefan Goßner
      On 4. August 2026 Permalink

      Hi Farid,
      this sounds like a known issue with Distributed Cache introduced in July CU.
      A fix is in development and is planned to be made available next week.
      Cheers,
      Stefan

      Reply
      1. 

         Farid
         On 5. August 2026 Permalink

         Hello Stefan,

         Thank you for your response.

         I have reviewed all the configuration settings, including cache-related settings, CacheStatistics, form digest expiration, and several other parameters. Everything appears to be correctly.

         We seem to be facing two different issues.

         In our test environment, where the Web Front-End and Distributed Cache roles are hosted on a single server, Search stopped working after the July patching. However, we did not observe any 401 authentication issues.
         In the production environment, which is distributed across multiple Web Front-End servers, dedicated Cache servers, and dedicated Search servers, Search is working correctly. However, we are experiencing intermittent 401 authentication errors as well as issues with Office Online Server,
         The differences between the two environments make the root cause difficult to identify

         So, there is nothing more we can do at this stage. We can only wait for Microsoft’s fix to be released next week.

         Best regards,
         Farid

         Reply
8. 

   Kiran Pasumarthi
   On 6. August 2026 Permalink

   We are also seeing issue with the userprofile pictureurl not able to update throws URL invalid.

   Any solution found.

   Reply
   1. 

      Stefan Goßner
      On 6. August 2026 Permalink

      Hi Kiran,
      Yes – this is a known issue in July 2026 CU.
      A fix for SP2019 and SPSE is planned to be released next week.
      As a workaround for now, add the following server debug flag before performing the change:

      $f = Get-SPFarm
      $f.ServerDebugFlags.Add(53534);
      $f.Update()

      After the change is performed revert the setting:

      $f = Get-SPFarm
      $f.ServerDebugFlags.Remove(53534);
      $f.Update()

      Cheers,
      Stefan

      Reply
9. 

   Kiran
   On 11. August 2026 Permalink

   Thank you Stephen. This seems to work now. Appreciate your help. Will look forward for the upcoming fix .

   Reply