Sitecore and the sample machine key: an exposed ViewState surface attackers are using now

Sitecore is an enterprise .NET content platform, the kind that runs large corporate and government sites. In late 2025 it became the subject of one of the more avoidable critical bugs of the year: CVE-2025-53690, an actively-exploited remote code execution rooted not in a code flaw but in a copy-paste mistake that propagated for years.

Old Sitecore deployment guides shipped with a sample ASP.NET machine key - a static value, printed in the docs, meant to be replaced. A great many installs never replaced it. The machine key is what signs and encrypts ASP.NET ViewState, the hidden __VIEWSTATE form field on every WebForms page. If an attacker knows the key - and the sample key is public - they can craft a ViewState payload the server will trust, deserialize, and execute. That's remote code execution, and Google's Mandiant disrupted a live campaign using exactly this.

What can be confirmed passively, and what can't

This is a case where being honest about the finding matters. A bare __VIEWSTATE field is standard ASP.NET WebForms - it's on millions of perfectly safe pages, so flagging it alone would be noise. What's specific is Sitecore plus a reachable ViewState surface: the X-Sitecore-* headers, the sc_site/sc_lang cookies, or the unauthenticated /sitecore/blocked.aspx endpoint serving a ViewState form.

What a scanner from outside can't confirm is whether the key in use is actually the leaked sample one - that's server-side config. So the responsible finding is "this is Sitecore with an exposed ViewState surface, vulnerable to CVE-2025-53690 if the sample machine key is still in place," not an overclaimed "you are exploitable." That framing tells you exactly what to go check without crying wolf.

Replace the key, patch, and close the surface

The fix is to make absolutely sure the machine key is unique, then update and restrict the admin surface.

<!-- web.config - the sample key from old deployment guides -->
<machineKey
validationKey="<the public sample value>"
decryptionKey="<the public sample value>" />

Generate a fresh, unique machineKey (every install should have its own - never a value from documentation), apply the latest Sitecore security updates, and restrict the /sitecore admin surface to internal access so the ViewState entry point isn't reachable from the internet. If your install ever ran the sample key on the public web, assume it could already have been abused and respond accordingly.

Whether your Sitecore exposes a ViewState surface to the public is something a stranger probes with a single GET to a Sitecore path, which means we check it the same way. SurfaceCheckr looks for Sitecore-specific headers and cookies, or probes /sitecore/blocked.aspx for a ViewState form, and reports the exposure - gated on those Sitecore markers, never on bare ViewState, and never by sending a deserialization payload. It reads what the page serves and stops there. That's the check that tells you whether your platform is showing attackers the door they're already walking through.