Sitecore CVE-2025-53690: Sample Machine Key ViewState RCE

What to do

1. Check every Sitecore role's web.config for a machineKey element and find out where its values came from.
2. Generate new validation and decryption keys, deploy them to all instances, and rotate them on a schedule.
3. Encrypt the machineKey section and restrict web.config access to application administrators.
4. Make sure ViewState MAC validation is enabled.
5. Hunt for compromise before and after rotation, since a stolen key works until it is changed.

How to check if you are affected or compromised

• Search the Windows Application log for ASP.NET event ID 1316 with event code 4009 and 'Viewstate verification failed. Reason: Viewstate was invalid.'
• Search IIS logs for POST requests to /sitecore/blocked.aspx, the endpoint Mandiant saw abused without authentication.
• Look for new local admins such as asp$ or sawadmin, net user /add or reg save HKLM\SAM launched by w3wp.exe, and tools staged in C:\Users\Public\Music.
• Check for EARTHWORM tunnels, DWAgent services and connections to 130.33.156.194 or 103.235.46.102.

What happened#

On September 3, 2025, Sitecore published Security Bulletin SC2025-005 for CVE-2025-53690. The flaw is in how some sites were configured, not in a code path a patch can remove. Deployment instructions for Sitecore XP 9.0 and earlier, and for Active Directory 1.4, included a sample ASP.NET machine key. Sites that pasted it into web.config share a secret anyone can look up. With it, an attacker can build a signed ViewState payload that the server deserializes and runs. The CVE record scores it CVSS 9.0, and CISA added it to KEV the next day.

Mandiant found it during an incident response and described the attack the same day in a detailed write-up. The attacker sent a crafted ViewState to /sitecore/blocked.aspx, which needs no authentication. The payload carried a .NET reconnaissance tool Mandiant calls WEEPSTEEL. Running as NETWORK SERVICE, the attacker archived the web root, including web.config, and staged EARTHWORM (a SOCKS tunnel), DWAgent (remote access) and SharpHound in C:\Users\Public\Music. They then created local admins asp$ and sawadmin, dumped the SAM and SYSTEM hives, and moved laterally over RDP. Mandiant says the key "had been exposed in Sitecore deployment guides from 2017 and earlier."

Who is affected#

Sitecore lists Experience Manager (XM), Experience Platform (XP), Experience Commerce (XC) and Managed Cloud. The clearest case is any deployment built with the sample key from the XP 9.0 or Active Directory 1.4 instructions. Sitecore also warns that any XM, XP or XC release may be affected in multi-instance mode with customer-managed static keys, and that both Managed Cloud Standard and Premium might be. SitecoreAI, Content Hub, CDP and Personalize, OrderCloud, Storefront, Send, Discover, Search and Commerce Server are not affected. NVD lists XM, XP and XC through 9.0 plus Managed Cloud.

Do you really need to act?#

Check, yes. Mandiant notes that newer deployments generate a unique machine key automatically, so a clean modern install is fine. The risk is long-lived sites. A deployment first built from a 2017-era guide may have carried the same machineKey through every upgrade, because the key lives in configuration, not code. Upgrading Sitecore does not rotate it. Static keys reused across many instances are also worth rotating, since one leaked web.config exposes them all.

What to do now#

1. Find every key: Get-ChildItem C:\inetpub -Recurse -Filter web.config | Select-String '<machineKey' on each CM and CD server.
2. Generate new keys, for example $b = New-Object byte[] 64; [Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($b); -join ($b | % { $_.ToString('X2') }), and deploy them to all instances at once.
3. Encrypt the section with aspnet_regiis -pef "system.web/machineKey" "C:\inetpub\sitecore\SitecoreCD\Website" and limit web.config access to administrators.
4. Confirm ViewState MAC is on, and rotate keys on a schedule, as Sitecore and Mandiant advise.
5. Managed Cloud customers should confirm with Sitecore that rotation was done.

How to tell if you were hit#

Search the Application log: Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1316} | Where-Object Message -match 'Viewstate verification failed'. Mandiant saw the payload logged next to event code 4009. Grep IIS logs for POST /sitecore/blocked.aspx. Then look for w3wp.exe launching net user /add or reg save HKLM\SAM, for the asp$ and sawadmin accounts, and for files in C:\Users\Public\Music. Mandiant's network indicators include 130.33.156.194 and 103.235.46.102. If you find any of it, treat the server as compromised: contain it, rotate the keys, and reset domain credentials the attacker could have reached.

Timeline#

• Sep 3, 2025 — Sitecore publishes SC2025-005, and Mandiant publishes its analysis; the CVE is published.
• Sep 4, 2025 — CISA adds CVE-2025-53690 to KEV.
• Sep 25, 2025 — CISA's remediation deadline for federal agencies.

Vulnerability records

• CVE-2025-53690 · KEV 2025-09-04 · Deserialization of Untrusted Data vulnerability in Sitecore Experience Manager (XM), Sitecore Experience Platform (XP) allows Code Injection.This issue…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Sitecore — Security Bulletin SC2025-005 (KB1003865) support.sitecore.com
2. CVE record — CVE-2025-53690 cve.org
3. NVD — CVE-2025-53690 nvd.nist.gov
4. CISA — Known Exploited Vulnerabilities: CVE-2025-53690 cisa.gov
5. Google Cloud (Mandiant) — ViewState deserialization zero-day vulnerability in Sitecore products (CVE-2025-53690) cloud.google.com