commit 37e4117f48bdef0fa1ba27f6467d7a891b0b55ba Author: Nick Craig-Wood Date: Fri Jun 5 16:20:23 2026 +0100 Version v1.74.3 commit 9222ed2c5a7678de7fa620214b0858311c707a29 Author: Nick Craig-Wood Date: Wed May 27 10:28:06 2026 +0100 rc: stop global.* connection string options changing config CVE-2026-49980 A connection string can carry global.* options which change rclone's process-wide configuration (e.g. global.http_proxy). This is undesirable for the rc interface which was designed to have multiple users or connections at once. The rc interface has the `_config` mechanism for setting request scoped global config. This blocks global.* options on all rc paths by marking the context as a remote control request at the rc boundaries. fs.NewFs then skips applying global.* to the process-wide config for a marked context. The marker is reapplied in fs.CopyConfig, which is the call rclone uses to detach context but keep config. global.* options still apply to the individual backend they are set on, exactly like override.* options; they just no longer leak into the rest of the process. Remotes created directly on the command line are unaffected as are remotes defined in the config file. See: GHSA-qw24-gh76-8rvv (cherry picked from commit 53f972830c1747cb9636a6342c5308e55672c375) commit 48da1774f4999d1d46543308b9a7fe75585dbfc4 Author: Nick Craig-Wood Date: Wed May 27 10:04:10 2026 +0100 rc: fix unauthenticated command execution via --rc-serve inline remotes CVE-2026-49980 The --rc-serve GET/HEAD file serving path accepted bracketed inline remotes from the URL and instantiated them, so a single unauthenticated request could run a command as the rclone user via backend options such as webdav bearer_token_command or sftp ssh, read arbitrary local files, or change process-wide config via global.* options. This was the GET/HEAD equivalent of the POST hole fixed for CVE-2026-41179, which only guarded the rc call dispatch path. Now, unless the rc server has authentication configured or --rc-no-auth is set, the serve path only allows remotes already present in the config file: inline remotes, connection string parameters and bare local paths are rejected. Connection string global.* options are never honoured on the serve path, even when authenticated. See: GHSA-qw24-gh76-8rvv (cherry picked from commit 2326ea79f7dd93de1f7ba15f02353d40995f06a8) commit 2a7b0d0d3b6decabdc8a5e4d4d977ae36b619dcc Author: Nick Craig-Wood Date: Wed Jun 3 12:40:28 2026 +0100 build: fix multiple CVEs by upgrading to go1.26.4 - CVE-2026-42504: mime: quadratic complexity in WordDecoder.DecodeHeader - CVE-2026-42507: net/textproto: arbitrary input are included in errors without any escaping - CVE-2026-27145: crypto/x509: split candidate hostname only once commit fc4349dc16c0240cad0a311388c416db9b03c39c Author: Nick Craig-Wood Date: Sun May 31 09:39:59 2026 +0100 iclouddrive: fix "Index has invalid data" error listing iCloud Photos Accounts with shared-album zones (named CMM-*) returned these zones in the photos changes/database listing alongside the real photo libraries. rclone treated them as libraries and queried their albums, but these zones have no CPLAlbumByPositionLive index so the query failed with BAD_REQUEST / "Index has invalid data", aborting the whole listing. Only PrimarySync and SharedSync-* zones are photo libraries, so skip any other zone during discovery. See: https://forum.rclone.org/t/sync-to-icloud-gives-index-has-invalid-data-errors/53852 commit dff3a0731ea03e51031cebc0d2269f1352dd66dc Author: Nick Craig-Wood Date: Sun May 31 10:30:24 2026 +0100 build: cache Go build and module dirs to speed up CI The build matrix relied on setup-go's built-in cache, which keys only on go.sum with no job differentiation. All matrix jobs computed the same cache key and raced to save it; since cache keys are immutable, only the first job to finish saved its cache. That winner was usually a fast job whose build cache contained none of the cross-compiled architectures, so the compile_all and ci_beta steps started from a cold cache on every run. Disable setup-go's cache and add two explicit actions/cache steps to the build matrix, the android job and the lint job: - the module cache (~/go/pkg/mod) depends only on go.sum, so it is shared across all jobs under a single key; it used to be duplicated in every job's cache. The downloaded module .zip archives are pruned before saving as they are not needed to build from the extracted module cache, roughly halving it to ~260 MiB per OS; - the build cache (compiled artifacts) is specific to OS, arch and Go version, so it is kept per job, keyed on the job name. This lets the cross-compile steps reuse per-architecture build artifacts and keeps the total cache within the repository limit. Measured on CI, comparing a cold-cache run against the following warm-cache run: other_os 23m12s -> 3m35s (compile_all 14m -> 21s) linux 23m13s -> 12m14s (deploy 11m -> 1m37s, race test 8m -> 4m45s) Both jobs now finish well under 15 minutes once the cache is warm. commit 5f5e2ef9cfc62e96fded5c514e45ec4725ab6c84 Author: Nick Craig-Wood Date: Mon Jun 1 15:48:48 2026 +0100 log: fix wrong source file:line in JSON logs from release builds JSON logs reported "source":"slog/logger.go:256" instead of the real caller. getCaller skips logging-machinery frames by file path, but release builds use -trimpath which rewrites the standard library slog frame's path to "log/slog/logger.go" - matching neither the "/log/" nor the "log.go" check, so it was reported as the source. Also skip frames whose function belongs to the log/slog package, which is immune to -trimpath. commit d4397faa94cdebb74c9911cc29798c1bd58ff7f6 Author: Janne Beate Bakeng <436265+jbbakeng@users.noreply.github.com> Date: Mon Jun 1 13:06:03 2026 +0200 mount2: fix empty directory listings on re-read With cmd/mount2, reading a directory more than once returned the correct entries on the first read but nothing on subsequent reads. Plain `ls` triggers this: it does lseek(fd, 0, SEEK_SET) to rewind the directory before a second getdents. go-fuse v2.9.0 rewinds a directory stream by calling Seekdir on the FileSeekdirer interface. dirStream did not implement it, so go-fuse returned ENOTSUP and produced an empty listing on every read after the first. This implements Seekdir on dirStream: a rewind to offset 0 resets the stream to the start, restoring correct listings on re-read. Non-zero offsets are uncommon for in-memory listings and still return ENOTSUP, matching go-fuse's own default. A compile-time interface assertion is added so signature drift on future go-fuse updates is caught at build time. Before: second and subsequent reads of a directory returned no entries. After: directories list correctly on every read. See: https://github.com/hanwen/go-fuse/issues/549 Co-authored-by: Nick Craig-Wood commit 7324ee850a2e736e1022596d136e474cabfb03b5 Author: Yakov Till Date: Thu May 21 21:48:47 2026 +0200 iclouddrive: fix ADP/PCS cookie acquisition for iCloud Drive commit 3c54a37488a5a35a8d5f9adddfd6af4afd8357fc Author: Nick Craig-Wood Date: Fri May 29 17:13:39 2026 +0100 drive: fix server-side move failing on shared drives with duplicate dirs - fixes #9472 When moving a file rclone removed the file from its old parent by looking the parent ID up from the path using the directory cache. When the source contained two directories with the same name and path, the cache could resolve to the wrong duplicate, so the removeParents request didn't match the file's real parent. This left the file with both its old and new parent, which fails on shared drives with: A shared drive item must have exactly one parent., teamDrivesParentLimit This uses the source object's actual parent ID instead when it is known, falling back to the path lookup only when the object has zero or multiple parents. commit a2f8b493ed9fc97ec7d202d11f26f53a31d45d99 Author: Leon Brocard Date: Fri Mar 20 17:12:55 2026 +0000 local: fix getXattr returning empty map instead of nil At least on my macOS Sequoia 15.7.4, the system automatically adds a com.apple.provenance xattr to files created by processes. This xattr lacks the "user." prefix so getXattr filters it out, but the metadata map was already allocated, resulting in an empty non-nil map being returned instead of nil. This caused TestMetadata/Symlink/Xattr and TestMetadata/File/Xattr to fail because they assert the return value is nil when no user xattrs are present. The fix checks if the metadata map is empty after filtering and returns nil if so. commit 641702fc7fd3a853ded4228e2f5f657867eaa938 Author: Nick Craig-Wood Date: Thu May 28 00:28:21 2026 +0100 serve s3: fix multipart ListParts pagination returning wrong part numbers - fixes #9460 Listing the parts of a multipart upload with a MaxParts smaller than the number of parts returned wrong PartNumber values and duplicate parts on pages after the first, and the part number marker regressed instead of advancing, causing clients to loop forever. This bumps github.com/rclone/gofakes3 to v0.0.6 pick up the fix. commit f25d9e2bf30d75de5820afade026f236adc6061a Author: Nick Craig-Wood Date: Thu May 28 15:45:40 2026 +0100 drime: fix directory rename leaving the renamed folder empty in VFS Drime's folder rename returns success immediately but the children listing of the renamed folder briefly returns empty before settling, which made VFS see an empty directory right after a successful rename and broke subsequent operations on its contents. After a successful DirMove, poll the renamed folder's listing until it shows the pre-rename child count, with a 30s timeout and exponential backoff. The backend integration test already tolerated this via its own list-consistency retries; this brings VFS into line. Fixes #9450 commit ec28206d8a584d20693b4aee73ef515d6f7eb261 Author: Nick Craig-Wood Date: Tue May 26 11:02:40 2026 +0100 drime: remove duplicate upload_cutoff config option The upload_cutoff option was registered twice with identical content. Remove the second copy. commit ddbc886395ea52386bb6aef7dfbe6262346ecde4 Author: Nick Craig-Wood Date: Tue May 26 10:26:24 2026 +0100 drime: fix files being uploaded to the wrong directory Large files (sent as multipart uploads) were placed in the wrong folder for two reasons: - the parent folder was sent as "parent_id", but the API ignores that and expects "parentId", so the parent was never honoured - relativePath was sent as the full path from the drive root, which made the server build folders from it and silently drop any "0" path segment (e.g. ".../data/0/file" lost the "0") Send the parent as "parentId" and use just the leaf as relativePath, matching the working single-part upload. This also lets us remove the now-unneeded absolute-path resolution code. Fixes #9392 Co-authored-by: Brian King commit c8ceb209fccf917ceaea44e846bfe7870067a1ed Author: Nick Craig-Wood Date: Tue May 26 09:46:22 2026 +0100 drime: fix server-side copy and move failing with Cloudflare 520 error The drime origin returns a malformed response (reported by Cloudflare as a 520 error) for a literal PUT request to the file-entries update endpoint, which broke renaming, and so server-side copy and move. Use a POST with the X-HTTP-Method-Override: PUT header instead - the API routes this to the same handler and it works reliably. Also retry Cloudflare 520-524 errors which may occur transiently. commit 5b4eb0eefb0573b65d5ee8f7afb397c4b6c5f8d8 Author: Nick Craig-Wood Date: Sun May 24 14:34:59 2026 +0100 serve sftp: fix truncate request being silently ignored The SFTP serve handler ignored the size attribute of SETSTAT/FSETSTAT requests, only acting on the modification time. This meant a client asking to truncate a file (eg setting the final size of an upload, or an explicit truncate) had no effect at all. This respects the size attribute (if present) by truncating the file to the requested size. commit 223e473e6efd47bc6868dfa3c0335fad80ed250b Author: Nick Craig-Wood Date: Sun May 24 13:33:21 2026 +0100 serve sftp: fix file corruption when a client resumes an upload The SFTP serve write handler always opened files with O_TRUNC, ignoring the flags requested in the SFTP OPEN packet. Some clients (notably WinSCP's "Process in Background", which resumes an upload on a second connection) re-open the partially written file without the truncate flag and continue writing from the offset they had reached, relying on the existing data being preserved. Forcing O_TRUNC zeroed that prefix, so the start of the uploaded file ended up as a block of zero bytes. This fix respects the requested open flags instead so a resume open without truncate keeps the already written data intact. See: https://forum.rclone.org/t/rclone-serve-sftp-winscp-background-mode-uploading-causes-file-corruption/53841 commit bac27547d5b48d8acd2028018adba51444facd62 Author: Nick Craig-Wood Date: Sat May 23 11:32:11 2026 +0100 Start v1.74.3-DEV development