CVE-2026-35385

What it actually does

OpenSSH scp before 10.3 can create downloaded files with setuid or setgid permission bits when scp is run as root using the legacy SCP protocol option (-O) and not using preserve mode (-p). This is a privilege-escalation condition driven by unsafe handling of file mode bits supplied by the remote side during a download. The vulnerability requires user interaction and a specific operational pattern: a privileged user or automation must invoke scp as root against a malicious or compromised SSH/SCP server using legacy protocol mode. If the downloaded file is executable and retains setuid/setgid bits, later execution can run with elevated privileges, potentially root or a privileged group.

Why it matters to the business

Organizations that use root-run scp jobs, administrative scripts, backup workflows, or break-glass file transfers with legacy SCP mode could unintentionally install attacker-controlled privileged executables. Successful exploitation can lead to full host compromise, unauthorized data access, tampering, persistence, and operational disruption. The risk is narrower than many remote code execution flaws because exploitation depends on a root user or root automation downloading from an attacker-controlled or compromised server with a specific scp option combination. EPSS is low and there is no known CISA KEV listing or public exploit maturity reported, but OpenSSH is widely deployed, so standard patching and hardening are still warranted.

How an attack unfolds

An attacker first needs to influence the source of an scp download, such as by operating a malicious SSH/SCP server, compromising a legitimate file distribution server, poisoning an administrative workflow, or convincing an administrator to fetch a file from an untrusted host. The victim must run vulnerable scp as root, explicitly select the legacy SCP protocol with -O, and omit -p. During the transfer, the malicious server presents a file with setuid or setgid mode bits. Vulnerable scp may install the downloaded file locally with those privileged bits intact, contrary to expectations when preserve mode was not requested. The attacker then needs the file to be executed by a local user or process, or to place it in a path where it will be invoked, resulting in execution with the elevated owner or group privileges assigned to the file.

How to fix it

Upgrade OpenSSH to version 10.3 or later when available from the operating system or software vendor. If vendor packages backport the fix without changing the upstream version string, rely on the vendor advisory and package changelog rather than only the OpenSSH banner. As interim mitigation, avoid using legacy scp protocol mode (-O), especially in root-run workflows; prefer SFTP-mode scp, sftp, or rsync over SSH where appropriate. Do not run scp as root unless strictly necessary. If privileged transfers are required, download to a quarantined staging directory as an unprivileged user, validate ownership and permissions, strip setuid/setgid bits with chmod ug-s, and only then move files into privileged locations. Review scripts, cron jobs, configuration management, and operational runbooks for scp -O usage and remove or constrain it.

How to confirm the fix worked

Confirm that installed OpenSSH packages contain the vendor fix for OpenSSH 10.3 or later, or a vendor-backported patch. Check client versions with commands such as ssh -V and package manager queries, then compare against the applicable vendor advisory. Search administrative scripts, scheduled tasks, CI/CD jobs, backup jobs, and operational documentation for invocations matching scp -O, especially commands run as root. Validate that scp downloads performed as root from a test server cannot create files with setuid or setgid bits unless explicitly intended and allowed by the fixed behavior. Scan sensitive directories and recent download locations for unexpected setuid or setgid files using find commands such as find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -ls, and investigate any unfamiliar binaries.

Typical attack path

1. Attacker prepares or compromises an SSH/SCP server that will serve a malicious executable file with setuid or setgid permission bits.
2. A privileged administrator, root shell, or root-run automation downloads the file using vulnerable scp before OpenSSH 10.3.
3. The scp command uses legacy SCP protocol mode with -O and does not include -p.
4. The malicious remote server supplies file metadata that includes setuid or setgid mode bits.
5. The vulnerable client writes the downloaded file locally while preserving those privileged bits.
6. The attacker waits for or induces execution of the downloaded file, or relies on the file being placed into a location used by an administrative workflow.
7. When executed, the file runs with elevated owner or group privileges, enabling local privilege escalation, persistence, data access, or further compromise.

How to detect it

To determine whether this was already exploited, focus on endpoint and administrative activity rather than network payloads, because exploitation depends on client-side file creation behavior over SSH. Review shell history, process accounting, EDR telemetry, sudo logs, auditd logs, and command-line logging for root-run scp commands using -O without -p. Correlate those executions with outbound SSH connections to untrusted, newly added, or unusual hosts. Examine file creation events shortly after those transfers for files with setuid or setgid bits, particularly in staging directories, temporary directories, administrative tool paths, and locations referenced by automation. On Linux, auditd records for chmod, chown, open/create, and execve can help identify suspicious privileged file creation and later execution. Investigate any newly created or modified setuid/setgid executable whose origin is a network transfer, whose owner is root unexpectedly, or whose hash is unknown. Also inspect SSH client known_hosts changes, administrative scripts, cron logs, and package/build pipelines for changes that introduced downloads from attacker-controlled infrastructure.

• scp -O
• scp -O
• /usr/bin/scp -O
• /bin/scp -O
• scp -O root@
• scp -O -r
• scp -r -O
• -perm -4000
• -perm -2000
• chmod u+s
• chmod g+s
• setuid
• setgid
• type=EXECVE
• comm="scp"
• exe="/usr/bin/scp"
• exe="/bin/scp"
• /tmp/
• /var/tmp/
• /usr/local/bin/
• /opt/

What your security team should do

• Patch OpenSSH clients to 10.3 or vendor-fixed packages across Linux, BSD, Unix, and appliance images where scp is available.
• Prioritize systems where administrators or automation run scp as root, especially with legacy protocol mode (-O).
• Inventory and remove scp -O usage from scripts, cron jobs, backup processes, build pipelines, and runbooks; migrate to safer transfer methods.
• Enforce least privilege for file transfer workflows so downloads occur as non-root users and are promoted only after validation.
• Add file integrity monitoring or scheduled hunts for newly created setuid/setgid files in administrative staging directories, /tmp, /var/tmp, /usr/local, /opt, and other transfer destinations.
• Restrict outbound SSH/SCP access from administrative systems to approved hosts to reduce exposure to malicious or compromised file sources.
• Educate administrators that root-run legacy scp downloads can create unexpectedly privileged files on vulnerable clients.
• Because this is not currently in KEV and EPSS is low, handle under normal vulnerability management timelines unless local workflows match the risky pattern, in which case expedite remediation.