CVE-2026-91205: Cockpit-files: cockpit-files: local attacker can hijack file ownership via symlink race

AIONLYREPORT package: cockpit-files-36-1.el10 ------ Summary: Symlink Hijacking in chown during directory creation: a local attacker who controls a writable parent directory can race privileged mkdir and chown operations and redirect the ownership change to a symlink target. Requirements to exploit: A local unprivileged attacker must control the parent directory of the path being created, that directory must be writable in a way that allows entry replacement, a user must perform the directory creation through Cockpit Files with owner assignment enabled, and the attacker must win the race between mkdir and chown. Component affected: cockpit-files-36-1.el10, src/dialogs/mkdir.tsx, createdirectory() 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:H/PR:L/UI:R/S:U/C:H/I:H/A:N - 6.0 (MEDIUM) AV:L - The attacker needs local access to a system where Cockpit Files is used. AC:H - Exploitation depends on winning a narrow pathname race and on an attacker-controlled writable parent directory. PR:L - The attacker needs only a low-privileged local account to prepare the directory and run the race. UI:R - A user must trigger the vulnerable directory creation flow. S:U - The impact remains within the same security scope. C:H - A successful attack can redirect ownership changes onto sensitive files and expose their contents. I:H - A successful attack can grant write control over files whose ownership should not be attacker-controlled. A:N - The demonstrated impact is confidentiality and integrity compromise rather than a direct denial of service. Impact: Moderate. The flaw can compromise confidentiality and integrity, but exploitation is materially constrained by local access, required user interaction, a race condition, and a specific writable-parent-directory setup. That aligns more closely with Red Hat's Moderate category than Important. Embargo: no Reason: The issue is local, requires a privileged user action and favorable filesystem conditions, and has straightforward operational mitigations, so delayed public disclosure is not strongly justified on the available evidence. Acknowledgement: Aisle Research Vulnerability Details: In the privileged owner-assignment path, directory creation and ownership change are performed as two separate operations on the same pathname: ts async function createdirectory(path: string, owner?: string) { if (owner !== undefined) { const opts = { err: "message", superuser: "require" } as const; await cockpit.spawn(["mkdir", path], opts); await cockpit.spawn(["chown", owner, path], opts); } else { await cockpit.spawn(["mkdir", path], { err: "message" }); } } If an attacker can modify the parent directory contents between these two calls, the newly created directory entry can be replaced with a symlink before chown runs. In that situation, the ownership change may be applied to the symlink target rather than the directory that Cockpit Files intended to create. The risk is limited to scenarios where the attacker can control the parent directory and where the superuser-assisted owner-setting path is actually used. Steps to reproduce: 1. Prepare two users: an unprivileged local attacker account and a user who will operate Cockpit Files with superuser access. 2. Create an attacker-controlled parent directory, for example: sudo mkdir -p /home/attacker/share sudo chown attacker:attacker /home/attacker/share sudo chmod 0777 /home/attacker/share 3. As the attacker, run a loop that continually replaces the target name with a symlink: while true; do rm -rf /home/attacker/share/poc; ln -s /etc/shadow /home/attacker/share/poc 2>/dev/null; done 4. In Cockpit Files, browse to /home/attacker/share/, choose to create directory poc, and use the owner-setting flow that triggers the privileged chown path. 5. If the race is won, verify whether the ownership of /etc/shadow changed unexpectedly: ls -l /etc/shadow Mitigation: Avoid using the privileged owner-setting directory creation flow inside attacker-writable directories. Restrict write access on shared parent directories, use sticky-bit protections where appropriate, and prefer symlink-safe ownership changes that do not dereference attacker-controlled path replacements. Proposed Fix: Add --no-dereference to the privileged chown invocation so that ownership changes do not follow a substituted symlink. diff diff --git a/src/dialogs/mkdir.tsx b/src/dialogs/mkdir.tsx @@ -42,7 +42,7 @@ async function createdirectory(path: string, owner?: string) { if (owner !== undefined) { const opts = { err: "message", superuser: "require" } as const; await cockpit.spawn(["mkdir", path], opts); await cockpit.spawn(["chown", owner, path], opts); + await cockpit.spawn(["chown", "--no-dereference", owner, path], opts); } else { await cockpit.spawn(["mkdir", path], { err: "message" }); }

------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat