Trending Issue: SharePoint 2010 workflows fail after June 2026 CU

- - 31 Comments

We have received multiple reports indicating that SharePoint 2010–style workflows are failing after installing the June 2026 Cumulative Update (CU).

Symptoms

The issue is typically reflected in the ULS logs with entries similar to the following:

w3wp.exe (0xXXXX)   SharePoint Foundation   Legacy Workflow Infrastructure   4letu   High   Block the namespace: clr-namespace:System.CodeDom;Assembly=System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, type: CodeBinaryOperatorExpression.Right

w3wp.exe (0xXXXX)   SharePoint Foundation   Legacy Workflow Infrastructure   4letu   High   Block the namespace: clr-namespace:System.CodeDom;Assembly=System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, type: CodePrimitiveExpression.Value

w3wp.exe (0xXXXX)   SharePoint Foundation   Legacy Workflow Infrastructure   4letu   High   Block the namespace: clr-namespace:System.CodeDom;Assembly=System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, type: CodeBinaryOperatorExpression.Left

…

After addressing these initial ULS log entries – by explicitly allow-listing the affected types using authorizedType entries in the web.config – the behavior typically changes and new log entries appear, such as:

w3wp.exe (0xXXXX)   SharePoint Foundation   Legacy Workflow Infrastructure 66eav High spNoCodeXomlCompiler.IsGoodWorkflow:
Potentially malicious WorkflowCodeTypeReferenceExpression:
<ns2:WorkflowCodeTypeReferenceExpression QualifiedName="Microsoft.SharePoint.WorkflowActions.Helper" Type="Microsoft.SharePoint.WorkflowActions.Helper" xmlns:ns2="clr-namespace:Microsoft.SharePoint.WorkflowActions; Assembly=Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null" />

These log entries indicate that the workflow is being blocked due to newly introduced security validations.

Cause

The problem is caused by a security hardening change included in the June 2026 CU, which adds stricter validation for workflow code. As a result, certain constructs used in SharePoint 2010–style workflows are now flagged as potentially unsafe and are prevented from executing.

Workaround

A workaround is available; however, it should be applied only after careful consideration as it disables a large number of security fixes for SharePoint 2010 style workflows released in the last couple of years:

$farm = Get-SPFarm
$farm.EnablePreParseSecurityCheckForWorkflow = $false
$farm.Update()

Solution

A fix for the workflow issue has been released with July 2026 CU for all supported SharePoint Version (2016, 2019, Subscription Edition)

Recommendation

Customers are strongly encouraged to plan and execute migration of SharePoint 2010–style workflows to supported alternatives (e.g., Power Automate or SharePoint 2013/Workflow Manager-based solutions, where applicable) at the earliest opportunity to avoid service disruptions.

