GHSA-8V25-V8P6-QF7V: Path Traversal in rclone S3 API Gateway Emulation

The S3 API gateway emulation layer in rclone, accessible via the rclone serve s3 subcommand, contains a path traversal vulnerability. This component emulates an S3-compatible object storage server on top of rclone's backend storage systems. By exposing this gateway, hosts allow users to interact with files using standard S3 protocol verbs and clients.\n\nThe flaw lies within the translation of S3 object keys to local system or virtual file system (VFS) paths. Under normal operation, each S3 bucket corresponds to a top-level directory within the rclone serve root, while object keys correspond to files nested inside those directories. Users should not be able to traverse outside their allocated bucket directory.\n\nThis vulnerability allows remote attackers with access to the S3 gateway to traverse outside the bucket root directory. By using manipulated object keys, malicious actors can access, overwrite, or delete arbitrary files at the root of the served directory. This violates the multi-tenant isolation assumptions of the S3-compatible interface.

The core defect exists in how rclone processes S3 object keys to map them to physical paths. In Amazon S3, object keys are flat, opaque strings that can syntactically contain directory separators and relative elements. When processing operations like GetObject, rclone uses Go's standard path.Join function to combine the bucket name and the object key.\n\nThe Go standard library's path.Join function automatically runs path.Clean on the resulting string to normalize it. This behavior resolves relative path segments such as double dots (..) and single dots (.). If an S3 object key contains ../ sequences, path.Join resolves these relative segments against the bucket directory prefix.\n\nFor example, combining a bucket name of bucket and an object key of ../secret.txt produces bucket/../secret.txt. After normalization via path.Clean, this string resolves directly to secret.txt. This resulting path references a file at the root level of the serve directory, completely escaping the bucket directory restriction.

In the vulnerable implementation, operations in cmd/serve/s3/backend.go directly concatenate path strings using unsafe methods. The functions for object retrieval, metadata querying, file writing, and deletion constructed target paths without validating key structure.\n\nThe vulnerable code pattern is exemplified by the GetObject function:\n\ngo\n// Vulnerable mapping logic\nfp := path.Join(bucketName, objectName)\n\n\nThis direct join allowed relative segments to modify the target directory.\n\nThe patched code introduces a strict validation function canonicalKey and helper function bucketObjectPath. The core modification requires all S3 keys to match their fully cleaned canonical form. If a key contains relative segments, it fails validation and the operation is terminated.\n\ngo\n// Patched validation logic\nfunc canonicalKey(key string) bool {\n return key != "" && "/"+key == path.Clean("/"+key)\n}\n\nfunc bucketObjectPath(bucketName, objectName string) (string, error) {\n if !canonicalKey(objectName) {\n return "", errInvalidObjectName(objectName)\n }\n return path.Join(bucketName, objectName), nil\n}\n\n\nBy anchoring the key with a leading slash during cleaning, the validation ensures that no relative segments can escape the root of the key structure without changing the overall path string, preventing the validation from passing.

Exploitation of this vulnerability requires network access to the exposed rclone serve s3 endpoint. The attacker does not need special administrative access, only standard permissions to execute S3 API calls on the target bucket. The attack is fully operationalizable using standard S3 client tools or direct HTTP requests.\n\nAn attacker targeting an arbitrary file root-secret.txt at the root of the serve directory would construct an S3 request specifying a valid bucket and a traversed object key. Using the AWS Command Line Interface, the command takes the following form:\n\nbash\naws s3api get-object --endpoint-url http://<rclone-ip>:8080 --bucket targetbucket --key "../root-secret.txt" output.txt\n\n\nThe corresponding HTTP request demonstrates how the raw path is transmitted to the server:\n\nhttp\nGET /targetbucket/../root-secret.txt HTTP/1.1\nHost: <rclone-ip>:8080\nAuthorization: AWS4-HMAC-SHA256 ...\n\n\nUpon receiving this request, rclone parses the object name as ../root-secret.txt. The vulnerable backend normalizes the path to root-secret.txt and returns the file contents to the client, bypassing access boundaries.

The impact of this path traversal vulnerability is significant for systems utilizing rclone serve s3 in multi-tenant or untrusted environments. If multiple users are assigned isolated buckets, any user can escape their boundary. This allows unauthorized access to data stored in other buckets or directly at the root.\n\nBeyond arbitrary file retrieval (information disclosure), the vulnerability permits arbitrary file creation and modification. An attacker can write files using PutObject with traversed keys, allowing them to overwrite critical application configurations or upload malicious files to unauthorized directories.\n\nFurthermore, the deleteObject code path is vulnerable. Attackers can delete files at the root level of the server, leading to denial of service or destruction of data. This combination of read, write, and delete capabilities results in complete compromise of the served storage root directory.

The primary remediation path is upgrading rclone to version v1.74.4 or later. The patched versions enforce strict canonical path checks on all client-supplied S3 keys. This prevents any non-canonical keys from being processed, causing the server to respond with a 400 Bad Request instead of performing unsafe path normalization.\n\nWhen immediate upgrading is not possible, administrative workarounds can reduce exposure. A reverse proxy or web application firewall (WAF) can be deployed in front of the S3 endpoint. Rules should be configured to inspect and block incoming HTTP requests containing .. or URL-encoded equivalents such as %2e%2e within the request path.\n\nIn addition to input filtering, the rclone process should run with the lowest possible system privileges. Running rclone in a rootless container or a restricted chroot jail limits the file system scope. This sandboxing ensures that even if a path traversal occurs, the process cannot access sensitive host system files outside the designated container environment.