TL;DR — CISA has dragged a critical ownCloud flaw back to the top of the queue: CVE-2023-49105 was added to the Known Exploited Vulnerabilities (KEV) catalog on 27 August 2026 with a 30 August federal patch deadline. The bug is an authentication bypass in ownCloud’s WebDAV API — an unauthenticated attacker who merely knows a victim’s username can read, modify or delete that user’s files whenever no signing key is configured, because the server accepts pre-signed URLs without checking that condition. ownCloud fixed it in core 10.13.1 back in November 2023; unpatched 10.6.0–10.13.0 instances remain exposed. NVD and CIRCL both score it 9.8 (Critical, CVSS v3.1).

CRITICALCVE-2023-49105ownCloud WebDAV authentication bypassCVSS V3.19.8 (Critical) — NVD / CIRCLVECTORCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HWEAKNESSCWE-287 — Improper authentication (pre-signed URL)AFFECTEDownCloud Server (core) 10.6.0 – 10.13.0ATTACK VECTORNetwork — unauthenticated, no UI (needs a username)FIXED INownCloud core 10.13.1 (November 2023)EXPLOITEDYes — in the wild (per CISA KEV)CISA KEVAdded 27 Aug 2026 — due 30 Aug 2026
At-a-glance threat summary for CVE-2023-49105.

What Is the ownCloud WebDAV Auth Bypass?

ownCloud is one of the most widely deployed self-hosted file-sync-and-share platforms, running everywhere from home labs to universities, hospitals and government departments that want a private alternative to public cloud storage. Its WebDAV API is the workhorse behind desktop and mobile clients — which is exactly why an authentication flaw in that layer is so dangerous: it sits directly in front of every user’s stored files.

CVE-2023-49105 is an authentication-bypass vulnerability in the way ownCloud’s core validates pre-signed URLs on the WebDAV endpoint. It carries a CVSS v3.1 base score of 9.8 (Critical) and is categorised as CWE-287 (improper authentication). ownCloud shipped a fix in core 10.13.1 in November 2023 as one of three flaws disclosed together (alongside CVE-2023-49103 and CVE-2023-49104); what changed in August 2026 is that CISA now has evidence of renewed active exploitation and has added it to the KEV catalog.

How the ownCloud Auth Bypass Works

In plain terms: an attacker who has never logged in, and who simply knows or guesses a valid username, can craft a WebDAV request that ownCloud treats as if it were properly signed — and then read, change or wipe that user’s files.

The root cause is a broken conditional in ownCloud’s URL-signing logic. ownCloud supports pre-signed URLs: time-limited links whose authenticity is verified with a per-user signing key. The flaw is that when a user has no signing key configured, the server does not fail closed. Instead of rejecting the request outright, the validation path accepts the pre-signed URL as valid, so a completely unsigned or attacker-forged request is honoured against that user’s WebDAV namespace.

Pre-conditions are minimal: the attacker needs network reach to the ownCloud instance and knowledge of a target username (no password, no session, no user interaction). That combination — unauthenticated network access with full read/write/delete over a victim’s files — is why NVD scores it 9.8 (Critical), with confidentiality, integrity and availability all rated High (C:H/I:H/A:H).

An authentication check that fails open is not a check at all. When “no signing key” means “accept everything”, knowing a username is the whole exploit.

ATTACK CHAIN1Identify a target usernameAttacker learns or guesses a valid ownCloud username — no password or session needed.2Craft a pre-signed WebDAV requestA request to the victim’s WebDAV path is built using ownCloud’s URL-signing scheme.3Signing-key check fails openWith no signing key set for the user, ownCloud accepts the unsigned request (CWE-287).4Request is served as authorisedThe WebDAV endpoint processes it over the network with no authentication behind it.5Read, alter or delete the victim’s filesAttacker gains full read-write-delete access to that user’s stored files.
From a known username to full control of a victim’s files, with no login required.

