| 제목 | https://github.com/kubescape/ kubescape 4.0.12 Incorrect Permission Assignment for Critical Resource |
|---|
| 설명 | Scan report file is written with default, often world-readable permissions
Affected versions: github.com/kubescape/kubescape/v3 <= 4.0.12
Description
## Summary
`kubescape scan --output <file>` writes the scan report using plain `os.Create`, with no explicit permission mode. The resulting file's permissions are the OS default (0666) masked by the running process's umask, which under a common umask leaves the file group- and/or world-readable. A scan report contains cluster/workload reconnaissance data (resource and namespace names, container images, which security controls failed and why, including privileged-container and likely-hardcoded-secret-name findings), effectively a ready-made map of weaknesses in the scanned environment. `--output` is kubescape's own documented way to persist scan results, routinely used in CI/CD as a build artifact, not an obscure flag.
## Details
`core/pkg/resultshandling/printer/printresults.go`:
```go
func GetWriter(ctx context.Context, outputFile string) *os.File {
if outputFile != "" {
if err := os.MkdirAll(filepath.Dir(outputFile), outputDirPerm); err != nil {
...
}
f, err := os.Create(filepath.Clean(outputFile))
...
}
...
}
func GetWriterNoFallback(outputFile string) (*os.File, error) {
...
f, err := os.Create(outputFile)
...
}
```
A third function, `GetWriterNoStdoutFallback`, has the same pattern. None of the three set an explicit file mode; `outputDirPerm` (0750) is applied to the containing directory, but only when `os.MkdirAll` creates it, not when writing into an existing directory.
## POC
(available upon request)
## Impact
Confirmed: running `kubescape scan <target> --output <file>` produces a report file with permissions determined solely by the process umask rather than a deliberate, restrictive mode. Under common umask values, the resulting file is group-readable and/or world-readable. Since the report is a detailed catalog of a scanned environment's security weaknesses, and `--output` is the tool's standard mechanism for persisting results (a normal part of CI/CD usage), this exposes that reconnaissance data to any other local user or process able to read the report's location.
## Suggested Fix
Open the report file with an explicit restrictive mode (`0600`) rather than relying on the process umask, and explicitly `Chmod` the file to that mode after opening for the case where it already existed with looser permissions. Skip the `Chmod` for non-regular files (a caller explicitly requesting a device node like `/dev/null` as a sink), since changing permissions on those isn't this fix's concern and typically isn't even permitted for a non-owning process. |
|---|
| 원천 | ⚠️ https://github.com/kubescape/kubescape/issues/4091 |
|---|
| 사용자 | carfeii (UID 97470) |
|---|
| 제출 | 2026. 10. 14. PM 02:39 (23 날 ago) |
|---|
| 모더레이션 | 2026. 11. 06. AM 10:21 (23 days later) |
|---|
| 상태 | 수락 |
|---|
| VulDB 항목 | 431789 [kubescape 까지 4.0.15 Output printresults.go GetWriter outputFile 권한 상승] |
|---|
| 포인트들 | 20 |
|---|