CVE-2025-24889: SecureDrop Client Path Traversal Flaw

CVE-2025-24889 Overview

CVE-2025-24889 is a path traversal vulnerability [CWE-22] in the SecureDrop Client, a desktop application that journalists use to communicate with sources on the SecureDrop Workstation. The flaw resides in the sd-log virtual machine, which centrally collects logs from other Qubes-isolated VMs. The log ingestion logic trusts a VM name supplied by the sending VM rather than reading it from the Qubes QREXEC_REMOTE_DOMAIN environment variable. An attacker with code execution in any log-enabled VM can abuse this to write attacker-controlled content to arbitrary directories inside sd-log, enabling lateral movement to that VM. Versions 0.14.1 and 1.0.1 contain the fix.

Critical Impact
An attacker who already controls one SecureDrop Workstation VM can achieve code execution inside the isolated sd-log VM by sending a crafted log entry that writes a syslog.log file into /home/user/.config/autostart/, which XFCE executes at login.

Affected Products

SecureDrop Client prior to version 0.14.1
SecureDrop Client 1.x prior to version 1.0.1
SecureDrop Workstation deployments using the vulnerable sd-rsyslog component

Discovery Timeline

2025-02-13 - CVE-2025-24889 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-24889

Vulnerability Analysis

The SecureDrop Workstation runs on Qubes OS and uses strong VM isolation. Logs from all workstation VMs are forwarded to the dedicated sd-log VM over the Xen vchan protocol via Qubes qrexec. A narrow Qubes RPC policy permits only this specific inter-VM communication path.

The sd-rsyslog client reads the local VM name from its own configuration file (/etc/sd-rsyslog.conf) and sends it alongside each log message. The sd-log server then uses this name as part of the destination file path without sanitization. Because the sending VM controls the name, it can embed path traversal sequences and overwrite logs belonging to other VMs or create files in unrelated directories.

Successful exploitation does not break Qubes isolation beyond the log-ingestion channel. Movement is limited to the sd-log VM, which is itself isolated from the internet.

Root Cause

The root cause is improper input validation of a security-sensitive identifier. The sending VM supplies its own name through the log stream, and sd-log concatenates it into the destination path. A trusted source for the remote VM name — the Qubes QREXEC_REMOTE_DOMAIN environment variable — was available but unused. The fix removes client-supplied naming and relies on Qubes-provided identity instead.

Attack Vector

An attacker who has already compromised any log-forwarding VM on the SecureDrop Workstation can inject a crafted VM name through the securedrop.Log qrexec service. By setting the name to a traversal sequence targeting /home/user/.config/autostart/, the attacker causes sd-log to write a syslog.log file with attacker-controlled contents to that directory. XFCE parses any file in the autostart directory as a .desktop entry regardless of extension, resulting in code execution as the user account on the next session start.

text

     config = configparser.ConfigParser()
     config.read('/etc/sd-rsyslog.conf')
     logvmname = config['sd-rsyslog']['remotevm']
-    localvmname = config['sd-rsyslog'].get('localvm', None)
-
-    # If no localvm name is specified, it must be supplied by Qubes OS. If this
-    # fails, we exit, to avoid falsely identified logs.
-    if localvmname is None:
-        try:
-            get_vm_name_process = Popen(["/usr/bin/qubesdb-read", "/name"],
-                                        stdout=PIPE, stderr=PIPE)
-            vm_name_output, vm_name_error = get_vm_name_process.communicate()
-            ...
-            localvmname = vm_name_output.decode("utf-8").strip()
-        except FileNotFoundError:  # not on Qubes?
-            ...
-            sys.exit(1)

     process = Popen(
             ["/usr/lib/qubes/qrexec-client-vm", logvmname, "securedrop.Log"],
             stdin=PIPE,
             stdout=PIPE,
             stderr=PIPE,
     )
-    process.stdin.write(localvmname.encode("utf-8"))

Source: GitHub Commit 3012bf7 — the patch stops the client from transmitting the source VM name, forcing the server to derive it from the trusted Qubes QREXEC_REMOTE_DOMAIN variable.

Detection Methods for CVE-2025-24889

Indicators of Compromise

Unexpected files named syslog.log outside the standard log directory inside the sd-log VM, particularly under /home/user/.config/autostart/.
Log files for a given VM containing entries whose source name does not match any legitimate workstation VM.
Unexpected XFCE autostart entries or new processes spawned at sd-log user session start.

Detection Strategies

Audit the sd-log filesystem for files written by the rsyslog receiver outside its expected log directory tree.
Compare the SecureDrop Client version in use against the fixed releases 0.14.1 and 1.0.1.
Review qrexec policy logs on the Qubes dom0 for anomalous call patterns to the securedrop.Log service from unexpected VMs.

Monitoring Recommendations

Monitor file creation events in sd-log directories outside /var/log and alert on writes to user autostart or configuration paths.
Track process execution within the sd-log VM; the VM should run a tightly bounded set of binaries, so new executions warrant investigation.
Enable centralized collection of Qubes qrexec policy decisions to correlate inter-VM activity with host-level anomalies.

How to Mitigate CVE-2025-24889

Immediate Actions Required

Upgrade the SecureDrop Client to version 0.14.1 or 1.0.1 on all SecureDrop Workstation instances.
Inspect the sd-log VM for unauthorized files written outside the intended log directory, especially under /home/user/.config/autostart/.
Review access to all log-forwarding VMs and investigate any VM showing signs of prior compromise, since exploitation requires a pre-existing foothold.

Patch Information

The Freedom of the Press Foundation released fixes in SecureDrop Client 0.14.1 and 1.0.1. The patch removes the client-supplied source VM name and instead relies on the trusted QREXEC_REMOTE_DOMAIN value provided by Qubes OS. See the GitHub Security Advisory GHSA-933q-fx9h-5g46 and the upstream commit 3012bf7 for details.

Workarounds

No official workaround exists; apply the vendor patch as the primary remediation.
Harden any VM that forwards logs to sd-log to reduce the risk of an attacker gaining the initial foothold required to reach this bug.
Remove or audit contents of /home/user/.config/autostart/ inside the sd-log VM to eliminate persistence written before patching.

bash

# Verify the installed SecureDrop Client version and update via the SecureDrop
# Workstation's standard update mechanism in dom0.
qvm-run --pass-io sd-app 'dpkg -s securedrop-client | grep ^Version'

# From dom0, run the SecureDrop Workstation updater to pull the fixed release.
sdw-admin --apply