Why This One Bites Harder Than It Looks

There is a nuance worth being honest about. On paper this is a file-access bug, not a remote-code-execution bug — the attacker manipulates files rather than running commands on the host. But the practical impact is severe: a file-sync platform is, by definition, a store of documents people care about, and unauthenticated read means data theft while unauthenticated write/delete means tampering, ransom-style destruction or planting of malicious content that syncs straight down to every trusted client.

The exploit’s single pre-condition — a user with no signing key — is common in practice, because signing keys are not something most administrators consciously configure per user. Combined with a trivially low bar (know a username, reach the server), that is why NVD holds the score at the maximum-adjacent 9.8 and why CISA’s renewed listing matters even though the CVE is nearly three years old.

Active Exploitation of CVE-2023-49105

CISA added CVE-2023-49105 to the Known Exploited Vulnerabilities catalog on 27 August 2026, which by policy means the agency has reliable evidence of exploitation in the wild. The ownCloud flaws first drew mass scanning and opportunistic exploitation within days of their November 2023 disclosure, and the KEV listing indicates that exposed, unpatched instances are being hit again. As of publication, CISA has not attributed the current activity to a named threat actor and has not published targeting or scale details; the KEV entry is the authoritative signal.

DISCLOSURE TIMELINE21 Nov 2023ownCloud discloses CVE-2023-49105; fix ships in core 10.13.1Late Nov 2023Mass scanning and exploitation of the ownCloud flaws observed27 Aug 2026CISA adds CVE-2023-49105 to the KEV catalog (active exploitation)30 Aug 2026Federal remediation deadline (FCEB) under BOD 22-01
Key dates for CVE-2023-49105, from the 2023 patch to the 2026 KEV listing.

The federal remediation deadline is 30 August 2026 for Federal Civilian Executive Branch agencies under Binding Operational Directive 22-01. The obvious exposure is any internet-facing ownCloud instance still running core 10.6.0–10.13.0 — and, given how many self-hosted deployments are stood up once and forgotten, that population is likely larger than most inventories admit.

Remediation & Mitigation: Patching ownCloud

Apply the fix. ownCloud resolved CVE-2023-49105 in core 10.13.1. Because that build is old, the pragmatic move is to upgrade to the latest supported ownCloud release rather than pinning the exact 10.13.1 build — and, if you have the option, to evaluate the maintained ownCloud Infinite Scale (oCIS) line. The key actions:

  • Upgrade ownCloud core to 10.13.1 or later (ideally the newest supported version) on every instance.
  • Do not rely on signing keys as a control. The bug is precisely that a missing signing key bypasses validation — patching is the only reliable fix, not key configuration.
  • Address the sibling advisories. If you are on a pre-10.13.1 build you are likely also exposed to CVE-2023-49103 (graphapi environment disclosure) and CVE-2023-49104 — treat all three together.

If you cannot patch immediately, reduce exposure:

  • Get ownCloud off the open internet where feasible — front it with a VPN or reverse proxy that enforces authentication before requests reach the WebDAV endpoint.
  • Restrict and monitor WebDAV access at the web-server or WAF layer, and alert on anomalous WebDAV requests that reference other users’ paths.

After patching, hunt for prior compromise. Because exploitation leaves relatively ordinary-looking file access, review WebDAV and web-server access logs for unexpected requests to user paths, look for unexplained file reads, modifications or deletions, and check for content that was added and then synced to clients. Where you find evidence of access, notify affected users and treat any exposed credentials or documents as compromised.

Related ZeroDayHub Coverage

Authentication-bypass flaws keep landing on the KEV list because they turn “exposed” straight into “owned”: see the SharePoint authentication bypass exploited in the wild and the N-able N-central authentication bypass — different products, same failure to fail closed.

Sources & Further Reading

Leave a Reply

Trending

Discover more from Zerodayhub

Subscribe now to keep reading and get access to the full archive.

Continue reading