OpenBSD OpenSSH scp may retain setuid/setgid bits in root downloads

In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).

• OpenBSD OpenSSH: the normalized record marks versions less than 10.3 as affected, with a structured range beginning at 0; the default status outside the explicit affected range is recorded as unaffected.
• OpenSSH 10.3 and the 10.3p1 release package contain the upstream correction for this behavior.
• Fedora recorded separate fixes for Fedora 42, Fedora 43, and Fedora 44. These are Fedora package boundaries and should not be treated as universal upstream version boundaries.
• Red Hat recorded fixes for Red Hat Enterprise Linux 6 Extended Lifecycle Support extension, 7 Extended Lifecycle Support, 8, 9, and 10, as well as Red Hat OpenShift Container Platform 4.12 through 4.19. Red Hat packages may retain older upstream version numbers because fixes are backported, so the advisory and installed build for the specific product must be checked.
• The record and reviewed sources do not establish affected status for other vendors or product branches.

The flaw is in the scp client and is classified as CWE-281, improper preservation of permissions. When a root process downloads a file using the legacy scp protocol (-O) without the mode-preservation option (-p), scp does not clear the file's setuid and setgid bits. If the remote source supplies a file carrying those bits, the destination file can be installed with special permissions that were not expected by the operator. OpenSSH states that this behavior dates back to the original Berkeley rcp program. The public details do not identify the specific internal function or permission-handling call responsible.

The affected path is reached through a network file transfer, but it requires all of the following conditions:

• A root process or automation workflow performs an scp download.
• The transfer uses legacy mode through -O and does not use -p.
• The remote file carries setuid or setgid bits, or the remote source is untrusted.

The record does not establish whether an attacker can force a root client to perform the download, nor does it define what authentication is required at the remote server. The normalized record marks public exploit as false and does not provide a known-exploited status; no specific campaign, victim, or exploit is identified in the supplied evidence.

The direct technical outcome is that a downloaded file may be stored with setuid or setgid bits that the operator did not expect. If the file is later executed under the corresponding ownership and permission semantics, it may run with higher privileges than the caller, creating a possible privilege-escalation path. The consequences may affect system integrity and confidentiality, and could affect availability if privileged code makes disruptive changes. The flaw does not itself execute the file, and the available evidence does not confirm a completed compromise.

The operational risk is concentrated in administrative, deployment, and automation workflows that download files as root. A downloaded file may acquire special permission bits without the operator intending that result, undermining assumptions about the file's origin and execution privileges. If the file is later executed or consumed by another system component, it may run with more privilege than expected, creating potential for protected data access, unauthorized changes, or service disruption. The available evidence does not establish a breach, observed exploitation, or data loss.

1. Upgrade OpenSSH to release 10.3, or install the vendor package that contains the corresponding fix. For upstream OpenSSH, release 10.3p1 includes the correction for scp.
2. For Fedora, apply the recorded fixed package for the active branch: openssh-9.9p1-14.fc42, openssh-10.0p1-9.fc43, or openssh-10.2p1-8.fc44.
3. For Red Hat Enterprise Linux and Red Hat OpenShift Container Platform, apply the erratum that matches the product branch and verify that the installed openssh build includes the fix. Do not assess status only by comparing the upstream version string because Red Hat backports fixes into older package lines.
4. Until updating is possible, avoid -O legacy mode in root-run download workflows and use the default SFTP mode where compatible. This is a precaution derived from the affected conditions, not a confirmed replacement for the update.
5. Review files already downloaded through affected workflows and remove unintended setuid or setgid bits under the organization's change-control process. Red Hat does not list a mitigation that meets its criteria for broad deployability and stability as a substitute for updating.

Use the following checks:

• Inventory systems running the OpenSSH client and compare installed packages with the applicable operating system or vendor fix data.
• Review scripts, cron jobs, deployment tools, and automation that run scp as root, especially commands using -O without -p.
• Inspect metadata on files downloaded by those workflows for unintended setuid or setgid bits.
• If process or command-line telemetry is available, review root invocations of scp in legacy mode. This is precautionary monitoring, not a confirmed indicator of compromise.

The absence of matching log events does not prove safety because command-line visibility may be incomplete and the flaw requires a narrow combination of conditions.