Alessia Nardotto

In Kura versions <= 5.6.2, the "Command" file-upload handler at `POST /admin/denali/file/command` extracts a client-supplied ZIP archive into the configured `command.working.directory`. The path-containment check `validateFileName()` compares canonical paths with `String.startsWith()` without appending a trailing path separator, so an entry that canonicalises to a sibling directory sharing the same string prefix (e.g. `/tmpevil/x` when the intended directory is `/tmp`) is accepted. The handler then calls `parent.mkdirs()` and `new FileOutputStream(newFile)`, creating directories and writing attacker-controlled bytes outside the intended extraction root. The command service is disabled by default since Kura 4.0.0 [1]. The issue does not apply when the command service is disabled. The caller must be authenticated with `rest.command` permission.

In Kura versions <= 5.6.2, `CommandCloudApp.execute()` extracts a caller-supplied ZIP archive into a caller-supplied directory inside the Kura JVM process before dispatching the command to the executor service. On a packaged Kura installation the JVM runs as `kurad` with `CAP DAC OVERRIDE`, while the configurable "Unprivileged" executor drops to the `kura` user via `su`. A caller with permissions `rest.command` who is intentionally restricted to unprivileged command execution (`privileged.command.service.enable=false`, the default) can therefore set `workingDirectory` to `/` and use the ZIP body to write or overwrite arbitrary files on the device as `kurad`, completely bypassing the unprivileged sandbox the operator selected. The command service is disabled by default since Kura 4.0.0 [1]. The issue does not apply when the command service is disabled. [1] https://github.com/eclipse-kura/kura/blob/f9f969231892769a269876b23f19fa0e8173e3df/kura/distrib/RELEASE NOTES.txt#L94