Fission: SanitizeFilePath lexical HasPrefix bypass permits sibling-directory escape

SanitizeFilePath in pkg/utils/utils.go validated that a path stayed under a safe directory by calling strings.HasPrefix(path, safedir). This is a lexical check, not a directory boundary check: /packages-extra/evil starts with /packages, so it passed. The function did not enforce a path-separator boundary, so any sibling directory whose name began with the safe-directory string was accepted.

Callers included the builder's Clean handler (pkg/builder/builder.go:208) and the fetcher's Fetch / Upload handlers (pkg/fetcher/fetcher.go). A tenant who could pre-create or control a sibling directory under the fetcher / builder's shared volume could induce a write or read outside the intended safe directory.

Affected

• Project: github.com/fission/fission
• Versions: all versions through v1.24.0 with SanitizeFilePath in the tree
• Audited commit: 647c141
• Component: pkg/utils/utils.go:SanitizeFilePath
• Callers: pkg/builder/builder.go:157,164,208, pkg/fetcher/fetcher.go:296,311,450,496,565,571
• Configuration: default; requires a sibling directory to the safe dir to exist on the filesystem

Fix section (paste into the Fix / Patches field)

Fixed in v1.25.0 by:

• PR #3445 (commit 8298e33e) — migrate every SanitizeFilePath call site (fetcher: storePath / tmpPath / secretDir / configDir / rename + writeSecretOrConfigMap; builder: srcPkg / deployPkg path validation and srcPkg stat) to new helpers (, , , , ) that operate through . enforces directory confinement in the kernel and is recognized by CodeQL as a traversal barrier.