| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/fission/fission | < 1.25.0 | 1.25.0 |
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.
github.com/fission/fissionSanitizeFilePath in the tree647c141pkg/utils/utils.go:SanitizeFilePathpkg/builder/builder.go:157,164,208, pkg/fetcher/fetcher.go:296,311,450,496,565,571Fix section (paste into the Fix / Patches field)
Fixed in v1.25.0 by:
8298e33e) — migrate every SanitizeFilePath call site (fetcher: storePath /
tmpPath / secretDir / configDir / rename + writeSecretOrConfigMap; builder: srcPkg / deployPkg path validation and srcPkg stat) to new pkg/utils/root.go helpers (RootJoin, RootStat, RootWriteFile, RootMkdirAll,
RootRename) that operate through os.Root. os.Root enforces directory confinement in the kernel and is recognized by CodeQL go/path-injection as a traversal barrier.5aac6f0b) — delete the deprecated SanitizeFilePath itself once no callers
remained. The vulnerable function no longer exists in the tree.Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free