Vulnerability in EPiServer.Forms
We have been experiencing an issue that has been happening specifically on some of our CMS12 Integration environments since early this week, more specifically any reference to @Model.Current page has been outputting just the fully qualified name with _DynamicProxy appended, see example below:
It has taken a while but Optimizely support have finally found that the issue is being caused by an upgrade of the .Net Runtime from 7.0.2 to 7.0.3 - all of the environments affected (other customers are starting to experience the same issue as well now) are running Azure App Service P1v3 and it is these V3 instances that have the new runtime.
I was unable to replicate this locally until this morning. A new version of Visual Studio 2022 has been released (version 17.5.0) and since upgrading I can now replicate the issue locally, as it looks like this upgrade also updates the .Net Runtime version to 7.0.3
I believe Optimizely will be making an announcement shortly but wanted to make people aware of this issue as I am sure it will start to affect more and more people, especially with the new version of Visual Studio being released.
A possible workaround (although hasn't worked for me) was provided by Opti support as follows:
I have added the @addTagHelper where necessary but the issue still persists.
Thanks for your post. was there a support ticket or a bug number?
The support ticket is 1094062 which is still open.
Thanks, I have raised the issue to Content Platform team, hopefully that will catch their attention
Okay, so an update on this one, it does indeed look like the new .Net SDK version has gone and broken the tag helper - see the following open issue on the AspNetCore Github repo:https://github.com/dotnet/aspnetcore/issues/46740So there are two workarounds for the issue as shown here until a fix is released. It is interesting to note that your machine will always use the latest SDK even if your project is targeting .Net 6…
I am opting for the global.json and pipeline update route as don't fancy changing every view component instance to @await InvokeAsync (which I have confirmed does work as well)