Microsoft SharePoint exposure: 163,266 matching assets and a code injection flaw that needs only a user account

SharePoint is one of the few enterprise platforms where an ordinary authenticated user is a meaningful attack position. The exposure figure for SharePoint therefore needs to be read alongside its authentication model rather than in isolation.

Method and scope

Every count in this article comes from ZoomEye international, queried through the official Python SDK on 3 October 2026 between 02:33 and 02:35 UTC. All queries used the sub_type=all scope, which covers devices and websites, with a page size of one. The returned figure is the total match count for the fingerprint, not the number of records retrieved.
A fingerprint match describes what the search engine observed on the wire. It does not confirm that a system runs an affected build, and it does not confirm that a system is exploitable. Exposure data and vulnerability confirmation are separate questions, and the sections below keep them apart.

The disclosed risk

CVE-2026-65660 is a code injection vulnerability in Microsoft SharePoint Server, rated 8.8, and it appears in the Known Exploited Vulnerabilities catalog [1][2]. The distinguishing detail is the privilege requirement. Exploitation requires an authenticated session with low privileges, not administrative rights [1].
Code execution occurs in the context of the SharePoint application pool, which owns the content databases the farm serves [1].

What ZoomEye shows

Query	Scope	Matching assets
app="Microsoft SharePoint"	all (devices and websites)	163,266

The count describes assets where the SharePoint fingerprint was observed. SharePoint farms commonly sit behind a reverse proxy or an identity provider, so the type of endpoint exposed at the perimeter varies. Some deployments publish the farm through a proxy that forwards all requests, which means the vulnerable application code is reachable even though the fingerprint matches the proxy rather than the origin.

Why the authentication requirement is a smaller barrier than it looks

The common mental model treats authenticated flaws as less urgent than unauthenticated ones, on the reasoning that the attacker first needs credentials. For SharePoint that reasoning does not hold well.
Large SharePoint deployments serve thousands of accounts, including external collaborators, vendors and contractors. Any one of those accounts satisfies the authentication requirement. Credential stuffing and password spray campaigns target exactly that population, and a single successful guess converts into a low-privilege session, which is all the flaw requires [1].
The second consideration is the value of what sits behind the account. A SharePoint site collection holds documents, lists and workflow definitions, and the application pool account can reach the content databases. Code execution in that context reaches the data regardless of the permissions the authenticated user was granted [1].

The patch verification problem

SharePoint patching is layered. A farm has the server, the workflow engine, SharePoint Designer customizations and cumulative update history, and each has its own servicing state.
A practical assessment has three steps. Read the exact build number from Central Administration rather than from a patch inventory, because cumulative updates have historically failed to apply silently. Check whether the farm is reachable from outside the corporate network and whether that exposure is still required. Review the site collection administrator list for accounts that no longer need the role.
Where ZoomEye is useful is the second step. A query for the SharePoint fingerprint across the organization's address ranges shows which farms answer publicly, and that list can be reconciled with the internal record of which farms are supposed to be public [3].

Detection and response

SharePoint writes unified logging that can be reviewed for unexpected changes to farm solutions and web part files, IIS worker process restarts without a matching maintenance record, and administrative actions from unusual addresses or hours [2].
If a compromise is suspected, rotate the content database credentials held by the application pool account, because code execution in that context can reach them [1].

Limitations

The count measures fingerprint matches at a single point in time. It cannot confirm the build number behind any match, and it cannot distinguish a production farm from a development environment. The vulnerability description comes from the vendor advisory and the NVD record, and the exact request path is not published in the sources consulted.

References

1. Summary of the exploited SharePoint code injection flaw and its privilege requirement: https://blog.csdn.net/weixin_45635831/article/details/166785623
2. NVD record for CVE-2026-65660: https://nvd.nist.gov/vuln/detail/CVE-2026-65660
3. ZoomEye international search platform: https://www.zoomeye.ai/