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-88013[0]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. From 1.49.0 until | 1.75.1, the HTTP backend attaches headers configured through --http- | headers or headers= to requests in backend/http/http.go, while its | fshttp.NewClient client follows redirects without a backend-specific | http.Client.CheckRedirect policy. A configured remote that redirects | to another host can therefore cause custom secrets such as X-Api-Key | to be resent to that untrusted destination, and a same-host HTTPS- | to-HTTP redirect can expose Authorization or Cookie headers in | cleartext. Listing, stat, download, mount, and serve operations can | trigger the leak during normal use. This issue is fixed in version | 1.75.1. CVE-2026-88014[1]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. From 1.72.0 until | 1.75.1, the archive ZIP backend method (*Fs).readZip in | backend/archive/zip/zip.go accepts archive/zip.File.Name values from | an untrusted central directory and exposes cleaned entry names | without ensuring that they remain inside the archive namespace. | Entries such as ../../etc/cron.d/evil can survive path.Clean and | become Object.Remote() values that fs/sync and fs/operations use as | destination-relative paths, allowing rclone copy or sync to write | outside the selected destination on backends that do not | independently confine the path. The non-empty root check also used | strings.HasPrefix without a path boundary, so root foo could | incorrectly include sibling foobar entries. This issue is fixed in | version 1.75.1. CVE-2026-88015[2]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. Prior to 1.75.1, | backend/local with --links or links=true exposes symlink targets as | .rclonelink objects, and fs.RangeOption.Decode can pass an unchecked | positive Range start through Object.Open and openTranslatedLink. The | function slices the target string as linkdst[offset:], so a Range | start larger than the target length causes a deterministic slice- | bounds panic when lib/http/serve exposes the object through HTTP or | WebDAV. Go net/http normally recovers the panic per connection, | causing request-level denial of service rather than terminating the | entire process. This issue is fixed in version 1.75.1. CVE-2026-88016[3]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. Prior to 1.75.1, when | backend/local runs with --links, a source .rclonelink object can | plant a symlink in the destination and later directory metadata is | applied through that path. MkdirMetadata, writeMetadataToFile, and | setTimes operate when Directory.translatedLink=false, so os.Chown, | os.Chmod, os.Chtimes, and birth-time handling can bypass os.Root | confinement and follow the symlink. An attacker controlling source | contents can therefore apply selected ownership, permissions, | modification times, or birth times to a file or directory outside | the destination, with --metadata required for chmod and chown while | modification time is applied by the normal directory workflow. This | issue is fixed in version 1.75.1. CVE-2026-88017[4]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. From 1.64.0 until | 1.75.1, the FTP auth-proxy driver in cmd/serve/ftp/ftp.go stores one | obscured password per username in the server-wide userPass | map[string]string instead of binding the credential or VFS to the | authenticated session. If two accepted credentials use the same | username but resolve to different proxy backends, a later | CheckPasswd login overwrites userPass[user], and subsequent getVFS | operations on the first session are reauthorized with the later | password. The first session can then read, create, overwrite, | rename, or delete objects using the second credential’s backend | authority. Exploitation requires the later same-username login to | occur while the first session remains open. This issue is fixed in | version 1.75.1. CVE-2026-88018[5]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. Prior to 1.75.1, rclone | serve s3 configured with --auth-proxy but without --auth-key allows | authPairMiddleware to register any client-chosen accessKeyID with an | empty ws.s3Secret. gofakes3 then verifies the request’s SigV4 | signature against that same empty secret, while Server.auth passes | the access key identifier as both the user and authentication value | to the proxy without an independent per-identity secret. An | unauthenticated network attacker can therefore choose an arbitrary | access key, sign with an empty secret, and reach whatever backend | the auth-proxy script resolves for that identity. This issue is | fixed in version 1.75.1. CVE-2026-88044[6]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. From 1.70.0 until | 1.75.1, the serve/start RC interface accepts per-server | proxyOpt.AuthProxy settings, and the FTP and S3 constructors in | cmd/serve/ftp/ftp.go and cmd/serve/s3/server.go incorrectly check | the process-global proxy.Opt.AuthProxy value instead. When the | global value is empty, the request-local authentication proxy is | ignored: FTP falls back to the fixed filesystem with username | anonymous and any password, while S3 with AuthKey serves the fixed | RC fs rather than the backend selected by the proxy. The dedicated | command-line servers that configure the global option are not | affected. This issue is fixed in version 1.75.1. CVE-2026-88045[7]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. From 1.75.0 until | 1.75.1, the serve S3 streamed multipart path in | cmd/serve/s3/multipart.go passes attacker-controlled contentLength | to multipart.NewRW().Reserve before reading request-body bytes. | waitForTurn admits the current part and one oversized part when the | buffer is empty despite --multipart-streaming-buffer-limit, and | lib/pool allocates 1 MiB pages according to Content-Length or X-Amz- | Decoded-Content-Length. A network client can retain or multiply | these reservations without sending the declared body, exhausting | process or host memory or permanently blocking request handlers. | Anonymous S3 deployments require no credentials, while deployments | using auth_key require an accepted S3 key. This issue is fixed in | version 1.75.1. CVE-2026-88046[8]: | rclone is a command-line program to sync files and directories to | and from different cloud storage providers. Prior to 1.75.1, rclone | core does not reject parent-directory segments in source | Object.Remote() values before fs/list, fs/walk, fs/sync, and | fs/operations pass those values to destination backends. A flat- | keyspace source object store populated with native non-rclone | tooling can contain a raw .. key segment, and affected b2, swift, | qingstor, oracleobjectstorage, internetarchive, smb, storj, sftp, | webdav, ftp, filelu, shade, and sia destinations use path.Join(root, | remote) before EncodeDot can neutralize the segment. A copy or | upload can therefore escape the configured root into another bucket, | share, or path reachable by the victim credential, with sftp and smb | potentially reaching other filesystem or share locations under the | same login authority. This issue is fixed in version 1.75.1. 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-88013 https://www.cve.org/CVERecord?id=CVE-2026-88013 [1] https://security-tracker.debian.org/tracker/CVE-2026-88014 https://www.cve.org/CVERecord?id=CVE-2026-88014 [2] https://security-tracker.debian.org/tracker/CVE-2026-88015 https://www.cve.org/CVERecord?id=CVE-2026-88015 [3] https://security-tracker.debian.org/tracker/CVE-2026-88016 https://www.cve.org/CVERecord?id=CVE-2026-88016 [4] https://security-tracker.debian.org/tracker/CVE-2026-88017 https://www.cve.org/CVERecord?id=CVE-2026-88017 [5] https://security-tracker.debian.org/tracker/CVE-2026-88018 https://www.cve.org/CVERecord?id=CVE-2026-88018 [6] https://security-tracker.debian.org/tracker/CVE-2026-88044 https://www.cve.org/CVERecord?id=CVE-2026-88044 [7] https://security-tracker.debian.org/tracker/CVE-2026-88045 https://www.cve.org/CVERecord?id=CVE-2026-88045 [8] https://security-tracker.debian.org/tracker/CVE-2026-88046 https://www.cve.org/CVERecord?id=CVE-2026-88046 Regards, Salvatore
