CISA lists ownCloud pre-signed URL bypass as exploited; ZoomEye counts 152,655 instances

CISA has added CVE-2023-49105 to its Known Exploited Vulnerabilities catalog, with the addition dated 27 August 2026, according to a dev.to analysis of the flaw. The vulnerability is described there as an authentication bypass affecting ownCloud core releases before 10.13.1. Separately, the author measured the exposed population with ZoomEye on 24 September 2026: a query for app="ownCloud" returned 152,655 matches, and a query for vul.cve="CVE-2023-49105" returned exactly the same figure.

When two queries agree exactly

Two unrelated filters producing identical totals is rare enough to demand an explanation. The dev.to post reads the overlap as ZoomEye's CVE index and its product fingerprint resolving to the same set of assets — in effect, every host the index associates with this vulnerability is also one it identifies as ownCloud, and the two populations appear to coincide completely.

The author is careful about the limits of that reading: a match in the vulnerability index means an asset is linked to the CVE in ZoomEye's data, not that the host is confirmed exploitable. Identical counts show that two datasets coincide; they do not constitute a census of vulnerable machines. Even so, a six-figure population of internet-facing file-synchronization servers is the actionable number here.

A flaw that stays exploitable until someone acts

According to the post, the underlying defect is that pre-signed URLs were accepted even when no signing key had been configured for the file owner. In that state, knowing a username was enough to read, modify or delete another account's files.

Neither precondition is difficult to satisfy. Usernames surface on login pages, in email addresses and in public documents, and a missing signing key is a configuration state that persists until someone deliberately changes it. Together, the author argues, these factors explain why unpatched installations can remain exploitable for years.

What operators should do now

The remediation steps the post lays out:

• Upgrade to ownCloud 10.13.1 or later.
• Configure a signing key for every file owner regardless of version, since the setting doubles as both the interim workaround and a standing requirement.
• Review WebDAV access logs for pre-signed URL requests that do not line up with a legitimate share. Such requests may arrive with no user identity attached, and that absence is the tell.
• Audit file integrity across the exposure window.
• Check for standing access created during that window, including new shares and application passwords, which remain valid even after a password reset.

The author also recommends re-measuring your own address ranges. For a flaw that reached the exploited catalog years after its 2023 disclosure, a persistent fingerprint match in your address space is a strong indicator of an installation nobody has reviewed.

Why it matters

A spot on CISA's catalog signals evidence of active exploitation, and this entry landed roughly three years after the CVE was assigned. The ZoomEye measurement — 152,655 hosts, with the vulnerability index and the product fingerprint overlapping completely — points to a large pool of servers that tend to stay online for years, serve remote file access, and get handed down to teams that never opted to run them, as the dev.to author notes. For anyone operating ownCloud, patching and signing-key configuration are cheap and immediate, and logs from the exposure period are worth auditing even on instances that appear untouched.