ownCloud in KEV: a WebDAV authentication bypass through pre-signed URLs

CISA added CVE-2023-49105 to its Known Exploited Vulnerabilities catalog. It is a vulnerability in ownCloud that allows access to files through the WebDAV API without authentication. For anyone who runs an external perimeter, the key question is simple: do you have an ownCloud instance reachable from the internet, and if you do, how is it configured?

When a KEV alert arrives, the first action is to establish what actually sits behind the company's external IP addresses. ownCloud is often deployed as an internal file server, but it sometimes turns out to be facing outward — directly or through a load balancer. If port 80 or 443 is open and answers with an ownCloud service, that host has to be checked, even if access was assumed to be possible only from the corporate network.

What exactly is broken

The ownCloud advisory describes the issue as an authentication bypass in the WebDAV API using pre-signed URLs. Normally, access to resources over WebDAV requires authorization: the client sends a request, the server validates the credentials. In this case a path was found where a specially crafted URL bypasses that check.

• Affected versions: ownCloud 10.6.0 through 10.13.0. The fix ships in 10.13.1.
• CVSS score assigned to the issue: 9.8.
• Conditions described by the vendor: the attacker needs to know a username, and the owner of the files must have no signing key configured.

The result is a broken access control: a request can reach data without a login and password. According to the vendor description, that covers reading, modifying and deleting the affected user's files — not control over the server itself. For a file store this matters, because the value of the data is higher than the operational stability of the system.

Why this concerns the external perimeter

ownCloud is rarely the only service on a machine, but it often stands out by its characteristic response to an HTTP request. The problem appears where a domain or IP address that was meant to stay internal has become public. The reasons vary:

1. An engineer configured a reverse proxy for testing and forgot to remove the routing rule once the work was done.
2. The service was deployed on a VPS for a quick project start, the project closed down, and the machine kept running.
3. A provider change or a network migration left an old IP address — still referenced by a DNS record — reachable from outside, although it used to sit behind NAT.

How to check your own perimeter

An attack on your infrastructure cannot be reproduced from the outside on your behalf, but the steps below help determine whether you have vulnerable assets. They run from the simple to the more involved.

Step 1. Inventory of open ports

Start with a list of every public IP address that belongs to the organization. If you have no exact list, use passive OSINT sources or internal monitoring systems that track inbound traffic. Then run a basic scan of 80/TCP and 443/TCP. The goal of this stage is to find hosts that answer web traffic from an external network.

It is worth checking more than the addresses assigned to production sites. The inventory should take in cloud accounts, VPS instances, old test environments, load balancer addresses and domains that are still present in DNS. Temporary and forgotten resources are the ones that most often fall out of the internal register while continuing to answer requests from outside.

Step 2. Identifying ownCloud

Not every web server is ownCloud, and it has to be told apart from other file storage systems. Send a GET request to the root directory of the addresses you found. Look at the response body and the headers for strings that identify the ownCloud interface — for example <title>Log in · ownCloud</title> or similar interface elements. You can also try requesting static files characteristic of this product. If such a file comes back with a 200 code and the correct MIME type, the probability that you are looking at ownCloud is very high.

Account for virtual hosting. A request straight to the IP address may return a default page, while ownCloud is only reachable with the right Host header value. Results of IP scanning therefore have to be matched against DNS records and the names configured in the reverse proxy or the load balancer. A redirect to another name should be followed through to the final response, rather than treating the original address as empty.

Version is also worth a look. In some ownCloud versions, certain endpoints disclose the version number. If you manage to read it, compare it against the ownCloud advisory to see whether it falls inside the affected range. If the version cannot be determined from outside, that does not prove the vulnerability is absent: the information then has to come from package management, the container image, the admin panel or the deployment configuration.

Step 3. Assessing the pre-signed URL configuration

This is where the important part begins, and a limit appears immediately: you cannot safely check for the presence of the exploit without attempting to use it. Any attempt to send a malformed pre-signed URL may be logged by a security system — a WAF or an IDS — and raise an alarm. External audit therefore comes down to risk assessment:

1. Is there file access without authentication? Try requesting known WebDAV API paths. If instead of a 401 Unauthorized error you get a folder listing or an XML response with data, that is a serious red flag.
2. Is HTTPS in use? If the connection runs over HTTP, traffic is easy to intercept, and passing any tokens or session cookies becomes unsafe. But even with HTTPS, the logic error in signature validation remains.
3. Is there a WAF? A Web Application Firewall in the path may block suspicious patterns in the URL. But KEV vulnerabilities are often exploited using legitimate request formats that a WAF lets through.

A check of a known WebDAV path should be performed only against your own host and without touching user files. Its purpose is to see the expected access denial, not to demonstrate that data can be read. If the result is ambiguous, it is better to establish the patch state from the software version and the vendor advisory than to extend an external test into exploitation.

If you find an exposed ownCloud, assume the worst: it is vulnerable until proven otherwise. The patch should be applied immediately, whatever the current configuration. If the update cannot be installed straight away, the external route to the service should be closed, or access restricted to a VPN or the internal network until the work is complete.

Where the chain could have been broken

Consider this incident from the prevention side. CVE-2023-49105 was known before it entered KEV. Even so, some systems could have stayed unpatched because of gaps between asset accounting, vulnerability assessment and the operation of the services themselves.

Failure point one: no regular audit of the external perimeter

Many organizations know their assets inside the DMZ but lose visibility of the hosts that were moved outward for short-term tasks. Where creating a new external service requires going through the security team, such cases are rarer. Where any engineer can open a port on a load balancer without registering it in the inventory, the risk grows.

An asset register on its own does not solve the problem if it is never reconciled with the observed state of the network. The record may say that ownCloud is reachable only internally, while the publishing rule on the reverse proxy stayed in place after testing. Inventory therefore has to compare administrative data with what actually answers on public addresses and domain names.

Failure point two: patch prioritization

In an environment where hundreds of services need updates, a CVE that is not yet in KEV often ends up at the back of the queue. An entry appearing in the CISA KEV catalog should automatically raise the priority to the maximum. If the vulnerability management system is not integrated with the KEV feed, the team loses that signal.

Assigning a high priority is not enough on its own. For each instance found, the external address, the service owner, the installed version and the patch status have to be tied together. Otherwise the update ticket can exist separately from the host that is actually published, and the team will not be able to confirm that it closed the very instance visible from the internet.

Failure point three: the architecture around ownCloud

File servers are high-interest targets by nature, because they hold confidential documents. Placing such a service in the internet zone without additional protection — for example two-factor authentication at login, strict rate-limiting rules and network isolation — creates excess risk. Even after the fix is installed, external access should match real need: if WebDAV is used only by employees, publishing it to the whole internet is not required.

The practical output of the check should not be a list of open ports. It should be a list of ownCloud instances with their domains and IP addresses, versions, owners, the way each one is published externally and its update status. A list like that distinguishes a confirmed fix from a situation where the scan merely stopped seeing the login page because routing changed.