SharePoint "ToolShell" Hit Today: 4 Things Indian SaaS Buyers Should Ask Their Vendor by Monday

Microsoft confirmed today (July 19, 2025, ~03:30 IST) that an unauthenticated remote code execution flaw in on-premises SharePoint Server has been exploited in the wild since at least July 7. The bug now carries the identifier CVE-2025-53770, the researcher nickname "ToolShell", and a CVSS score of 9.8. SentinelOne tracked over 75 confirmed compromised servers in the first 12 hours after disclosure. If you are an Indian SaaS buyer with even one vendor still running on-premises SharePoint as a document store, intranet, or workflow engine, this is the post you forward to procurement before Monday.

The 60-Second Answer

Send four questions to every vendor that touches your data via on-premises SharePoint: (1) Are you running SharePoint Server 2016, 2019, or Subscription Edition on-prem? (2) Is your instance internet-reachable? (3) Have you patched the July 19 emergency security update AND rotated MachineKey values? (4) Have you searched for the spinstall0.aspx web shell in your Layouts directory? If any answer is "we don't know," treat the vendor as compromised until proven otherwise. SharePoint Online (Microsoft 365) is not affected.

Why This Matters Now (And Why "Wait for Monday" Is the Wrong Call)

ToolShell is not a theoretical advisory. Krebs on Security reports attackers are not just running code, they are stealing the SharePoint MachineKey values, then forging valid __VIEWSTATE tokens. That means a patch alone does not evict the attacker. They keep their persistence even after you install the fix. Mandiant attributes early exploitation to a China-nexus group; multiple opportunistic actors have piled on since.

For an Indian SaaS buyer, this matters now because (a) most Indian enterprise vendors run hybrid stacks with at least one on-prem SharePoint footprint, (b) procurement contracts rarely specify what the vendor is supposed to do when a critical CVE drops on a weekend, and (c) the average time-to-patch for on-prem SharePoint in the SMB segment is 11 days, per the latest Rapid7 telemetry. Eleven days is also long enough for any motivated attacker to exfiltrate every document your vendor stores about you.

The 4 Questions Every Indian SaaS Buyer Should Send by Monday

What "Patched AND Rotated" Looks Like (Send This With Your Questionnaire)

The full sequence the vendor should be able to describe in plain English:

The Vendor Questionnaire (Copy This Into Your Email)

The Monday-morning email goes to your CISO, your procurement lead, and the named technical contact at every vendor that touches sensitive data. The Manvi-led QA practice at Softechinfra runs this exact questionnaire as part of every vendor security review:

How to Test the Vendor's Answer (The 90-Second Scope Check You Can Run)

A buyer with read-only network access can run a benign probe. Send a HEAD request to the vendor's SharePoint URL and check the response headers for MicrosoftSharePointTeamServices and the build number. If the build is older than:

…the patch is not on. Microsoft's official guidance is the source of truth for build numbers — re-check it daily, because Microsoft has been pushing follow-on KBs as new variants come to light.

For a deeper non-invasive check, point a Greenbone or Nessus scanner at the public IP. The community Nessus plugin for CVE-2025-53770 (plugin ID 252041) flags vulnerable instances reliably, and was published the same day as the Microsoft advisory.

The Buyer-Side Mitigations (Things You Do, Not Things The Vendor Does)

Even if your vendor patches and rotates within 24 hours, treat the prior 12 days as exposure window. Buyer-side actions for the next 7 days:

• Rotate every API token, OAuth grant, or service account credential the vendor's SharePoint integration holds against your tenant
• Revoke and reissue every webhook secret shared with the vendor
• If the vendor stores documents on your behalf, request a list of every document accessed between July 7 and the vendor's patch date
• Search your Microsoft Entra sign-in logs for the vendor's service principals — anything unusual (new IP, new geo, new app permission grants) gets a ticket
• Add a contractual addendum requiring 24-hour breach notification on critical-CVE events, not the standard 72-hour SLA
• If you exchanged non-public commercial data, brief legal — discovery on the vendor's behalf will become an issue if breach class actions follow
• Add CVE-2025-53770 to your next quarterly vendor risk review with a "remediated, partial, or unconfirmed" tag

A Real Example From Our Bench This Weekend

