An ordinary SharePoint login is enough to exploit the KEV-listed CVE-2026-65660

The write-up that published the scan count, on dev.to, describes the common model first. Authenticated flaws rank below unauthenticated ones because the attacker needs credentials before anything else. For SharePoint, the author argues, that reasoning does not hold well ^[11]. Credential stuffing and password spray campaigns go after exactly the account population a large farm carries. One correct guess produces the low-privilege session the flaw requires ^[13].

No administrative rights are needed ^[3]. A site collection holds documents, lists and workflow definitions. Code running in the application pool context reaches that data whatever permissions the logged-in user was granted ^[5].

The ZoomEye figure is a total match count. The author queried ZoomEye's international index through the official Python SDK between 02:33 and 02:35 UTC ^[6]. The queries used sub_type=all, which covers devices and websites, with a page size of one, so the number is the match total and not a set of retrieved records ^[7]. A page size of one is the cheap way to ask a search engine for a total.

For that count to transfer into a risk estimate, each match would have to be a production farm on an affected build. A fingerprint confirms neither ^[8]. The snapshot is a single point in time and cannot separate production from development ^[9]. The count can also hide reachable farms. A farm published through a proxy that forwards every request leaves the vulnerable application code reachable, while the fingerprint matches the proxy and not the origin ^[10].

The author's assessment runs in order:

1. Read the exact build number from Central Administration, not from a patch inventory, because cumulative updates have historically failed to apply silently ^[15]. 2. Confirm whether the farm can be reached from beyond the corporate network, and if it can, whether it still has to be ^[16]. A ZoomEye fingerprint query across the organization's own address ranges, reconciled against the internal record of which farms should be public, covers this step ^[18]. 3. Review the site collection administrator list for accounts that no longer need the role ^[17].

Step one goes to the farm itself because SharePoint patching is layered. The server, the workflow engine, SharePoint Designer customizations and the cumulative update history each have their own servicing state ^[14].

For this CVE I'd extend step three. The flaw asks for an ordinary session, not an administrative one ^[3]. The review that shrinks exposure covers the external collaborator, vendor and contractor accounts that no longer need access, since any one of them satisfies the login requirement ^[12]. That is a judgement for farms with a large outside account base; a farm whose every login is a managed employee account has less to gain from it.

The write-up's description of the vulnerability comes from the NVD record and the vendor's advisory, and none of the sources it consulted give the exact request path ^[21].