CVE-2026-91202: Cockpit-files: cockpit-files: arbitrary file ownership change via symlink following in privileged paste

AIONLYREPORT package: cockpit-files-36-1.el10 ------ Summary: Recursive Ownership Change in Paste Follows Symlinks: the privileged Paste as owner flow can recursively change ownership of symlink referents outside the pasted tree when a copied directory contains symlinks. Requirements to exploit: A low-privileged local user must be able to prepare a directory tree containing a symlink, and another user must use the cockpit-files privileged paste flow with superuser mode available, choose Paste as owner, and select a non-original owner. Component affected: cockpit-files-36-1.el10, src/dialogs/copyPasteOwnership.tsx, pasteAsOwner() privileged paste flow Version affected: cockpit-files-36-1.el10 Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:H/A:L - 6.3 (MEDIUM) AV:L - The attacker needs local access to prepare the copied directory tree and reach the file-management workflow. AC:L - The behavior follows directly from copying a directory containing a symlink and triggering the privileged ownership-change path. PR:L - Basic local user privileges are needed to create the crafted source tree. UI:R - A user must confirm the Paste as owner dialog and choose a non-original owner. S:U - The impact is limited to the same host and security authority. C:L - Confidentiality can be reduced if the changed ownership grants read access to the symlink referent. I:H - Ownership of files outside the pasted tree can be modified unexpectedly, which is a direct integrity violation and can enable follow-on abuse. A:L - Changing ownership of sensitive files can disrupt access or require recovery, but broad denial of service is not established from the available evidence. Impact: Moderate. Based on Red Hat's severity guidance, this issue can compromise integrity and, in some cases, confidentiality of local resources, but it requires local access, a crafted symlink tree, a privileged paste workflow, and user interaction in the ownership dialog. Those preconditions make it materially less straightforward to exploit than a typical Important issue. Embargo: no Reason: The issue is local and user-assisted, with reachable mitigations available before a fix is shipped. The available evidence supports prompt remediation, but it does not indicate a wormable, unauthenticated, or default-remote compromise scenario. Acknowledgement: Aisle Research Vulnerability Details: In the privileged paste flow, pasteAsOwner() first performs a privileged archive copy and then, when the selected owner is not original, performs a privileged recursive ownership change on the pasted paths: tsx await cockpit.spawn([ "cp", "--archive", ...clipboard.files.map(file => clipboard.path + "/" + file.name), dstPath ], { superuser: "require" }); if (ownerStr !== "original") { await cockpit.spawn([ "chown", "--recursive", ownerStr, ...clipboard.files.map(file => dstPath + "/" + file.name), ], { superuser: "require" }); } On GNU chown, dereferencing symlinks is the default behavior unless --no-dereference is supplied. As a result, if a pasted directory contains a symlink, the recursive chown may affect the symlink referent rather than only objects within the copied tree. Because this code runs with superuser: "require", the resulting ownership change can reach files outside the pasted directory. The available evidence establishes unintended ownership changes outside the pasted tree. Any follow-on privilege escalation depends on the selected owner and the targeted referent, so that effect should be treated as conditional rather than guaranteed. Steps to reproduce: 1. As an unprivileged user, prepare a source tree containing a symlink to a sensitive file: bash mkdir -p /tmp/src/evil ln -s /etc/shadow /tmp/src/evil/linktoshadow stat -c '%U:%G %n' /etc/shadow 2. In the UI, navigate to /tmp/src and copy evil. 3. Navigate to a destination where unprivileged paste fails but superuser mode is available. 4. Paste, then in Paste as owner choose any non-original owner and confirm. 5. Verify whether the referent ownership changed: bash stat -c '%U:%G %n' /etc/shadow 6. Expected behavior: only files within the pasted tree should have their ownership changed. 7. Observed behavior: the symlink referent may have its ownership changed. Mitigation: Until a fix is available, avoid using Paste as owner on copied trees that may contain symlinks. If privileged paste is required, keep the owner selection at original, which avoids the recursive chown path described above. Proposed Fix: Add --no-dereference to the privileged recursive chown invocation so ownership changes apply to symlink objects rather than their referents. diff diff --git a/src/dialogs/copyPasteOwnership.tsx b/src/dialogs/copyPasteOwnership.tsx @@ if (ownerStr !== "original") { await cockpit.spawn([ "chown", "--recursive", + "--no-dereference", ownerStr, ...clipboard.files.map(file => dstPath + "/" + file.name), ], { superuser: "require" }); } ------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat