我找不到此漏洞的更多详细信息，因此我的回答仅推测了可能的攻击向量.

I can't find any further details of this vulnerability, so my answer only speculates to a possible attack vector.

MAC 是 ViewState 值的签名，使用 EnableViewStateMac=true ASP.NET 将检查 MAC 签名是否实际将 ViewState 值签名为真实的.这意味着 __VIEWSTATE 隐藏字段中从客户端发送的 ViewState 值已被验证为来自服务器.

The MAC is a signature of the ViewState value, and with EnableViewStateMac=true ASP.NET will check whether the MAC signature actually signs the ViewState value as authentic. This means that the ViewState value sent from the client in the __VIEWSTATE hidden field has been verified to come from the server.

现在想象一下，处理 ViewState 值的代码容易受到对象反序列化的影响.Microsoft 公告指出:

Now imagine that the code processing the ViewState value is vulnerable to say object deserialisation. The Microsoft advisory states:

未经身份验证的攻击者可以将特制的 HTTP 内容发送到目标服务器，这可能允许攻击者在 ASP.NET 站点上运行的服务帐户的上下文中在服务器上运行代码.

An unauthenticated attacker could send specially crafted HTTP content to the targeted server, potentially allowing the attacker to run code on the server in the context of the service account running on the ASP.NET site.

使用 EnableViewStateMac=true 时，无法利用此漏洞，因为在处理 ViewState 值之前验证 MAC.任何不是来自服务器的值都会遇到 Validation of viewstate MAC failed 异常消息.

With EnableViewStateMac=true this vulnerability cannot be exploited because the MAC is validated before the ViewState value is processed. Any value that has not come from the server will be met with a Validation of viewstate MAC failed exception message.

但是，如果使用 EnableViewStateMac=false，攻击者可以操纵整个 ViewState 值来利用 缓冲区溢出/使用权限提升/escape 攻击并执行任意作为有效负载注入 __VIEWSTATE 字段的代码.

However, with EnableViewStateMac=false the whole ViewState value could be manipulated by an attacker to exploit the buffer overflow/escape attack with privilege escalation and execute arbitrary code that is injected as a payload into the __VIEWSTATE field.

总而言之，由于不再验证 ViewState 值，它打开了这个未公开的攻击向量攻击的领域.

So in summary, as the ViewState value is no longer being validated it opens up the field to attack by this unpublicised attack vector.