31 Comments


  1. Thank you again for the heads-up, Stefan. This is critically important information for customers like my company, which began a (forced) workflow automation platform migration more than two years ago. We’ve completed less than half of the automation conversions, so we will run unsupported for several months into the future.

    I fully expected Microsoft to inject a kill pill with the July 2026 updates for the SP2010 workflow engine, but doing it in June and then potentially not providing a fix BEFORE the end of support deadline is awfully bold.

    If we are patched through May 2026, I assume that it would be more secure to remain on May 2026 with EnablePreParseSecurityCheckForWorkflow = $true than if we applied June 2026 patches and then set EnablePreParseSecurityCheckForWorkflow = $false. Is that correct?

    Reply

    1. Hi Brett,
      no, I would not say so.
      June CU included 30 security fixes for different areas in SharePoint – including two critical security vulnerabilities.
      Cheers,
      Stefan

      Reply

  2. Good evening, Stefan.

    I saw the comments regarding this in the SharePoint SE June 2026 post but does this impact SharePoint 2019 as well?

    Thanks in advance.

    Reply

    1. Hi Daniel,
      this affects all SharePoint Version (2016, 2019, SPSE).
      Cheers,
      Stefan

      Reply

  3. Guess my jokes that Microsoft would find a way to “kill” 2010 style workflows in the final CU was almost true

    Reply

  4. Hi Stefan and also other users of this blog,

    can someone tell me if the current issue with SharePoint 2010 workflows only affects SharePoint Designer workflows or also Nintex?
    I know that Nintex for SharePoint is using the SharePoint 2010 Workflow Engine which is going to be deprecated in July. Right now my assumption would be, after reading the blog and all the comments, that the fix from Marc does not really work all the way: https://pastebin.com/Fzqg1P3u
    Currently I have not installed the June CU update because I am not really sure what would happen with the Nintex workflows and so it would be great if we could get an update on this.

    Thanks in advance,
    Alex

    Reply

  5. So if I checked ang got “False” from:
    get-spfarm | select EnablePreParseSecurityCheckForWorkflow

    Does this mean the June 2026 CU won’t cause the failing of our 2010-style workflows?
    We have Nintex for SharePoint 2019 implemented.

    Reply

    1. Hi Paul,
      yes – the workflows will not fail.
      But again; this setting invalidates most SP2010 Workflow security fixes released in the last 5 years.
      That should not be the default setting and should be reverted as soon as the fix is available.
      Cheers,
      Stefan

      Reply

      1. I am afraid to ask, but is it really secure to have a flag, which disables security updates for the last couple of years?

        Reply

        1. Hi John,
          you raise a very important question, and it is exactly why I included the statement that this workaround should only be applied after careful consideration.

          From a security perspective, the safest approach is to install the June 2026 CU and not implement the workaround. However, for many customers this would effectively render their SharePoint 2010 workflows inoperable, which may not be a viable option.

          For organizations that still depend on SharePoint 2010 workflows for critical business processes, the decision becomes a risk assessment. The key question is whether the greater risk lies in disabling these specific security protections or in delaying the deployment of the June 2026 CU, which contains more than 30 important and critical security fixes.

          Ultimately, each organization must evaluate its own security posture, business requirements, and operational dependencies before deciding on the most appropriate course of action.

          Cheers,
          Stefan

          Reply

          1. Hi Stefan,
            yes, you are right. I got it and that is exactly what I recommended to my clients.

            However, my concern was whether having such a flag or any setting implemented in SharePoint, which disables security updates on a fully patched SharePoint farm, could eventually be used to attack an up-to-date SharePoint farm?

            Or will this flag be removed from SharePoint as soon as the SharePoint 2010 workflows are fixed in July?


          2. Hi John, this flag is in the product since at least 5 years.


  6. Hi everyone: just received the information that a fix for the workflow issue is planned to be released with July 2026 CU for all supported SharePoint Version (2016, 2019, Subscription Edition)

    Reply

    1. Thanks, that is great news!

      Reply

  7. Hi Stefan,

    if suppose we go ahead with implementing this workaround for rectifying the issue related to the SP2010 workflows after installing June 2026 CU will the implications of security risks be confined to only SP2010 workflows or the whole farm security risks would be endangered?

    Reply

    1. Hi John,
      based on the information available to me, the risk only applies to SP2010 workflows.
      Cheers,
      Stefan

      Reply

  8. Hi Stefan,
    The event driven and manually triggered workflows were resolved by authorizing the “System.CodeDom” namespace assembly references in the web.config. However the scheduled workflows were failing and were not able to be resolved even after disabling the EnablePreParseSecurityCheckForWorkflow for the farm. We ended up rolling back. Hopefully that is resolved in the July CU patch.
    Thanks for your article!
    Justin

    Reply

    1. Hello Justin,
      A week ago, after deploying the SPSE June 2026 CU and setting the EnablePreParseSecurityCheckForWorkflow farm property to False, I had some issues, on a couple but not all of my farms, with the Windows “SharePoint Timer Service” (SPTimerV4). I noticed it taking up a large amount of memory and noticed in Central Administration -> Monitoring -> Check Job Status, that there were a lot more running jobs than normal and they were taking a lot longer than typical to complete. Specifically the timer job named “Workflow” had been running for a few hours. It is scheduled to run every 5 minutes by default and should be completing in less than 5 minutes. This job is responsible for checking for pauses in 2010 workflows that have reached their completion, and then triggering the WF to continue with the next step. As the timer job appeared to be stuck, this was not working as designed. Through a combination of IIS reset, timer cache clearing, and restarting of the Windows “SharePoint Timer Service” service, server memory and running timer jobs returned to their normal operation, including the “Workflow” timer job now completing every 5 minutes in less than a minute. After seeing your post this morning, I tested a workflow that relies on a pause, on two farms, and the Workflow timer job responsible for moving the WF to the next step succeeded. You may want ensure that your “Workflow” timer job is completing every 5 minutes. If it is and your 2010 WFs containing a “scheduled” step are still failing, I’d be interested in what type of scheduled step is not functioning in your WFs, if it is different than the standard “pause for 5 minutes” step that I used.

      Reply

      1. Hi Fred,
        Thanks so much for your post. We were testing with a simple scheduled workflow scenario i.e. manual workflow with a start workflow action that triggers an item update workflow, but configured as a scheduled workflow in the start workflow action. We do use pause actions in some other scheduled workflows and its possible they may have been running at the time, but unfortunately we didn’t check the “Workflow” timer job to see if it was stuck. All we can confirm is that the Nintex Workflow Scheduler was triggered every 5 minutes with varying durations.
        When we patch the July CU, I will post back here to confirm the steps performed and the outcome. We will view the Check Job Status especially to review the “Workflow” timer service, and we will also try clearing the timer cache which I don’t believe we tried.
        Thanks again for taking the time to respond.
        Justin

        Reply

  9. Hello, Stefan.
    Could you please give us information, if June 2026 CU affects Nintex workflows? We applied it on SP 2019 Prod system, afterwards Nintex Workflows stopped working. We added new Nintex licenses on the Servers, but Nintex Workflows are still not starting.
    Thank you.

    Reply

    1. Hi Teodora,
      of course, as Nintex workflows are SP2010 workflows.
      That means this article applies.
      Cheers,
      Stefan

      Reply

  10. Hi Stefan,

    is there a reason, that the July updates are not released yet?

    BR
    Patrick

    Reply

    1. Hi Patrick,
      the monthly updates are scheduled to be released on the second Tuesday of each month.
      The second Tuesday this July is July 14th.
      Cheers,
      Stefan

      Reply

      1. Hi Stefan,

        my mistake |-)

        Many thanks for the quick info 🙂

        BR
        Patrick

        Reply

  11. Is the July SharePoint CU still coming today to fix workflow issues?

    Reply

    1. Hi Todd,
      already released.
      Check my blog posts from today.
      Cheers,
      Stefan

      Reply

      1. Hi
        I applied July 2026 patch on SP 2016 onPrem, but workflow 2010 issue still not resolved and getting the same error. however after disable below, issue get fixed: $farm = Get-SPFarm
        $farm.EnablePreParseSecurityCheckForWorkflow = $false
        $farm.Update()
        could you please suggest permanent solution for this .

        Reply

          1. Hi Stefan,

            This means the issue has not been fixed in the July 2026 patch, despite Microsoft’s commitment. In my opinion, it is not appropriate for known bugs to remain unresolved in the final patch release after the product has reached its End of Support (EOS).

            Microsoft should take responsibility for this issue, as many customers are facing the same challenge. We started our migration journey more than two years ago, but we still need to maintain this infrastructure for the next 15 months. Therefore, a reliable and fully supported environment is critical for our business operations during this transition period.


          2. Hi Anil,
            I und understand you point of view, but the issue introduced in June CU was fixed in July.
            What you are experiencing now is a problem with the configuration in the web.config where certain classes need to be allowed to enable specific workflow actions.
            Applying these steps will allow the workflows to run.
            This would not have worked with June CU.
            Cheers,
            Stefan

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.