| Título | https://github.com/kubescape/ kubescape 4.0.12 Incorrect Permission Assignment for Critical Resource |
|---|
| Descrição | 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. |
|---|
| Fonte | ⚠️ https://github.com/kubescape/kubescape/issues/4091 |
|---|
| Utilizador | carfeii (UID 97470) |
|---|
| Submissão | 14/10/2026 14h39 (há 23 dias) |
|---|
| Moderação | 06/11/2026 10h21 (23 days later) |
|---|
| Estado | Aceite |
|---|
| Entrada VulDB | 431789 [kubescape até 4.0.15 Output printresults.go GetWriter outputFile Elevação de Privilégios] |
|---|
| Pontos | 20 |
|---|