ZoomEye's CVE-2023-49105 count matches its entire ownCloud fingerprint at 152,655 hosts

Two different queries rarely land on the same six-figure total by accident. Here the gap is zero, so by count the CVE-tagged set is the whole fingerprinted set ^[1]. The post's author reads this as ZoomEye's CVE index and its ownCloud fingerprint resolving to the same assets ^[5].

If that reading holds, the CVE tag is a product label. Only ownCloud core before 10.13.1 is affected ^[1]. A tag that covers every fingerprinted host also covers any patched instances in the set. The author says it directly: "A CVE-index match is not a confirmed vulnerable host." ^[6] For 152,655 to become an exposure figure, a scanner would have to see two things from outside: the core version, and whether each file owner has a signing key. The second is a server configuration state ^[9]. I would not expect a remote fingerprint to see it.

Both preconditions for the bypass are cheap to meet. Usernames show up in login pages, email addresses and public documents ^[8]. A missing signing key stays missing until someone configures one ^[9]. That persistence is why the post tells operators to set a signing key for every file owner on any version. It calls the setting both the workaround and a permanent requirement ^[10]. Upgrading to 10.13.1 fixes the code ^[1]. It does not create keys that were never set ^[9].

The same persistence explains the inherited-server problem. According to the post, file sync platforms are long-lived, frequently exposed for remote work and often inherited by teams that did not choose them ^[11]. It advises re-measuring your own address ranges. It treats a persistent fingerprint match there as a strong indicator of an installation nobody has reviewed ^[14]. I would limit that advice to ownCloud instances, since the flaw is in ownCloud core ^[1].

Patching also leaves open whether someone already got in. For detection, the post suggests reviewing WebDAV access logs for pre-signed URL requests that match no legitimate share. Those requests may have no user identity attached, and the post treats that gap as the signal ^[12]. It also recommends auditing file integrity for the exposed period and checking for standing access added during it. That includes new shares, and application passwords that survive a password reset ^[13].

The timeline in the post disagrees with itself. It says the flaw reached the exploited catalog three years after disclosure ^[15]. Later it refers to a five-year window between disclosure and exploitation ^[16]. A 2023 identifier and a 2026 listing fit three ^[3]. The scan ran 28 days after the listing ^[2]. A page size of one is plenty when the total is all you want. The post publishes both query strings, the 02:36 UTC collection time and the all-asset scope, so anyone can rerun the count ^[3][4].