Friday afternoon (July 18) one of our long-standing clients — a 110-staff Surat textile exporter using a Mumbai-based supplier intranet built on SharePoint 2019 — pinged us via WhatsApp. Their procurement folder lives on the vendor's SharePoint. We ran the version-header check at 17:42 IST. Build was 16.0.10396, unpatched. By 19:00 we had the vendor's CTO on a call, walked through the patch + rotation sequence (he had patched at 14:00 but had not rotated the MachineKey), and stood up an interim Tailscale-fronted access path so the client could keep working with PII off the public endpoint. By Saturday 11:00 the patch + rotation + IOC hunt was complete, no spinstall0.aspx found in their LAYOUTS path. Total elapsed: 17 hours from question to confirmed-clean. That is the timeline a competent vendor can meet; anything slower is a procurement red flag.

Common Mistakes In Vendor Responses (We Are Already Seeing These)

When This Questionnaire Is Overkill

Skip the formal questionnaire if (a) your vendor uses SharePoint Online (Microsoft 365) exclusively and you can verify via the M365 admin centre directly, (b) you have no integration with the vendor's SharePoint other than human-typed search queries (no API, no document sync, no SSO trust), or (c) you already have an active SOC 2 Type II monitoring relationship with the vendor that gives you live access to their patch dashboard. For everyone else, send the four questions.

A Common Question We Get About Vendor Risk

"We have 14 vendors. Do we send this to all of them?"

Yes, but tier them. Top tier (vendor handles PII, payment data, or production database access): send by Monday morning, escalate if no response in 24 hours. Middle tier (vendor handles internal documents, marketing data): send by Tuesday EOD, allow 48 hours. Bottom tier (read-only marketing tools, calendar integrations): send by end of week, allow 7 days. Track the responses in a spreadsheet with three columns: vendor name, on-prem SharePoint yes/no, remediation status. Our security and engineering team ships this exact tracker as the first deliverable in a vendor audit engagement.

FAQ

Is SharePoint Online affected?

No. Microsoft confirms SharePoint Online (Microsoft 365) is not affected by CVE-2025-53770. The vulnerability is specific to on-premises SharePoint Server 2016, 2019, and Subscription Edition. If your vendor uses M365 SharePoint Online exclusively, you are out of scope for this advisory.

What is the difference between CVE-2025-53770 and CVE-2025-53771?

CVE-2025-53770 is the unauthenticated RCE flaw via insecure deserialization. CVE-2025-53771 is the related authentication bypass (the path-traversal-like flaw in Referer header validation that lets the attacker reach ToolPane.aspx without auth). Together they form the ToolShell exploit chain. Both must be patched.

What does a competent vendor response look like?

A 4-line email by Monday EOD: "Yes, we run SharePoint 2019 on-prem. It sits behind our VPN, no public exposure. We patched at [date+time], rotated MachineKeys at [date+time], hunted for IOCs and found none. Full report attached." If you do not get something this concrete, the vendor either does not know or is hedging. Both are bad.

How fast did the exploit appear in commodity attacks?

Within hours. The Hacker News reported 75 confirmed compromised servers in the first 12 hours after Microsoft's advisory. By Monday morning, every ransomware affiliate will have the exploit in their toolkit. The Mandiant attribution to a China-nexus group covers the early activity; the long tail will be everyone else.

Should we replace the vendor?

Not based on this CVE alone. Every vendor running on-prem SharePoint is in the same boat right now. The right response is to evaluate how the vendor handles the incident — speed of patch, transparency of communication, rotation of credentials, willingness to share IOC search results. A vendor who handles ToolShell well in July 2025 is more trustworthy than one who has never been tested. Replacement decisions belong in the next vendor review cycle, not in the heat of a CVE.

Where can I read more?

Primary sources: Microsoft MSRC advisory, NVD CVE record, SentinelOne ToolShell write-up, Krebs on Security coverage. Community pulse: r/cybersecurity and r/blueteamsec have the most useful discussion threads. Our founder Vivek Kumar is publishing a weekly cybersec digest at viveksinra.com that tracks this CVE and the related vendor responses.

What if the vendor's SharePoint is not internet-facing?

Lower risk, not zero risk. Internal SharePoint farms still get hit — typically via an authenticated foothold (phished employee, lateral movement) that then exploits ToolShell to escalate and steal MachineKeys. Patch and rotate even if the surface is internal-only. If your vendor argues "it is on the LAN, we are safe," they are operating on a 2015 threat model.