Vulnerability in EPiServer.Forms
We just updated to the latest versions of cms 10.10.4 and commerce 11.2.1 and noticed a change to the save actions.
We have a save event hook that will set a property to a product when a property has been changed. Before we used 'SaveAction.Save | SaveAction.SkipValidation | SaveAction.ForceCurrentVersion' to update changes to a product draft without publishing the product or creating a new version.
But now this functionality has changed somehow. It seems SaveAction.ForceCurrentVersion is now saving the changes also to the currently published version.
I can't see that the currently published version got the changes in the edit mode or in the version history, but when looking at the product on the website the changes are showing.
We have some different scheduled jobs and save event hooks that we need to remove the ForceCurrentVersion action from now. So, my question is if this is an intentional change to the ForceCurrentVersion action, and if so, what should we use instead?
We haven't made any changes to that behavior, I think your problem is as same as this:
I would appreciate if you could have a deeper look into this, because I think that error you sent appears when trying to Force current version on a product with the status Published? In our case we try to update and save a product that has the current status CheckedOut. And we don’t want to publish it. And I should see that error in the logs then, but I don’t.
Obviously, something in this functionality has been changed, it worked fine in the previous versions of cms and commerce that we had (they were version 10+ something).
Can you post the code you are using? I might need to reproduce the problem first
I tried this code (quick and dirty), and I have no problem with current published version
var contentEvents = context.Locate.Advanced.GetInstance<IContentEvents>();
contentEvents.SavedContent += (sender, args) =>
if ( args.Content != null)
var product = args.Content as ProductContent;
if (product == null)
if (product.Code != "123")
var clone = product.CreateWritableClone<ProductContent>();
clone.Code = "abc";
.Save(clone, SaveAction.Save | SaveAction.SkipValidation | SaveAction.ForceCurrentVersion,
Hm, well we are having the similar code, only we use the IContentVersionRepository.
var contentVersionRepository = ServiceLocator.Current.GetInstance<IContentVersionRepository>();
var contentRepository = ServiceLocator.Current.GetInstance<IContentRepository>();
ContentVersion latestVersion = contentVersionRepository.List(currentContent.ContentLink, languageId).OrderByDescending(x => x.Saved).FirstOrDefault();
ContentVersion version = contentRepository.Get<BaseProductType>(latestVersion.ContentLink);
if (version != null)
var versionClone = version.CreateWritableClone();
// Adding stuff to versionClone...
SaveAction saveAction = this.CalculateSaveAction(version);
contentRepository.Save(versionClone, saveAction, AccessLevel.NoAccess);
private SaveAction CalculateSaveAction(BaseProductType product)
SaveAction action = SaveAction.Save | SaveAction.SkipValidation;
if ((product as IVersionable).Status == VersionStatus.Published)
return action | SaveAction.ForceNewVersion | SaveAction.Publish;
return action | SaveAction.ForceCurrentVersion;
Can you make sure latestVersion is not the published version?
Sorry, I know I gave you one example for when we modifiy a product on the SaveEvent, but we also have some scheduled jobs updating the products were we process versions that are either published or drafts/checkedout, and now those jobs also have the issue with ForceCurrentVersion.
so if the latest version is Published the save action will be:
SaveAction.Save | SaveAction.SkipValidation | SaveAction.ForceNewVersion | SaveAction.Publish;
and for Drafts/Checked out:
SaveAction.Save | SaveAction.SkipValidation | SaveAction.ForceCurrentVersion;
So what happens on the save for a draft version is that the changes are saved to the draft and in the version gadget it looks ok (also in compare mode it says the draft has got the changes while the published version does not), but when looking on the product on the website the changes are showing on the published version.
I think we need more information to investigate this issue - i.e. you might have to contact Episerver developer support service and provide us an VM to reproduce the issue, so it can be properly debugged.
Mia, as I just dealt with a somewhat simiar case I thought I would post some further information that might help with your issues. But please take Quan Mai's advice and pass on additional details through the developer support service so this can be confirmed. Key details would be which event you are listening to and if you are manipulating the Content property of the event argument passed in in any way.
The reason that you are seeing changes to could be that the was some changes done to the CMS UI in the way they call the Core CMS API. This change may bring a different set of content status and actions to events that you didn't see before. The UI is now calling Publish (SaveAction.Publish) directly without first calling Save (SaveAction.Default) so this means that if you are listening to the ContentSaving event you may now see published versions being published (which leads to a new version). Looking at your code it suggests that you are probably listening to the ContentSaved event though, so not sure if this will apply to you.
It may also help having a look at http://world.episerver.com/documentation/Release-Notes/ReleaseNote/?releaseNoteId=CMS-2078, to review the changes that we did in this area for CMS 10.
For future visitors: We filed a bug (COM-5451) - which is being worked on at this time of writing. It would be fixed in upcoming version (after 11.2.4), so probably 11.2.5 or 11.3
Yes, so developer support found that the SaveAction.Patch is the root cause.
When we combine SaveAction.SkipValidation and SaveAction.ForceCurrentVersion, the action will be SaveAction.Patch, and then the bug will happen.
We have now removed one of the actions until the bug has been solved.
Thanks four you help Quan and Henrik!