December 2025 CU for SharePoint Server 2016 is available for download

13 Comments

1. 

   Jude Buddle
   On 9. December 2025 Permalink

   Hi Stefan, looking at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-62562 it shows “Critical” for SharePoint 2016 even though all of the other products listed on the page are “Important”.

   Reply
   1. 

      Stefan Goßner
      On 9. December 2025 Permalink

      Hi Jude,
      I will follow up with the relevant team to get clarification.
      Cheers,
      Stefan

      Reply
   2. 

      Stefan Goßner
      On 10. December 2025 Permalink

      Hi Jude,
      thanks for the heads up! Critical was incorrect – the article has been corrected.
      Cheers,
      Stefan

      Reply
      1. 

         Jude Buddle
         On 10. December 2025 Permalink

         Thanks Stefan. Much appreciated.

         Reply
2. 

   MK
   On 12. December 2025 Permalink

   Hello Stefan,

   In article: https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-sharepoint-server-2016-december-9-2025-kb5002821-52430693-a4a0-49b0-a354-501171ef4bd3

   There is: “If you’re currently running the Classic version of Workflow Manager, you have to enable the debug flag in order to continue using it.​​​​​​​​​​​​​​​​​​​​​​​​”

   What does that classic version of Workflow Manager means? Is it referring to build-in SharePoint workflows? We don’t have Workflow Manager installed, but we are using build-in workflows in SP2016. $farm.ServerDebugFlags is returning nothing, so we are confused a bit.

   Thank you.

   Reply
   1. 

      Stefan Goßner
      On 14. December 2025 Permalink

      Hi MK,
      classic Worfklow manager is identical with Microsoft Workflow Manager 1.0.
      The new product is SharePoint Workflow Manager which replaces it and has new additional functionality.
      Cheers,
      Stefan

      Reply
3. 

   Will
   On 9. January 2026 Permalink

   Hi Stefan!

   We have applied Nov 2025 CU for SP2016 (previously we had Aug 2026 CU) in our test and acceptance environments.

   When we run Test-DefenderAndAmsiWorkProperly we get the following two errors (it’s actually exactly the same problems that Yuriy describes in a comment to your post from Sep 9, see #1 below).

   Tamper Protection: DISABLED [X]
   AMSI HTTP Header Test: Failed [X]

   You wrote that the Tamper Protection error can be ignored. But what about the failed AMSI HTTP Header Test? What does it indicate? Is it serious? Should we avoid installing the CU in production before this is resolved?

   Grateful for any help!

   #1
   https://blog.stefan-gossner.com/2025/09/09/new-security-features-released-with-september-2025-cu-for-all-supported-sharepoint-versions/#comment-42612

   Reply
   1. 

      Stefan Goßner
      On 9. January 2026 Permalink

      Hi Will,
      this indicates that the test header used to verify if AMSI integration into SharePoint is working correctly fails.
      Malicious requests will not be detected by AMSI.
      Are you using Defender as AV solution?
      Cheers,
      Stefan

      Reply
      1. 

         Will
         On 12. January 2026 Permalink

         Hi Stefan!

         Thanks for your quick reply. Yes, we are using Windows Defender.

         Are there any other steps or measure we can take to check why the “AMSI HTTP Header Test” might fail? Maybe from a Defender perspective?

         Really appreciate your help.

         Reply
         1. 

            Will
            On 12. January 2026 Permalink

            Ok – quick update:

            I ran “Test-DefenderAndAmsiWorkProperly -Verbose” and got some more interesting and detailed results:

            All webapps except one reported the following: (blocked with 400 Bad Request)
            The SharePoint Addin webapp reports: “The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.”

            Note that the SP Addin webapp has a valid SSL cert.

            /W

            Reply
            1. 

               Stefan Goßner
               On 12. January 2026 Permalink

               Hi Will,
               the trust relationship with the web app is established in the SSL handshake right after the TCP handshake before the actual request is sent to the server.
               That means for the admin website an AMSI test could not be done as the test request was never sent due as the SSL channel could not be established.
               Cheers,
               Stefan

4. 

   Will
   On 12. January 2026 Permalink

   Hi again Stefan!

   First – I was a bit stressed and thought “bad request” was a bad thing, but reading the verbose AMSI output more carefully, those websites are indeed marked as PASSED. It wasn’t a bad thing in this case. 🙂

   About the problematic website: the SharePoint Add-in website (not the admin website) fails due to problems establishing an SSL connection as you say.

   The SP add-in websites ARE a bit unusual in how they need to be configured: the SSL cert contains the SP add-in domain (which is entirely different from anything else), but the AAM for the web is just the hostname of the webserver – so if the AMSI test tries that, it won’t match the cert and SSL won’t work. The IIS website has no host header and is listening to “*” on 443, to be able to catch all the add-in requests.

   So maybe it’s OK that the AMSI test fails in this case?

   Please correct any of my above statements if I’ve misunderstood something… I’d be happy to catch any mistakes! 🙂 Thanks a lot!

   Reply
   1. 

      Stefan Goßner
      On 12. January 2026 Permalink

      Hi Will,
      bad request in this context means indeed that AMSI rejected the request as bad. Means it correctly identified it as malicious which is the purpose of this test.

      On the other issue: if the hostname in the request Url does not match the name configured in the certificate, then then a trusted SSL tunnel cannot be established.
      And as all other web applications are protected it is very likely that this also applies to the problematic one.
      Cheers,
      Stefan

      Reply