Source: rclone Version: 1.69.3+dfsg-3 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for rclone. CVE-2026-71309[0]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. From 1.40.0 until | 1.75.0, rclone serve restic does not correctly reject URL paths | beginning with ../ in cmd/serve/restic/restic.go WithRemote, which | accepts a leading parent path and passes it to GET, HEAD, POST, and | DELETE handlers for configured backends including WebDAV, FTP, HTTP, | Memory, and SFTP. An attacker who can access the REST endpoint may | read, create, overwrite, or delete objects outside the path | configured by the operator when the operator publishes a backend | subdirectory and the backend credential can access parent or sibling | objects. This issue is fixed in 1.75.0. CVE-2026-71310[1]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. Prior to 1.75.0, the | shared HTTP CONNECT helper in lib/proxy/http.go parses proxy CONNECT | responses with http.ReadResponse over an unrestricted buffered | reader, allowing a malicious or compromised configured proxy, or an | active on-path actor controlling a plaintext HTTP proxy hop, to send | oversized headers that grow memory until the rclone process fails. | The affected helper is used by FTP and SFTP proxy connections, and | SFTP reaches the parser before SSH server authentication, so target | host key validation does not constrain a malicious proxy. This issue | is fixed in 1.75.0. CVE-2026-71311[2]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. Prior to 1.75.0, a valid | but nondefault FTP filename encoding in backend/ftp/ftp.go can | restore raw CR/LF immediately before an attacker-controlled path is | interpolated into the line-oriented FTP control channel, and | github.com/jlaffaye/ftp formats the argument through | textproto.Conn.Cmd without rejecting CR or LF, allowing a filename | such as victim CRLF DELE other-secret CRLF NOOP to inject an | independent authenticated FTP command when the victim copies or | syncs to a more-privileged FTP destination. This issue is fixed in | 1.75.0. CVE-2026-71312[3]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. Prior to v1.75.0, rclone | interpolates remote SFTP paths into PowerShell hash commands in | backend/sftp/sftp.go, and quoteOrEscapeShellPath escapes only ASCII | apostrophe even though PowerShell treats U+2018, U+2019, U+201A, and | U+201B as single-quote delimiters, allowing an attacker-controlled | filename to terminate the intended path literal and append | PowerShell statements that execute as the victim SSH account when | server-side hashing is invoked. This issue is fixed in v1.75.0. CVE-2026-71313[4]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. From v1.51.0 until | v1.75.0, the local backend in backend/local/local.go relies on the | configurable filename encoder to prevent remote filename data from | becoming operating-system path syntax, so a local destination using | Slash, None, Raw, or on Windows an encoding that preserves backslash | can decode a standard-encoded fullwidth dot-dot component or native | backslash form into an actual parent-directory component before | filepath.Join resolves it outside the configured local root, | allowing an attacker-controlled source object to create or overwrite | files outside the selected destination directory as the rclone | process. This issue is fixed in v1.75.0. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-71309 https://www.cve.org/CVERecord?id=CVE-2026-71309 [1] https://security-tracker.debian.org/tracker/CVE-2026-71310 https://www.cve.org/CVERecord?id=CVE-2026-71310 [2] https://security-tracker.debian.org/tracker/CVE-2026-71311 https://www.cve.org/CVERecord?id=CVE-2026-71311 [3] https://security-tracker.debian.org/tracker/CVE-2026-71312 https://www.cve.org/CVERecord?id=CVE-2026-71312 [4] https://security-tracker.debian.org/tracker/CVE-2026-71313 https://www.cve.org/CVERecord?id=CVE-2026-71313 Regards, Salvatore
