Path Traversal in OpenBMB ChatDev File Upload Endpoint
CVE-2026-58166 is a path traversal vulnerability affecting OpenBMB ChatDev through version 2.2.0. The flaw exists in the file upload handling logic for the POST uploads session endpoint, where the application uses an attacker-supplied multipart filename to construct the destination path without proper sanitization in save_upload_file. By supplying a crafted filename containing directory traversal sequences such as ../ or an absolute path, an unauthenticated remote attacker can cause uploaded content to be written to arbitrary filesystem locations. The same unsanitized path handling also affects cleanup operations, allowing attacker-chosen files to be deleted.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation allows unauthenticated remote attackers to write arbitrary files to the server filesystem and delete arbitrary files via the affected upload and cleanup workflow. Depending on the targeted path and runtime environment, this can result in destruction of application or system files, tampering with application data, denial of service, exposure or corruption of sensitive information, and potentially further compromise if written files can influence application behavior or execution.
If you can’t patch tonight, do this now.
If immediate patching is not possible, restrict or disable the vulnerable file upload functionality where feasible, place the application behind controls that limit access to the upload endpoint, and run the service with the minimum filesystem permissions necessary so it cannot write to or delete sensitive paths outside the intended upload directory. Additional defensive checks should enforce server-side filename normalization and path validation before any file write or cleanup operation.
Patch, then assume compromise.
Upgrade OpenBMB ChatDev to a version that includes the fix introduced in commit 4fd4da6. Versions through 2.2.0 should be considered vulnerable. The vulnerable upload workflow should be corrected to sanitize multipart filenames, reject absolute paths and traversal sequences, and ensure all resolved upload destinations remain confined to an intended upload directory after canonicalization.
No public exploits tracked yet. Mallory keeps watching.
1 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.