Rollback and Reconciliation for rclone Backup Changes
CVE-2026-93986 affects rclone releases through 1.75.0 and is fixed in 1.75.1. The change confines names returned by server or third-party listings so they cannot escape the directory being listed. The vendor rates the issue Low with CVSS 3.1 score 3.1 and CWE-22, and the local backend already has a path-escape guard. A controlled patch can be straightforward, but backup teams still need a rollback and reconciliation plan because changing path handling can expose unusual names that were previously ignored or represented differently.
Before upgrading, capture the current state of each automation. Record the rclone version, command line, source remote, destination root, schedule, service identity, and last successful run. Store a manifest of the object names, sizes, and hashes that the job expected at that point. The manifest is the baseline for later reconciliation. Do not include credentials or full remote configuration files in the record.
After the upgrade, run a non-production synchronization with the same source and destination shape. Use a disposable root and a small sample from each backend. Confirm that ordinary files still arrive, then introduce a harmless name containing parent-directory components. The expected security result is a rejection or confinement that keeps the local tree inside the test root. The expected operational result is an error that the automation can classify without entering an endless retry loop.
The first post-patch production run should be observed rather than scheduled and forgotten. Compare the new destination tree with the pre-upgrade manifest. Account for expected changes such as new source objects, but investigate names that appear at a different depth, collide after normalization, or vanish from the destination without a documented reason. A path-escape rejection should preserve the source name and the version in use. If the job treats it as a transient transport fault, fix that classification before running the next cycle.
A rollback may be appropriate when the fixed binary introduces an unexpected compatibility problem with an approved name. Rollbacks should not restore the vulnerable behavior as a long-term state. Isolate the affected source, capture the rejected entry, and reproduce the issue with the previous binary only in a disposable environment. If the older version is needed temporarily to retrieve data, keep the destination restricted and do not allow the job to promote files automatically. Record the exception, owner, expiry, and compensating controls.
Reconciliation should happen after either a successful patch or a rollback. Compare three views: the source listing, the local destination tree, and the frozen manifest from the last known good run. Resolve differences by object identity and content hash where possible. A same-size file with the same name is not enough evidence of equivalence. If a name was normalized, store both the original name and the local representation. If two source names map to one local path, stop and require a policy decision rather than silently overwriting one object.
Failed runs need their own queue. Separate path confinement failures from authentication, quota, and network errors. For a path error, preserve the evidence and notify the owner of the source relationship. For a network error, normal bounded retries may still apply. If the result of a write is unknown, do not assume success and do not repeat it without checking the destination. Reconcile the intended object and the actual object before deciding the next action.
A rollback plan should also cover service composition. A container image, system package, and manually installed binary may move independently. If a rollback changes one layer, confirm which executable the service actually starts. Restart long-running processes and repeat the version check. Container health checks should include the version or image digest, not only a successful process start. The rollback is complete only when the observed runtime matches the intended state.
After reconciliation, update the baseline manifest and document the residual work. Preserve the failed source entry, the test result, the fixed version, and any approved compatibility mapping. Remove disposable data only after the evidence has been retained according to policy. The next scheduled backup should start from a known tree and a known binary.
ZoomEye's app="rclone" product query returned 830 matches during this review. The number is useful for finding where rclone may exist, but it is not a backup inventory and does not reveal affected versions. Combine it with owner records, command paths, image digests, and actual run evidence. The quality of that internal inventory determines whether rollback and reconciliation can be completed across the fleet.
Top comments (1)
On resolving differences by content hash: the hash you can get differs by backend, and that bites reconciliation. For S3 multipart uploads the ETag is not an MD5 of the content, rclone only has an MD5 if it stored its own checksum metadata at upload, and some backends offer no hash at all. If the frozen manifest doesn't record which hash type each entry used, the post patch compare quietly falls back to size and modtime for part of the tree.
Did your sample backends all share a hash type, or did you see that mix?