ASP.NET ViewState Deserialisation is caused when ViewState data is accepted or processed without proper integrity protection, allowing tampered data to be interpreted by the application. Attackers target weak ViewState protection to inject crafted payloads or alter application state. Defenders should ensure ViewState integrity controls are enabled and verify that the page does not trust client-supplied state blindly.
Why ASP.NET ViewState Deserialisation Happens
ASP.NET ViewState deserialisation happens when an application accepts ViewState that can be modified by the client and then interprets it as trusted state. The weakness is not deserialisation alone, but deserialisation of data that should have been protected against tampering. When integrity controls are weak, attackers can shape the payload before the server processes it.
In practice, the issue usually appears when ViewState protection is incomplete, misconfigured, or built on assumptions that the client cannot alter the payload. If the application treats returned state as authoritative, the server may reconstruct objects or state from attacker-influenced data. That is why ViewState security is a state-trust problem as much as a parsing problem.
ASP.NET ViewState deserialisation is especially dangerous because the payload is part of normal page flow, so abuse can blend into ordinary requests. The control objective is simple: do not let client-supplied state drive server-side behaviour unless its integrity is enforced. For broader background on insecure deserialisation patterns and .NET-specific attack paths, see the Insecure Deserialisation Guide.
How Attackers Turn ViewState into Code or State Manipulation
Attackers look for ViewState pathways that accept crafted content, especially when the application exposes a predictable or reusable trust boundary. If they can influence the payload and the server accepts it, they may alter application state, trigger unexpected object handling, or reach a deeper exploit chain. The risk becomes much higher when the application also relies on secrets or keys to protect ViewState but those secrets are exposed, reused, or poorly managed.
In ASP.NET environments, machine keys are a frequent pivot point because they govern whether ViewState integrity checks can be trusted. When those keys are known or reused in unsafe ways, attackers can produce payloads the server will accept as legitimate. NHIMG documented this pattern in ASP.NET machine key attacks 2025, where stolen or publicly exposed keys enabled ViewState abuse, and in ToolShell SharePoint exploitation 2025, where key theft allowed compromise to survive normal patching.
The practical takeaway is that ViewState abuse is often a cryptographic trust failure first and a deserialisation failure second. If the server cannot reliably distinguish authentic state from attacker-crafted state, the deserialiser becomes a delivery path for manipulation rather than a harmless parser.
What Good Defences Look Like in ASP.NET
Defence should start with confirming that ViewState integrity protection is enabled and correctly bound to the application. Teams should verify that the page does not accept unsigned or otherwise unprotected state, and that any key material used for protection is generated, stored, and rotated under a proper lifecycle. When key handling is weak, the deserialisation layer is only as trustworthy as the weakest key path.
Rotation and inventory matter because ViewState protection is only effective while the underlying secrets remain protected. The Cryptographic Key Management Guide is relevant here because it covers key lifecycle, compromise response, and inventory discipline for keys that protect authentication and integrity mechanisms. For the underlying control baseline, NIST also emphasises strong control over authentication and cryptographic material in NIST SP 800-53 Rev 5 Security and Privacy Controls and key lifecycle management in NIST SP 800-57 Key Management.
Where the environment already has evidence of tampering, defenders should assume the state boundary may have been crossed and investigate for earlier compromise before merely changing configuration. If the payload was accepted once, the question is not only whether ViewState is now protected, but whether the application already processed malicious state.
Risk and Threat Considerations
ViewState deserialisation creates a direct path from client-controlled input to server-side interpretation, so the main risk is not just malformed data but trusted-data abuse. If the application accepts tampered ViewState, attackers can use the page state channel to alter logic, preserve access, or feed a deeper exploit chain.
Failure mechanism: The server fails to verify the integrity of ViewState before deserialising it, or the protection key is predictable, exposed, or reused in a way that makes forged state acceptable.
Impact: An attacker can manipulate application state, trigger unsafe object handling, and in stronger cases convert a web request into code execution or persistent compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-57 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | ViewState integrity depends on protecting and rotating the keys that sign it. |
| SC-23 — Session Authenticity | ViewState abuse is a client-state integrity problem affecting trusted session flow. | |
| Recommendation — Manage and rotate the keys that protect ViewState integrity to prevent forged state. Validate page-state authenticity before processing any client-returned state. | ||
| NIST SP 800-57 | 1 — Key Management | ViewState protection hinges on key lifecycle, storage, and rotation discipline. |
| Recommendation — Apply key lifecycle controls to the secrets that protect ViewState integrity. | ||
| OWASP ASVS | V9 — Self-contained Tokens | ViewState behaves like a self-contained state token that must resist tampering. |
| Recommendation — Require tamper resistance for any self-contained client state accepted by the app. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Exposed or reused machine keys let attackers forge protected ViewState. |
| Recommendation — Eliminate secret leakage for any key material that protects ViewState. | ||
Practitioner Guidance
What to verify: Treat ViewState protection as a required trust control, not a default convenience feature. Verify that the application never relies on client-supplied state for security decisions unless integrity and provenance are enforced end to end.
Decision rule: If ViewState protection depends on a secret or key that has been exposed, reused, or cannot be confidently inventoried, rotate it as a priority and assess whether any earlier requests may already have been processed with forged state.
What practitioners underestimate: Many teams focus on the deserialiser and miss the real failure point, which is the trust boundary around the payload. The parser is only dangerous when the application accepts attacker-shaped state as legitimate.
Practitioner takeaway: The right fix is not simply to “secure deserialisation”, but to make sure the server can prove the state it is about to trust has not been tampered with.