Typemill < 2.24.0 Path Traversal via ControllerApiImage::getPagemedia()

An authenticated attacker with Author-level privileges can supply traversal sequences (e.g., `../../`) in the `path` query parameter passed to `Storage::getFile()` while providing an empty `folder` argument. The old `getFolderPath()` method did not resolve symlinks or normalize the final path, so a crafted path like `../../../etc/passwd` would bypass the intended content-directory restriction. The attacker can then read arbitrary files on the server filesystem, such as configuration files or system secrets. This is a classic path traversal vulnerability [CWE-22].

The vulnerability resides in `system/typemill/Models/Storage.php`, specifically in the `getFile()` method and the helper `getFolderPath()`. The patch introduces a new `validatePath()` method that uses `realpath()` to resolve the final path and checks that it starts with the allowed base directory, preventing traversal sequences from escaping the content folder. All file operations (`getFile`, `writeFile`, `deleteFile`, `renameFile`, `copyFile`, `checkFile`, `getFileTime`, `deleteFolder`, `deleteContentFolder`, `deleteContentFolderRecursive`) are hardened by routing through `validatePath()`.

The patch adds a private `validatePath()` method that calls `realpath()` on the concatenated folder+filename and checks that the resolved path starts with the allowed base directory. If the path cannot be resolved or escapes the base, the method returns `false` and sets an error message. Every file operation in `Storage.php` now calls `validatePath()` before acting on the path, and the old direct string concatenation (`$folderpath . $filename`) is replaced with the validated result. This ensures that traversal sequences like `../` are resolved and rejected, closing the path traversal hole.