ownCloud authentication bypass (CVE-2023-49105) — knowing a username is enough to read, alter, or delete files without authenticating

1How light the precondition of "knowing a username" is

The stated conditions are that the attacker knows the victim's username and that the victim has no signing key configured. No password, no token. Usernames are frequently inferable — from internal share links, from part of an email address, from an organization's naming convention — and they are not treated as secrets.

That what stands as the precondition for attack is effectively public information is what sets the weight of this vulnerability.

2Pre-signed URLs and the signing key

The vendor advisory frames the issue as an authentication bypass of the WebDAV API using pre-signed URLs. A pre-signed URL embeds proof of validity in the URL itself so that authentication does not have to happen each time. That proof is anchored by a signing key, so where no key is configured, there is nothing for the check to verify against.

A design in which "not configured" collapses into "does not check" rather than "does not pass" is a recurring shape in authentication failures.

3Where self-hosted file sharing sits

ownCloud is a file sync-and-share platform an organization runs itself rather than entrusting to a cloud provider. The flip side of choosing where the data lives is that applying updates and reviewing settings are the operator's responsibility.

Working documents accumulate in a file-sharing platform, so the fact that modification and deletion are possible — not just reading — makes this a question of integrity and availability as much as confidentiality.

4Too little is needed for the attack

Only two conditions are given for the attack to succeed. Neither a password nor a token is required. Following them in order shows where the premise being protected breaks.

1. 1Know a usernameOften inferable from a shared link, part of an email address, or an organisation's naming convention
2. 2The signing key is unsetWhat ought to be verified does not exist at all
3. 3Compose a pre-signed URLA mechanism embedding proof of validity in the URL passes with no proof
4. 4Reach the filesFiles can be read, altered and deleted without authentication

A design in which the unset state falls to "does not verify" rather than "fails verification" is a recurring problem around authentication. ownCloud is a file sync and share platform run in-house rather than entrusted to a cloud provider, and the flip side of choosing where data sits is that applying updates and checking settings both fall to the operator.