Important: If September 2025 CU for SharePoint has been installed before, remove the NT Authority\system account from WSS_WPG and IIS_IUSRS local security groups of the SharePoint machines – otherwise installing the SharePoint fixes will fail.
For more details check this article: Trending Issue: SharePoint fixes fail to install after installation of September 2025 CU
Below are the security fixes for the SharePoint OnPrem versions released this month.
SharePoint Server 2016:
- KB 5002788 – SharePoint Server 2016 (language independent)
- KB 5002787 – SharePoint Server 2016 (language dependent)
Microsoft Support recommends to install the complete October 2025 CU for SharePoint 2016 rather than individual security fixes.
SharePoint Server 2019:
- KB 5002796 – SharePoint Server 2019 (language independent)
- KB 5002798 – SharePoint Server 2019 (language dependent)
Microsoft Support recommends to install the complete October 2025 CU for SharePoint 2019 rather than individual security fixes.
SharePoint Server Subscription Edition:
- KB 5002786 – SharePoint Server Subscription Edition
This security fix is identical with October 2025 CU for SharePoint Server Subscription Edition.
Office Online Server:
- KB 5002797 – Office Online Server
More information:
Please ensure to have a look at the SharePoint Patching Best Practices before applying new fixes.
Security Vulnerabilities fixed in this PU
| Vulnerability | SP 2016 | SP 2019 | SP SE | OOS | Impact | Max Severity |
|---|---|---|---|---|---|---|
| CVE-2025-59221 | x | x | Remote Code Execution | Important | ||
| CVE-2025-59222 | x | x | Remote Code Execution | Important | ||
| CVE-2025-59223 | x | Remote Code Execution | Important | |||
| CVE-2025-59224 | x | Remote Code Execution | Important | |||
| CVE-2025-59225 | x | Remote Code Execution | Important | |||
| CVE-2025-59228 | x | x | x | Remote Code Execution | Important | |
| CVE-2025-59231 | x | Remote Code Execution | Important | |||
| CVE-2025-59232 | x | x | x | Information Disclosure | Important | |
| CVE-2025-59233 | x | Remote Code Execution | Important | |||
| CVE-2025-59235 | x | x | x | Information Disclosure | Important | |
| CVE-2025-59236 | x | Remote Code Execution | Critical | |||
| CVE-2025-59237 | x | x | x | Remote Code Execution | Important |
See the Security Update Guide below for more details about the relevant fixes:
Permalink
I’m having problems installing the sts core cus for both 2016 and 2019. Is it just me?
Permalink
Hi Guillermo,
what error did you get?
Cheers,
Stefan
Permalink
None. Just that the package failed to install. I saw your post from last month about the local system account being added to the WSS_WPG and IIS_IUSRS… I’m trying that now.
I seem to recall that I had to remove my admin account from one of those groups to install last month.
Permalink
Worked on the 2016 app server. I’ll keep you posted.
Permalink
I assume you would have found the error listed in this blog post in the installer log:
https://blog.stefan-gossner.com/2025/09/11/trending-issue-sharepoint-fixes-fail-to-install-after-installation-of-september-2025-cu/
Permalink
I am getting the error “Installation of this package failed” error when trying to install the patch on SP2016 Servers.
They were updated with September 2025 patch and PSConfig was run successfully last month. CA does not say any upgrade is needed as well.
Any issues reposted with the exe files?
Permalink
Yes. That’s the one. After following it’s instructions (and restarting after the previous installs were in a hung state), I am able to install the Oct 25 CUs
Permalink
Thanks Guillermo. So just removing the NT Authority\System account from WSS_WPG and IIS_IUSRs group, worked for you?
Permalink
I also removed Local Service. (Thanks Stefan).
Permalink
It worked. Thanks a lot both of you!!
Permalink
I added a big fat yellow note at the top of each of the relevant articles now, to ensure that customers will not miss this detail.
Permalink
HI Stefan,
We need one confirmation, we are running classic workflow manager with our SharePoint 2016 server.
Below is Oct 2025 security patch documentation:
https://support.microsoft.com/en-gb/topic/description-of-the-security-update-for-sharepoint-server-2016-october-14-2025-kb5002788-1fd3f61d-1457-4c93-bea9-993edb7fa333
It says below:
* If you’re running 2013-type workflows, you must install the August 2025 update for SharePoint Workflow Manager to your farm before you install this cumulative update.
If you’re currently running the Classic version of Workflow Manager, you need enable the debug flag to continue using it.
$farm = Get-SPFarm
$farm.ServerDebugFlags.Add(53601)
$farm.update()
iisreset
So since we are running classic WFM, we can run above PowerShell script & apply Oct 2025 SharePoint patch without updating Aug 2025 WFM update?
Please confirm.
Permalink
Hi Aditya,
the August 2025 WFM update does not apply to you as it is for SharePoint Workflow Manager – not for classic Microsoft Workflow Manager.
You only have to install October 2025 CU for SharePoint, enable the ServerDebugFlag and restart the services.
Cheers,
Stefan
Permalink
Thank you for replying back to my query.
Permalink
Hi Stefan,
Hope are you doing Gerat 🙂
We’ve installed the October 2025 SharePoint updates on our test tier, and post-patching, we’ve encountered an issue where one of our Nintex workflows—specifically the one using the Pause action—is failing.
Upon investigation, we found that this issue is likely due to security changes introduced in the October update that affect the SharePoint workflow engine. According to current guidance, resolving this may require disabling the EnablePreParseSecurityCheckForWorkflow setting via PowerShell, restarting the SharePoint Timer service, or removing the AuthorizedTypes node from the OWSTIMER.EXE.CONFIG file.
Add-PSSnapin Microsoft.SharePoint.PowerShell
$farm = Get-SPFarm
$farm.EnablePreParseSecurityCheckForWorkflow = $false
$farm.Update()
iisreset
Restart-Service -Name SPTimerV4
These steps are intended to disable the PreParseSecurityCheckForWorkflow setting, which has been known to resolve workflow-related issues following certain security updates.
However, despite applying this fix, the workflow still fails.
The ULS logs show the following error
Unable to locate the xml-definition for FieldName with FieldId ‘xxx’
Exception: Microsoft.SharePoint.SPException: Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))
—> System.Runtime.InteropServices.COMException: Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))
at Microsoft.SharePoint.Library.SPRequestInternalClass.GetGlobalContentTypeXml(…)
at Microsoft.SharePoint.Library.SPRequest.GetGlobalContentTypeXml(…)
— End of inner exception stack trace —
at Microsoft.SharePoint.SPGlobal.HandleComException(COMException comEx)
at Microsoft.SharePoint.Library.SPRequest.GetGlobalContentTypeXml(…)
at Microsoft.SharePoint.SPFieldCollection.FetchFieldsFromWeb()
This suggests a deeper issue possibly related to corrupted content types or missing field definitions post-update. We’re continuing to investigate and would appreciate any insights or similar experiences from the community.
Thanks.
Chandu Yanala
Permalink
Hi Chandu,
per Microsoft recommendation this setting (PreParseSecurityCheckForWorkflow=False) should NOT be used in production!
It disables half a dozend security fixes for SharePoint. You can use it as an interim solution for a couple of days to avoid a server down scenario till the correct AuthorizedTypes are configured.
For 3rd party tools like Nintex the list of AuthorizedTypes required by the 3rd party application needs to be provided by the 3rd party provider (Nintex).
Again: this should never be the final solution!
Cheers,
Stefan