Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

rclone: Infinite Scale TUS Creation Transport Error Causes a Nil-Response PanicGHSA-3x6r-wxxg-53vv

MEDIUMFix: rclone/rclone@5871d98

GHSA-3x6r-wxxg-53vv is a medium-severity (CVSS 5.3) CWE-248 vulnerability in github.com/rclone/rclone. A fix is available for github.com/rclone/rclone — see the affected versions and patch details below.

Also known asBIT-rclone-2026-79778CVE-2026-79778GO-2026-6183
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-3x6r-wxxg-53vv.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs19th percentile — riskier than 19% of all scored CVEsHighest risk
0.00%0.26%0.52%0.78%0.2%0.3%0.3%Sep 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-3x6r-wxxg-53vv by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 383,485 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐹github.com/rclone/rclone

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

1. Summary

A transport failure during the initial Infinite Scale TUS creation POST can return (nil response, non-nil error). Rclone dereferences the nil response before processing the error and panics. The production CreateUploader path reproduced the crash against a closed endpoint.

The security case is deployment-dependent. A one-shot upload already fails when its endpoint resets, while RC jobs recover panics in fs/rc/jobs/job.go and return a job error. The incremental denial of service is strongest in a long-lived VFS mount or concurrent/multi-remote CLI process where the upload runs in an unrecovered goroutine and the panic terminates unrelated work.

2. Affected Assets & Attack Surface

  • Verified rclone revision: a0c09f1381ae93e2a9a33c529d170186c61ad058 (v1.74.0-240-ga0c09f138)
  • Current-master check: backend/webdav/tus.go was unchanged at master commit 961266888fe797390c535386f3b3aa46f4853602 on 2026-07-18
  • Response evaluation: backend/webdav/tus.go:45-59
  • Creation path: backend/webdav/tus.go:61-107
  • Unrecovered VFS caller: vfs/write.go:71-81
  • Contained RC caller: fs/rc/jobs/job.go:107-115
  • Configuration: Infinite Scale WebDAV uploads using TUS
  • Code triggers: any pre-response transport failure, including refusal, reset, timeout, DNS/TLS/proxy failure, or cancellation
  • Security trigger: a malicious/compromised configured endpoint resets an upload in a long-lived or multi-workload process

3. Technical Root Cause Analysis

getTusLocationOrRetry switches on resp.StatusCode before checking whether resp is nil or handling the accompanying error. A nil response is valid when the HTTP transaction fails before a response is parsed. There is no recovery boundary in the WebDAV operation itself. Whether the panic is process-fatal depends on its caller: the VFS write path starts operations.Rcat in an unrecovered goroutine (vfs/write.go:71-81), whereas RC jobs wrap their function in recover (fs/rc/jobs/job.go:107-115).

4. Proof-of-Concept & Evidence

  1. Configure the actual Infinite Scale creation path to a closed local endpoint.
  2. Invoke Object.CreateUploader.
  3. The POST returns a transport error and no response.
  4. getTusLocationOrRetry dereferences resp.StatusCode and panics.

A remote endpoint can produce the same (nil response, non-nil error) state by accepting and resetting the connection before returning an HTTP response. TLS prevents arbitrary response modification but does not prevent the configured endpoint from closing or resetting its own connection. Refusal, DNS, TLS, proxy, and cancellation failures exercise the code defect but do not by themselves identify a remote security actor.

5. Impact Assessment

In an unrecovered CLI or VFS upload goroutine, the panic terminates the rclone process and any unrelated work it hosts. A hostile configured endpoint can repeat the condition whenever the victim initiates a TUS upload. RC jobs are excluded from the process-wide impact because their execution boundary recovers the panic and records an error. In a one-shot process dedicated to the hostile endpoint, the incremental security impact over an ordinary transport error is limited.

6. Remediation Guidance

  • Check resp == nil before accessing response fields.
  • Pass transport errors through the existing retry policy and return a normal error after exhaustion.
  • Test refusal, reset, timeout, DNS, TLS, proxy, and cancellation paths.
  • Add panic containment to long-lived worker goroutines as defense in depth; keep nil handling as the primary fix.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/rclone/rcloneall versions1.75.0go get github.com/rclone/rclone@v1.75.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/rclone/rclone, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/rclone/rclone to 1.75.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3x6r-wxxg-53vv is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate

A flaw was found in rclone. When using the WebDAV backend with TUS (resumable upload) support, a nil pointer dereference panic can occur if the server returns a nil HTTP response during a TUS upload operation. A malicious or misconfigured WebDAV server can trigger this condition, causing the rclone process to crash.

Workaround published by Red Hat
Avoid using rclone's WebDAV backend with TUS-enabled servers from untrusted sources. If TUS uploads are not required, use a WebDAV server configuration that does not advertise TUS support.
Source: Red Hat security advisory for GHSA-3x6r-wxxg-53vv (CC BY 4.0)

Frequently Asked Questions

## 1. Summary A transport failure during the initial Infinite Scale TUS creation POST can return `(nil response, non-nil error)`. Rclone dereferences the nil response before processing the error and panics. The production `CreateUploader` path reproduced the crash against a closed endpoint. The security case is deployment-dependent. A one-shot upload already fails when its endpoint resets, while RC jobs recover panics in `fs/rc/jobs/job.go` and return a job error. The incremental denial of service is strongest in a long-lived VFS mount or concurrent/multi-remote CLI process where the upload
O3 Security · Impact-Aware SCA

Is GHSA-3x6r-wxxg-53vv in your dependencies?

Find it across Go, including transitive dependencies.

rclone: Infinite Scale TUS Creation Transport Error Causes…