Une faille ownCloud de 2023 refait surface et ouvre les fichiers sans le moindre identifiant

Novembre 2023. ownCloud publie le correctif 10.13.1 pour CVE-2023-49105, une faille d’authentification WebDAV notée CVSS 9,8. 27 août 2026. La CISA inscrit cette même faille à son catalogue KEV des vulnérabilités activement exploitées. 30 août 2026. Échéance fédérale de correction. Entre les deux dates, près de trois ans se sont écoulés — et la faille est toujours là.

Ce n’est pas un nouveau jour zéro. C’est une vulnérabilité critique, corrigée depuis longtemps, que des milliers d’instances n’ont simplement jamais patche — et que des attaquants ont fini par adopter.

Une porte WebDAV ouverte par défaut

CVE-2023-49105 est une faille d’authentification impropre dans la fonctionnalité WebDAV d’ownCloud Server. Le mécanisme repose sur des URL pré-signées (pre-signed URLs) : un client peut présenter une URL déjà signée pour accéder à un fichier sans renvoyer ses identifiants à chaque requête.

Le défaut tient au fait que l’application accepte ces URL pré-signées sans valider la condition qui devrait les rendre légitimes. Concrètement, un attaquant non authentifié qui connaît le nom d’utilisateur de sa victime peut lire, modifier ou supprimer ses fichiers — à condition que l’instance n’ait pas configuré de clé de signature. Or cette clé de signature n’est pas configurée par défaut.

Le résultat est un accès en lecture-écriture sur les fichiers d’un utilisateur, sans mot de passe, sans jeton, sans interaction. La seule information requise est un nom d’utilisateur, souvent trivial à deviner ou à collecter.

Les versions concernées vont de 10.6.0 à 10.13.0. Le correctif est la version 10.13.1, publiée en novembre 2023 ; l’éditeur recommande aujourd’hui de viser la branche courante 10.13.3. Les services managés ownCloud Infinite Scale et ownCloud.Online ne sont pas affectés.

Ce que sont censées faire les URL pré-signées

Le WebDAV d’ownCloud a été conçu pour que les clients lourds et les applications tierces puissent accéder aux fichiers sans renvoyer un mot de passe à chaque requête. Le principe est simple : le serveur signe une URL avec une clé de signature, et cette signature garantit que l’URL n’a pas été altérée et qu’elle reste valable pour la ressource visée. Le client présente l’URL signée, le serveur vérifie la signature, et l’accès est accordé.

La faille CVE-2023-49105 tient à ce que cette vérification est conditionnelle : si aucune clé de signature n’est configurée — ce qui est le défaut d’installation — le serveur accepte quand même les URL pré-signées, sans rien valider. La porte reste donc ouverte alors que le verrou n’a jamais été posé. C’est un cas d’école de configuration dangereuse par défaut : le correctif ne se contente pas d’ajouter une vérification, il fait refuser l’URL pré-signée quand la clé manque.

Cette mécanique explique aussi pourquoi l’exploitation est si discrète. L’attaquant n’a rien à casser : il utilise la fonctionnalité comme prévu, à la différence près que personne n’a fermé la condition. Les journaux ne montrent rien d’anormal — des accès WebDAV légitimes, vers des fichiers légitimes, simplement initiés par quelqu’un d’autre. C’est ce qui rend la détection rétrospective difficile et l’enquête indispensable.

Le contexte de la divulgation initiale mérite d’être rappelé : CVE-2023-49105 a été révélée en novembre 2023 par ownCloud, en même temps qu’une autre faille critique — CVE-2023-49103 — dans l’application graphapi. La vague de correctifs d’alors a concerné des dizaines de milliers d’instances auto-hébergées. Près de trois ans plus tard, son inscription au KEV dit simplement que tout le monde n’a pas suivi.

Pourquoi une faille de 2023 redevient un problème en 2026

La réinscription au KEV trois ans plus tard raconte une mécanique bien connue, et pourtant rarement intégrée à la gestion des correctifs : la dette de patch ne disparaît pas, elle s’accumule jusqu’à devenir un marché.

Une faille critique corrigée par l’éditeur ne disparaît pas du paysage le jour où le correctif sort. Elle disparaît de l’attention. Les équipes qui ont manqué la mise à jour initiale — faute de temps, d’inventaire, ou parce que l’instance n’était pas jugée « sensible » — la laissent en place. Trois ans plus tard, les scanners d’attaquants, eux, la connaissent par cœur et l’enchaînent automatiquement.

Le cas ownCloud est aggravé par un facteur d’usage : ce logiciel est typiquement auto-hébergé par des structures qui n’ont pas d’équipe sécurité dédiée — associations, petites collectivités, PME, laboratoires. L’instance est souvent exposée sur Internet pour permettre le partage de fichiers avec l’extérieur, ce qui est précisément le scénario d’exposition maximal pour cette faille. À cela s’ajoute une réalité opérationnelle simple : ces serveurs sont souvent installés une fois, puis laissés à tourner, sans canal de mise à jour centralisé ni responsable identifié du patching.

La CISA a marqué cette entrée « forensic triage : oui ». Traduit en opérationnel : les instances non corrigées et exposées doivent être traitées comme des compromissions probables, pas comme des machines à patcher tranquillement.

Ce qu’il faut faire

La réponse combine un inventaire, une mise à niveau et une enquête.

• Recenser les instances. Identifier chaque ownCloud Server 10.x auto-hébergé, en priorité celles qui sont joignables depuis Internet. Vérifier la version via l’interface d’administration ou la commande occ status.
• Mettre à niveau sans délai. Passer à 10.13.1 au minimum, idéalement à la branche courante 10.13.3. Le correctif fait refuser les URL pré-signées lorsqu’aucune clé de signature n’est configurée.
• Configurer une clé de signature. Au-delà du correctif, définir une clé de signature pour le WebDAV referme la faille de conception sous-jacente — ne pas s’arrêter à la simple montée de version.
• Enquêter. Chercher les téléchargements ou suppressions de fichiers inattendus, les nouveaux partages, les accès WebDAV depuis des IP inconnues et les modifications de clés de signature. Toute instance non corrigée qui tournait avant le correctif est un candidat à la compromission.

# Confirmer la version d'une instance ownCloud (depuis le répertoire d'installation)
sudo -u www-data php occ status

# Rechercher des accès WebDAV dans les journaux (exemple générique)
grep -i "webdav" /var/log/owncloud/owncloud.log | tail -50

# Vérifier la présence d'une clé de signature WebDAV dans la configuration
sudo -u www-data php occ config:app:get webdav signing-key

Verdict

Si vous exploitez une instance ownCloud 10.x exposée, la mise à niveau vers 10.13.1 ou plus est une urgence du jour, pas une tâche de maintenance : la faille est non authentifiée, critique, et désormais activement exploitée. L’enquête d’éventuelle compromission fait partie du même geste, car la CISA la rend obligatoire pour le périmètre fédéral.

Si vous gérez un parc de services auto-hébergés, la leçon dépasse ownCloud : une faille critique corrigée par l’éditeur est un créneau de tir tant que votre inventaire ne l’a pas éliminée. La réinscription au KEV est un rappel que l’âge d’une CVE ne la rend pas inoffensive — il la rend au contraire plus exploitable, parce que les attaquants ont eu le temps de l’industrialiser.

Références

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