SharePoint 2010 workflows fail after April/Mai/June 2026 CUs with XOML security validation errors

SharePoint 2010 workflows fail after April/Mai/June 2026 CUs with XOML security validation errors

I ran into another one of those on-prem SharePoint issues that looks random at first and then turns out to be very specific.

After the 2026 SharePoint Subscription Edition cumulative updates, some classic SharePoint 2010 workflows in one of my environments suddenly refused to publish. Other workflows still worked, which made the whole thing look inconsistent and honestly a bit misleading.

The important part: this was not a broken SharePoint Designer action, and it was not a corrupted workflow definition. The actual cause was workflow hardening that now blocks specific legacy XOML constructs.

Initial Symptoms

What I saw first was confusing:

  • Only some SharePoint 2010 workflows failed.
  • Affected workflows could no longer be published from SharePoint Designer.
  • Simpler workflows still published and ran as expected.
  • The issue showed up after the 2026 CU level changed in the farm.

That combination is what makes this issue easy to misread. If only one workflow breaks, the first instinct is usually to blame the workflow logic itself.

What Broke in My Case

I rebuilt the failing workflow piece by piece until I found the exact point where publishing started failing again.

These parts still worked:

  • Sending an email
  • Writing an entry to the workflow history list
  • Creating a task

The failure came back when I added a condition that compared a current item property with a value.

That detail matters because it lines up directly with what later appeared in the ULS logs. Once I saw that, the issue stopped looking random.

The Useful Signal in ULS

The decisive evidence was in ULS. These were the relevant entries:

07/07/2026 09:14:35.50 	w3wp.exe (0x2CC0)                       	0x3C4C	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	9dd924a2-ae83-607d-abae-8755e28bcc47
07/07/2026 09:14:35.50 	w3wp.exe (0x2CC0)                       	0x3C4C	SharePoint Foundation         	Legacy Workflow Infrastructure	c42q0	High    	Potentially malicious xoml node: <ns0:CodeBinaryOperatorExpression.Right xmlns:ns0="clr-namespace:System.CodeDom;Assembly=System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">        <ns0:CodePrimitiveExpression>         <ns0:CodePrimitiveExpression.Value>          <ns1:Boolean xmlns:ns1="clr-namespace:System;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">true</ns1:Boolean>         </ns0:CodePrimitiveExpression.Value>        </ns0:CodePrimitiveExpression>       </ns0:CodeBinaryOperatorExpression.Right>	9dd924a2-ae83-607d-abae-8755e28bcc47

The key phrases are:

  • Block the namespace
  • Potentially malicious xoml node
  • CodeBinaryOperatorExpression.Right

That is the real indicator. SharePoint is not just failing to compile the workflow. It is actively rejecting part of the XOML definition during security validation.

First Place I Checked

My first assumption was that the workflow compiler allowlist in web.config was incomplete.

I checked the web application config here:

C:\inetpub\wwwroot\wss\VirtualDirectories\<appname:port>\web.config

This section looked like the obvious candidate:

<System.Workflow.ComponentModel.WorkflowCompiler>
   <authorizedTypes>
     <targetFx version="v4.0">
        <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="Microsoft.SharePoint.WorkflowActions.WithKey" TypeName="*" Authorized="True" />
    </targetFx>
   </authorizedTypes>
</System.Workflow.ComponentModel.WorkflowCompiler>

At first glance, i was hoping this lines are missing, but that looks good (it’s an known Issue).

What Changed

The issue appears after the 2026 cumulative update hardening for legacy workflows.

In practice, SharePoint now performs stricter validation of legacy workflow code and XOML before it allows the workflow to publish or run. Some constructs that were previously accepted are now treated as unsafe.

That means the workflow engine is behaving as designed after the update, but the new security behavior conflicts with older SharePoint 2010-style workflow definitions.

Quick Verification Checklist

If you want to confirm whether you are hitting the same issue, these are the first checks I would make:

  1. Reproduce the publish failure with the smallest possible SharePoint 2010 workflow.
  2. Check ULS for Block the namespace, Potentially malicious xoml node, or System.CodeDom entries.
  3. Compare the failing workflow against a simple workflow that still publishes.
  4. Identify whether the failure starts when a condition or expression adds a legacy XOML construct.

That gives you a much faster answer than spending hours inside SharePoint Designer.

Workaround

There is a workaround, but it comes with a real security tradeoff.

You can disable the pre-parse workflow security check at the farm level:

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

This can get production moving again, but it effectively rolls back part of the protection Microsoft added for legacy workflows.

I would only use this if the business impact is serious enough to justify the risk.

My Recommendation

If this issue is blocking production, the workaround can buy you time. I would still treat it as an emergency measure, not a real long-term fix.

What I recommend:

  1. Confirm the issue in ULS before changing any farm-wide setting.
  2. Use the workaround only when the operational impact clearly outweighs the security rollback.
  3. Inventory the remaining SharePoint 2010 workflows in the farm.
  4. Plan migration away from legacy workflows where possible.

That last point is the important one. These workflows may still exist in the product, but they are becoming more fragile every time security hardening gets stricter.

Reference

Stefan Goessner documented the broader issue here:

Conclusion

If a SharePoint 2010 workflow suddenly fails to publish after the 2026 CU level changes, do not stop at SharePoint Designer.

Go straight to ULS and look for blocked System.CodeDom namespaces or Potentially malicious xoml node entries. That is the fastest way to separate a broken workflow design from a platform hardening issue and decide whether you need a short-term workaround or a migration plan.