GHSA-3x6r-wxxg-53vv
MEDIUMGHSA-3x6r-wxxg-53vv is a medium-severity (CVSS 5.3) vulnerability in github.com/rclone/rclone. O3 Security confirms whether GHSA-3x6r-wxxg-53vv is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
rclone: Infinite Scale TUS Creation Transport Error Causes a Nil-Response Panic
Blast Radius
github.com/rclone/rcloneReal-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.gowas unchanged at master commit961266888fe797390c535386f3b3aa46f4853602on 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
- Configure the actual Infinite Scale creation path to a closed local endpoint.
- Invoke
Object.CreateUploader. - The POST returns a transport error and no response.
getTusLocationOrRetrydereferencesresp.StatusCodeand 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 == nilbefore 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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/rclone/rclone | all versions | 1.75.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/rclone/rclone. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-3x6r-wxxg-53vv is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-3x6r-wxxg-53vv. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-3x6r-wxxg-53vv in your dependencies?
O3 detects GHSA-3x6r-wxxg-53vv across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.