A 2023 ownCloud flaw resurfaces and opens files with no credentials at all

November 2023. ownCloud ships the 10.13.1 fix for CVE-2023-49105, a WebDAV authentication flaw rated CVSS 9.8. 27 August 2026. CISA adds that same flaw to its KEV catalog of actively exploited vulnerabilities. 30 August 2026. Federal remediation deadline. In between, nearly three years passed — and the flaw is still there.

This is not a new zero-day. It is a critical, long-patched vulnerability that thousands of instances never fixed, and that attackers have finally adopted.

A WebDAV door left open by default

CVE-2023-49105 is an improper authentication flaw in the WebDAV functionality of ownCloud Server. The mechanism relies on pre-signed URLs: a client can present an already-signed URL to reach a file without re-sending credentials on every request.

The defect is that the application accepts those pre-signed URLs without validating the condition that should make them legitimate. Concretely, an unauthenticated attacker who knows a victim’s username can read, modify, or delete their files — provided the instance has no signing key configured. And that signing key is not configured by default.

The result is read-write access to a user’s files with no password, no token, and no interaction. The only piece of information required is a username, often trivial to guess or harvest.

Affected versions run from 10.6.0 to 10.13.0. The fix is 10.13.1, released in November 2023; the vendor now points operators at the current 10.13.3 line. The managed ownCloud Infinite Scale and ownCloud.Online services are not affected.

What pre-signed URLs are supposed to do

ownCloud’s WebDAV was built so that desktop clients and third-party apps could reach files without re-sending a password on every request. The principle is simple: the server signs a URL with a signing key, and that signature guarantees the URL has not been tampered with and remains valid for the targeted resource. The client presents the signed URL, the server checks the signature, and access is granted.

CVE-2023-49105 exists because that check is conditional: if no signing key is configured — which is the installation default — the server still accepts pre-signed URLs without validating anything. The door stays open while the lock was never fitted. It is a textbook case of unsafe-by-default configuration: the fix does not merely add a check, it makes the server reject the pre-signed URL when the key is missing.

This mechanism also explains why exploitation is so quiet. The attacker breaks nothing: they use the feature as designed, except that nobody closed the condition. Logs show nothing unusual — legitimate WebDAV access to legitimate files, simply initiated by someone else. That is what makes retrospective detection hard and the investigation essential.

The original disclosure context deserves a note: CVE-2023-49105 was revealed in November 2023 by ownCloud, alongside another critical flaw — CVE-2023-49103 — in the graphapi app. That round of patches touched tens of thousands of self-hosted instances. Nearly three years later, its KEV listing simply says not everyone followed through.

Why a 2023 flaw becomes a problem again in 2026

The KEV re-listing three years later tells a well-known mechanics that is still rarely baked into patch management: patching debt does not disappear — it accumulates until it becomes a market.

A critical flaw fixed by the vendor does not vanish from the landscape on the day the patch ships. It vanishes from attention. Teams that missed the original update — for lack of time, inventory, or because the instance was not judged “sensitive” — leave it in place. Three years later, attacker scanners know it by heart and chain it automatically.

The ownCloud case is worsened by a usage factor: this software is typically self-hosted by organizations without a dedicated security team — associations, small public bodies, SMBs, labs. The instance is often exposed to the internet precisely to allow file sharing with the outside world, which is the maximum-exposure scenario for this flaw.

The operational reality of self-hosting compounds the risk. These instances are usually set up once and left running — no central update channel, no fleet manager, no security team triaging advisories. The person who installed the server may have moved on, taking the signing-key knowledge with them. The result is a population of instances that are at once critical, because they hold real files, and orphaned, because no one owns their patching cycle. Attackers understand this demographic precisely, which is why a flaw disclosed in 2023 can still find fresh victims three years later.

CISA marked this entry “forensic triage: yes”. Translated operationally: unpatched, exposed instances must be treated as probable compromises, not as machines to patch at leisure.

What to do

The response combines an inventory, an upgrade, and an investigation.

• Inventory the instances. Identify every self-hosted ownCloud Server 10.x, prioritizing those reachable from the internet. Confirm the version via the admin UI or the occ status command.
• Upgrade without delay. Move to 10.13.1 at minimum, ideally the current 10.13.3 line. The fix rejects pre-signed URLs when no signing key is configured.
• Configure a signing key. Beyond the patch, setting a WebDAV signing key closes the underlying design gap — do not stop at the version bump.
• Investigate. Look for unexpected file downloads or deletions, new shares, WebDAV access from unknown IPs, and changes to signing keys. Any unpatched instance running before the fix is a compromise candidate.

# Confirm the version of an ownCloud instance (from the install directory)
sudo -u www-data php occ status

# Search WebDAV access in the logs (generic example)
grep -i "webdav" /var/log/owncloud/owncloud.log | tail -50

# Check whether a WebDAV signing key is configured
sudo -u www-data php occ config:app:get webdav signing-key

The upgrade and the investigation are two halves of the same response, and neither is optional. Patching without hunting leaves a possible compromise in place; hunting without patching leaves the door open for the next attacker. For a flaw that has been sitting unpatched since 2023, the only defensible posture is to do both, in that order, on every exposed instance.

Verdict

If you run an exposed ownCloud 10.x instance, the upgrade to 10.13.1 or later is today’s urgency, not a maintenance task: the flaw is unauthenticated, critical, and now actively exploited. The compromise investigation is part of the same move, since CISA makes it mandatory for the federal perimeter.

If you manage a fleet of self-hosted services, the lesson goes beyond ownCloud: a critical vendor-patched flaw is a shooting window until your inventory closes it. The KEV re-listing is a reminder that a CVE’s age does not make it harmless — it makes it more exploitable, because attackers have had time to industrialize it.

References

• CISA Adds Three Known Exploited Vulnerabilities to Catalog — CISA, 27 August 2026
• U.S. CISA adds ownCloud, Linux Kernel, and JFrog Artifactory flaws to its KEV catalog — Security Affairs, 28 August 2026
• WebDAV API Authentication Bypass Using Pre-Signed URLs — ownCloud Security Advisory
• August 27 2026 CVE Threat Brief — Carthage Electronics
• CVE-2023-49105 — NVD