CVE-2023-49105: ownCloud Improper Authentication Vulnerability
ownCloud contains an improper authentication vulnerability that allows an attacker to access, modify, or delete any file without authentication if the username of a victim is known, and the victim has no signing-key configured.
Overview
ownCloud Server versions 10.6.0 through 10.13.0 contain an authentication bypass in the WebDAV API that stems from how the platform handles pre-signed URLs when no signing key is configured. Because signing keys are absent by default, an attacker who knows a valid username can forge a pre-signed URL with an empty secret and gain full unauthenticated access to that user's files. Read, write, and delete operations are all reachable, meaning an attacker can exfiltrate, alter, or destroy any file owned by the targeted account. Active exploitation against real organizations has been observed.
Vulnerability details
ownCloud's WebDAV API supports pre-signed URLs as a mechanism for delegated, time-limited file access. The signing process is supposed to bind a URL to a secret key held by the file owner, so the server can verify the request is legitimate. The flaw, rooted in improper initialization (CWE-665) and improper authentication (CWE-287), is that when a file owner has no signing key configured, the server does not reject pre-signed requests outright. Instead, it accepts them regardless of whether the embedded signature is valid, including signatures generated with an empty or null secret. Because signing keys are absent by default, the overwhelming majority of accounts are vulnerable without any additional misconfiguration.
An attacker who can reach the ownCloud WebDAV endpoint and knows a valid username on the instance can craft a pre-signed URL using an empty signing secret and submit it directly to the API. No credentials, session token, or prior authentication are required. The server accepts the request as though it were legitimately signed, granting full read, write, and delete access to every file owned by the targeted account. Threat intelligence reporting documents a suspected Chinese-speaking operator using exactly this technique against a Philippine nuclear research organization, generating pre-signed URLs with an empty secret to retrieve files over WebDAV without authentication.
Severity and impact
Exploitation status
This vulnerability is confirmed as actively exploited in the wild — it is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.
Detection and monitoring
- Monitor WebDAV request logs for file access, modification, or deletion events that carry no associated authenticated session or valid credential record. Requests succeeding without a matching login event are a strong indicator of exploitation.
- Audit ownCloud access logs for requests to WebDAV endpoints that include pre-signed URL parameters (such as OC-Credential, OC-Date, OC-Expires, OC-Verb, or OC-Signature) originating from unexpected source IPs or at unusual hours, particularly where the targeted account has no signing key configured.
- Review server-side logs for bulk file retrieval patterns against a single username from a single external IP, which matches the documented attacker behavior of scripted, per-file exfiltration over WebDAV.
Remediation
Additional hardening
- Upgrade ownCloud Server to version 10.13.1 or later, which denies pre-signed URL requests when no signing key is configured for the file owner, closing the authentication bypass entirely.
- For accounts that cannot be patched immediately, configure a signing key for every user account. The absence of a signing key is the direct precondition for exploitation; accounts with a key configured are not affected by this bypass.
- Restrict network access to the ownCloud WebDAV endpoint to known, trusted IP ranges. Reducing external exposure limits the attacker's ability to reach the vulnerable API without requiring authentication.
- Audit ownCloud user accounts for the presence of signing keys and treat any account without one as at risk. Prioritize accounts with access to sensitive files for immediate key assignment or access suspension until patching is complete.
Key dates
References
- https://owncloud.com/security-advisories/webdav-api-authentication-bypass-using-pre-signed-urls/
- https://owncloud.org/security
- https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
- https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk
- https://nvd.nist.gov/vuln/detail/CVE-2023-49105
- https://hunt.io/blog/chinese-speaking-operator-philippine-nuclear-naval-contractor
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-49105
Frequently asked questions
Does CVE-2023-49105 affect my FedRAMP authorization?
If ownCloud runs inside your authorization boundary, yes. CVE-2023-49105 appears on CISA's Known Exploited Vulnerabilities (KEV) catalog, with a remediation deadline of August 30, 2026. For a FedRAMP-authorized service, an unpatched KEV within the boundary is an assessor finding. You must either remediate it or formally document a mitigation before your assessor and sponsoring agency raise it as a deficiency.
How does Knox help me handle CVE-2023-49105?
Knox does not patch your ownCloud instance. Remediation is your responsibility under the FedRAMP shared-responsibility model. What Knox provides is the pre-authorized, single-tenant boundary to remediate within, along with Knox's automated continuous monitoring platform and audit-artifact coverage that document the fix for your next assessment. Applying the patch is yours to own; maintaining a defensible compliance posture while you do it is not something you manage on your own.
How does Knox's monitoring help with vulnerabilities like this?
Knox's automated continuous monitoring platform watches your environment for newly disclosed vulnerabilities and compliance issues on a continuous basis. For a critical finding like CVE-2023-49105, that means exposure surfaces during ongoing monitoring rather than waiting until an assessor flags it at a scheduled review.
How do I get FedRAMP authorized with Knox?
Knox runs a FedRAMP-as-a-Service platform. It gives SaaS vendors a pre-authorized cloud boundary on AWS, Azure, and GCP. Your application inherits 60-80% of the required security controls. You reach FedRAMP authorization in about 90 days for roughly 90% less than the traditional $3.5M path. Book a meeting and Knox will map your path to authorization.
What happens if CVE-2023-49105 isn't remediated by August 30, 2026?
Missing the August 30, 2026 deadline turns CVE-2023-49105 into a Plan of Action and Milestones (POA&M) item. A growing POA&M list is what converts a routine continuous-monitoring review into a difficult conversation with your sponsoring agency. Remediating by the deadline keeps your authorization standing clean and the agency relationship intact.
Ready to achieve FedRAMP authorization in 90 days or less?
Schedule a meeting to discuss scope, parse readiness, and map your company’s accelerated path to FedRAMP authorization.
_Horizontal_RGB.png)
