GHSA-95cv-r8x4-vh75

Summary

The /api/fs/batch_rename handler validates and authorizes only the requested source directory. It rejects path separators in new_name, but it does not validate src_name. The handler concatenates src_dir and attacker-controlled src_name, then passes the result to the filesystem rename layer, where the path is normalized.

An authenticated user with rename permission can set src_name to traversal segments such as ../../ab/secret.txt. When the user's base path is /team/a and src_dir is /writable, the authorized directory becomes /team/a/writable, but the final source path normalizes to /team/ab/secret.txt. The file outside the user's base path is then renamed.

Details

The HTTP API registers filesystem management routes under the authenticated group:

• server/router.go:104 registers _fs(auth.Group("/fs")).
• server/router.go:198 through server/router.go:205 expose /api/fs/batch_rename.

The vulnerable code is in server/handles/fsbatch.go:

• src_dir is constrained through user.JoinPath(req.SrcDir) (server/handles/fsbatch.go:170 through server/handles/fsbatch.go:174).
• Write permission is checked only for that constrained directory (server/handles/fsbatch.go:176 through server/handles/fsbatch.go:185).
• The loop checks renameObject.NewName with checkRelativePath, but does not check renameObject.SrcName (server/handles/fsbatch.go:186 through server/handles/fsbatch.go:194).
• The handler builds filePath := fmt.Sprintf("%s/%s", reqPath, renameObject.SrcName) and passes it to fs.Rename (server/handles/fsbatch.go:195 through server/handles/fsbatch.go:196).

The single-file rename path shows the intended pattern: checkRelativePath(req.Name) rejects separators, empty strings, ., and .. before renaming (server/handles/fsmanage.go:284 through server/handles/fsmanage.go:333). Batch rename applies this protection to the destination name only, not to the source name.

Lower layers...