Insufficient permission checks allow unauthorized external storage in ownCloud Server

ownCloud Server before 5.0.16 and 6.0.x before 6.0.3 does not check permissions to the files_external application, which allows remote authenticated users to add external storage via unspecified vectors.

• ownCloud Server 5.0.x: affected before 5.0.16; NVD configuration data identifies the scope through and including 5.0.15. The supported fixed release is 5.0.16.
• ownCloud Server 6.0.x: affected before 6.0.3. The supported fixed release is 6.0.3.
• The normalized record also contains a generic owncloud product entry without its own version boundary. That entry does not establish additional scope beyond the branches listed above, and the status of other branches is not verified.

This is an access-control failure in ownCloud Server: permissions for the files_external application are not properly enforced, consistent with CWE-264. The attacker must have a valid ownCloud account and remote access to the server. When the permission check is bypassed, an authenticated user can add external-storage configuration without the corresponding authorization. The evidence does not identify the exact endpoint, request, storage backend, or additional deployment conditions involved. It also does not establish that the flaw alone permits access to existing data, code execution, or privilege escalation.

The flaw is remotely reachable and requires an authenticated user. The record characterizes attack complexity as low, but does not identify the specific endpoint, request, or attack vector. No requirement for victim interaction is documented. The record does not establish whether the flaw has been exploited in the wild or whether a public exploit exists; those statuses are unknown rather than confirmed negative.

The technical outcome is an unauthorized configuration change: a remotely authenticated user can add external storage without the required permission. The recorded impact includes partial effects on integrity and availability, while no confidentiality impact is recorded in the supplied assessment data. The flaw is not established as a privilege-escalation mechanism, code-execution path, or means to access other users' data. Organisational consequences may include unapproved storage configuration, weakened control over data placement, or disruption of storage operations, depending on the account and backend configuration.

The flaw lets an authenticated account change external-storage configuration without the required authorization. This can create unapproved storage locations, affect the integrity of storage configuration, and potentially disrupt or redirect storage operations. The available evidence does not confirm data disclosure, access to existing files, or code execution through this flaw. The practical consequence depends on the abused account's permissions, the external-storage backend, and the deployment configuration.

1. Upgrade the 5.0.x branch to the exact fixed release 5.0.16, or upgrade the 6.0.x branch to the exact fixed release 6.0.3.
2. After upgrading, verify permissions for the files_external application and review existing external-storage entries for unapproved changes.
3. Review available audit or application logs for external-storage additions performed by unauthorized accounts.
4. The available evidence does not document a specific temporary workaround. Do not assume that other release branches are safe merely because one branch has a fix; inventory and verify each branch separately.

1. Inventory ownCloud deployments and identify the exact release branch in use.
2. Verify whether the files_external application is enabled and review which users, groups, or roles can add external storage.
3. Compare existing external-storage configurations with an approved baseline, focusing on new or changed entries created by unauthorized accounts.
4. If audit or application logging is available, review events for external-storage additions or changes and correlate the account, time, and source address. This is precautionary monitoring; the available evidence does not provide a specific log signature or IOC.
5. Do not treat the absence of suspicious events as proof that a deployment is safe.