CVE-2026-58166: Verified Repro With Script Download

OpenBMB ChatDev through 2.2.0 exposes an unauthenticated file-upload path traversal in the product workflow server. The original POST /api/uploads/{session_id} route passes the raw multipart filename into AttachmentService.save_upload_file(), which joins it under a temporary upload directory without sanitization at the vulnerable commit. A remote unauthenticated attacker can first mint a session through the product /ws WebSocket, then upload a filename containing ../ path traversal segments. In this run, that primitive was chained on the original ChatDev product surface into code execution: the upload wrote a malicious workflow YAML outside the intended upload directory, and the product POST /api/workflow/run endpoint then executed attacker-controlled Python through ChatDev's real workflow python node runtime.

• Package/component affected: OpenBMB/ChatDev workflow server, specifically server/routes/uploads.py and server/services/attachment_service.py (AttachmentService.save_upload_file). The demonstrated execution sink is the real workflow runtime reached by server/routes/execute_sync.py (POST /api/workflow/run), runtime.sdk.run_workflow, and runtime/node/executor/python_executor.py.
• Affected versions: ChatDev <= 2.2.0, represented by vulnerable checkout 4fd4da603801766b14ad8788649cfc1ad21f99a6^ = a6a5cda5560053136897aa44301eacc6c48d8168.
• Fixed version/commit: 4fd4da603801766b14ad8788649cfc1ad21f99a6, which adds upload filename basename sanitization via _safe_upload_filename().
• Risk level and consequences: Critical. A remote unauthenticated attacker can write/delete files reachable by the server process via traversal. This run shows that the write primitive can be chained into product-level code execution by writing a workflow YAML to a traversed path and invoking ChatDev's workflow execution API to run attacker-controlled Python.

Impact Parity

• Disclosed/claimed maximum impact: Remote code execution (code_execution) after unauthenticated path traversal upload.
• Reproduced impact from this run: Full code execution on the original product API surface. Two vulnerable attempts created attacker-controlled marker files (bundle/repro/rce_marker_vuln_1.txt and bundle/repro/rce_marker_vuln_2.txt) from Python code executed by ChatDev's real workflow runtime after the malicious YAML was written via the unauthenticated upload path. Two fixed-commit attempts sanitized the filename, did not create the traversed YAML target, and returned 404 from /api/workflow/run because the target YAML file was not written.
• Parity: full.
• Not demonstrated: No privilege escalation or sandbox escape beyond the privileges of the ChatDev server process. The RCE demonstrated is arbitrary Python execution within the server's normal workflow execution environment.

Root Cause

At the vulnerable checkout, AttachmentService.save_upload_file() trusts UploadFile.filename and joins it directly onto a temporary directory:

filename = upload.filename or "upload.bin"
temp_dir = Path(tempfile.mkdtemp(prefix="mac_upload_"))
temp_path = temp_dir / filename
with temp_path.open("wb") as buffer:
    ...

Because Python path joining preserves ../ segments, a multipart filename such as ../../../../tmp/chatdev_cve58166_vuln_1_link.yaml escapes the temporary upload directory. The product upload route is reachable remotely at POST /api/uploads/{session_id} and only requires a known session id. The reproduction obtains that session without authentication by opening the product /ws WebSocket; the server returns a fresh UUID session and records it in active_connections, after which ensure_known_session(..., require_connection=False) accepts uploads for that session.

The vulnerable function also removes temp_path in a finally block. A direct traversal write is therefore deleted after registration, but the reproduction uses a symlink at the traversed path. open("wb") follows the symlink and writes the malicious YAML to the symlink target, while unlink() removes only the symlink. The resulting YAML file persists outside the upload directory. The product /api/workflow/run endpoint accepts an absolute yaml_file path and runs the referenced workflow; the uploaded YAML contains a single ChatDev python node, causing PythonNodeExecutor to execute attacker-supplied Python from task_prompt with subprocess.run().

The fix commit 4fd4da603801766b14ad8788649cfc1ad21f99a6 adds AttachmentService._safe_upload_filename(), normalizing path separators and reducing the multipart filename to a safe basename before joining it with the temporary directory. In the fixed negative controls, the same traversal filename is returned as chatdev_cve58166_fixed_*_link.yaml, the /tmp/...fixed_*.yaml target is not created, and the follow-on workflow execution cannot find the malicious YAML.

Fix commit: https://github.com/OpenBMB/ChatDev/commit/4fd4da603801766b14ad8788649cfc1ad21f99a6

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh with bash.
2. The script:
   • Reuses the prepared project cache at <project_cache_dir>/repo or clones https://github.com/OpenBMB/ChatDev.git if absent.
   • Resolves the fixed commit and checks out 4fd4da603801766b14ad8788649cfc1ad21f99a6^ for vulnerable runs and 4fd4da603801766b14ad8788649cfc1ad21f99a6 for fixed runs.
   • Starts the original product server via server_main.py --host 127.0.0.1 --port <port> and waits for /health.
   • Opens the real /ws WebSocket to mint an unauthenticated session.
   • Sends a real multipart POST /api/uploads/{session_id} request with a traversal filename targeting a symlink under /tmp.
   • In vulnerable runs, persists a malicious workflow YAML outside the upload directory and then calls the real POST /api/workflow/run endpoint to execute attacker-controlled Python that writes a marker file under bundle/repro/.
   • In fixed runs, verifies the same request is sanitized, the traversed YAML target is not created, and the workflow run fails closed with no marker file.
3. Expected evidence:
   • bundle/repro/runtime_manifest.json with entrypoint_kind=api_remote, service_started=true, healthcheck_passed=true, and target_path_reached=true.
   • bundle/repro/eval_summary.json with both vulnerable code-execution attempts true and both fixed-blocked attempts true.
   • bundle/repro/result_vuln_1.json, result_vuln_2.json, result_fixed_1.json, and result_fixed_2.json.
   • bundle/repro/rce_marker_vuln_1.txt and bundle/repro/rce_marker_vuln_2.txt containing RCE_OK_FROM_CHATDEV_WORKFLOW ....
   • Runtime logs in bundle/logs/.

Evidence

The script was run twice consecutively and succeeded both times. The final run produced:

{
  "vuln_attempts_code_execution": [true, true],
  "vuln_attempts_persistent_yaml_write": [true, true],
  "vuln_response_names": [
    "../../../../../../../../../../../../../../../../tmp/chatdev_cve58166_vuln_1_link.yaml",
    "../../../../../../../../../../../../../../../../tmp/chatdev_cve58166_vuln_2_link.yaml"
  ],
  "vuln_marker_contents": [
    "RCE_OK_FROM_CHATDEV_WORKFLOW role=vuln attempt=1\n",
    "RCE_OK_FROM_CHATDEV_WORKFLOW role=vuln attempt=2\n"
  ],
  "fixed_attempts_blocked_chain": [true, true],
  "fixed_response_names": [
    "chatdev_cve58166_fixed_1_link.yaml",
    "chatdev_cve58166_fixed_2_link.yaml"
  ],
  "fixed_target_created": [false, false],
  "confirmed": true
}

Important artifact locations:

• Main proof log: bundle/logs/reproduction_steps.log.
• Vulnerable server logs: bundle/logs/server_vuln_1.log, bundle/logs/server_vuln_2.log.
• Vulnerable driver logs: bundle/logs/driver_vuln_1.log, bundle/logs/driver_vuln_2.log.
• Fixed server logs: bundle/logs/server_fixed_1.log, bundle/logs/server_fixed_2.log.
• Fixed driver logs: bundle/logs/driver_fixed_1.log, bundle/logs/driver_fixed_2.log.
• Structured runtime evidence: bundle/repro/runtime_manifest.json.
• Marker files proving attacker-controlled Python execution: bundle/repro/rce_marker_vuln_1.txt, bundle/repro/rce_marker_vuln_2.txt.

Example vulnerable result (bundle/repro/result_vuln_1.json): the upload response echoed the raw traversal filename, the traversed YAML target existed after upload, the symlink was removed, /api/workflow/run returned HTTP 200 with final_message RCE_MARKER_WRITTEN role=vuln attempt=1, and the marker contained RCE_OK_FROM_CHATDEV_WORKFLOW role=vuln attempt=1.

Example fixed result (bundle/repro/result_fixed_1.json): the upload response name was sanitized to chatdev_cve58166_fixed_1_link.yaml, the traversed YAML target did not exist, /api/workflow/run returned 404 (YAML file not found), and no marker file was created.

Recommendations / Next Steps

• Keep the fixed _safe_upload_filename() behavior: normalize both POSIX and Windows separators, strip directory components, and reject or replace empty/special names such as ., .., and blank filenames.
• Consider adding defense in depth to save_upload_file() by resolving the final path and verifying it remains under the temporary directory before opening it.
• Avoid following symlinks for temporary upload writes where possible, or create temp files with safe APIs that prevent symlink traversal.
• Restrict /api/workflow/run from accepting arbitrary absolute YAML paths unless this is an explicit trusted-admin feature. Prefer resolving workflow files only under the configured workflow directory.
• Add end-to-end regression tests that send multipart filenames with ../, absolute paths, Windows separators, symlink targets, and the RCE chain pattern demonstrated here.
• Upgrade users to a version containing commit 4fd4da603801766b14ad8788649cfc1ad21f99a6 or later.

Additional Notes

• The reproduction is idempotent: the script removes old /tmp/chatdev_cve58166_* files and marker files before each attempt, chooses free local ports, and runs two vulnerable and two fixed attempts per invocation.
• The script uses the original product server entrypoint (server_main.py) and real product routes. It does not reimplement the vulnerable upload handler or workflow execution sink.
• A small sitecustomize.py shim is used only to avoid a Python import-cycle in the current environment when importing runtime submodules; it does not modify AttachmentService, routes, workflow execution logic, or the vulnerable/fixed behavior under test.

No fixed-version bypass was confirmed. The variant analysis found one same-sink, vulnerable-only alternate filename form: an absolute multipart filename reaches the same AttachmentService.save_upload_file() path-join flaw as the parent ../ traversal on vulnerable commit a6a5cda5560053136897aa44301eacc6c48d8168. However, the fixed commit 4fd4da603801766b14ad8788649cfc1ad21f99a6 reduces client-controlled filenames to a basename before joining with the temporary upload directory, so both the parent ../ traversal and the absolute-filename alternate trigger are blocked on the fixed/latest tested source. The stage therefore records a negative bypass verdict with a bounded candidate matrix.

Fix Coverage / Assumptions

The original fix relies on the invariant that AttachmentService.save_upload_file() never joins attacker-controlled directory components into temp_dir / filename. Commit 4fd4da603801766b14ad8788649cfc1ad21f99a6 adds AttachmentService._safe_upload_filename(raw), which:

• replaces Windows backslashes with POSIX separators,
• applies os.path.basename(...),
• trims whitespace,
• maps empty, ., and .. names to upload.bin, and
• uses the sanitized basename for the temporary write and attachment display name.

This explicitly covers the vulnerable upload route POST /api/uploads/{session_id} because server/routes/uploads.py::upload_attachment() calls only manager.attachment_service.save_upload_file(session_id, file) for multipart uploads. Source scanning found no other server-side multipart endpoint that calls save_upload_file().

The fix does not attempt to change unrelated high-risk product behavior such as unauthenticated session creation over /ws, arbitrary absolute yaml_file handling in POST /api/workflow/run, or local-tool/workflow authoring APIs. Those behaviors may deserve separate hardening, but they are not alternate ways to reach the same upload filename path traversal sink.

Target threat-model review: no SECURITY.md or explicit repository threat model file was present in the tested checkout. The product documentation exposes Web UI and HTTP workflow execution surfaces, and no documentation was found that excludes unauthenticated upload path traversal from security scope.

Variant / Alternate Trigger

Tested candidates:

1. Parent baseline control: POSIX ../ traversal filename through AttachmentService.save_upload_file().

   • Vulnerable commit: escaped the temporary upload directory via a symlink target and deleted the supplied symlink path.
   • Fixed/latest commit: blocked; response/record basename was sanitized.

2. Candidate alternate trigger: absolute multipart filename with symlink target.

   • Entry point equivalence: same production route as parent, POST /api/uploads/{session_id}, because the route passes multipart UploadFile.filename to the same sink. The runtime test uses a direct UploadFile-compatible object against the service sink for deterministic side-by-side source checks; the parent RCA already validated the remote API route to this sink.
   • Code path: server/routes/uploads.py::upload_attachment() → server/services/attachment_service.py::AttachmentService.save_upload_file() → temp_path = temp_dir / filename → temp_path.open("wb").
   • Vulnerable behavior: because pathlib.Path discards the left-hand side when the right-hand operand is absolute, temp_dir / "/attacker/path" writes to the attacker-specified absolute path. With a symlink at that path, the write follows the symlink and persists data outside the temp directory while cleanup removes only the symlink.
   • Fixed/latest behavior: _safe_upload_filename() converts the absolute path to a basename, so the write stays under temp_dir; the symlink target is not created.

3. Candidate alternate trigger: absolute multipart filename pointing at an existing file.

   • Same sink and same absolute-path semantics as candidate 2.
   • Vulnerable behavior: the existing target is overwritten and then removed by the cleanup unlink().
   • Fixed/latest behavior: the existing target remains unchanged; sanitized basename is stored under the temp/attachment workspace.

Bounded source scan results:

• server/routes/uploads.py is the only route that accepts a multipart upload and calls AttachmentService.save_upload_file().

• server/routes/batch.py accepts UploadFile, but server/services/batch_parser.py only uses the upload filename to select/label CSV/XLS parsing (Path(filename).suffix and .stem), and BatchRunService._sanitize_label() constrains derived task directories. It does not join the raw multipart filename into an arbitrary write path.

• Workflow CRUD endpoints in server/routes/workflows.py route through validate_workflow_filename() and reject traversal/absolute filenames.

• server/routes/tools.py restricts local tool filenames with an alphanumeric/underscore/dash regex plus a post-resolution relative_to() check.

• server/routes/vuegraphs.py stores filename as a SQLite key rather than a filesystem path.

• Package/component affected: OpenBMB/ChatDev workflow server upload attachment handling, primarily server/services/attachment_service.py and server/routes/uploads.py.

• Affected version tested: vulnerable parent commit a6a5cda5560053136897aa44301eacc6c48d8168 (4fd4da603801766b14ad8788649cfc1ad21f99a6^).

• Fixed/latest version tested: 4fd4da603801766b14ad8788649cfc1ad21f99a6; in this run origin/main resolved to the same commit.

• Risk level and consequences: On vulnerable versions, the absolute-filename form has the same arbitrary file write/delete primitive as the parent bug and can support the same RCE chain if delivered through the unauthenticated upload route. On the fixed/latest commit, the tested candidates do not escape the upload temp directory.

Impact Parity

• Disclosed/claimed maximum impact for parent: remote code execution after unauthenticated upload path traversal.
• Reproduced impact from this variant run: vulnerable-only arbitrary file write/delete at the same sink using an absolute filename. The fixed/latest commit blocked this behavior.
• Parity: partial for the vulnerable-only alternate trigger; none as a fixed-version bypass.
• Not demonstrated: No code execution was demonstrated for the absolute-filename candidate in the variant stage because the purpose was to test fix coverage. The parent reproduction already demonstrated the RCE chain for the same sink on vulnerable code. No fixed-version write/delete/RCE bypass was observed.

Root Cause

The underlying vulnerable root cause is the same as the parent issue: pre-fix AttachmentService.save_upload_file() trusted UploadFile.filename and joined it into a server-side temporary path before opening it for writing. In Python pathlib, both ../ components and absolute right-hand operands can escape a base directory when joined naively. The parent bug used ../ traversal; the variant candidate used an absolute filename. Both exploit the same missing basename/path-confinement invariant before temp_path.open("wb") and cleanup temp_path.unlink().

The fixed commit closes this class for upload filenames by reducing all slash/backslash-containing input to a final basename before any path join. Therefore, the alternate absolute-filename candidate is not a bypass of commit 4fd4da603801766b14ad8788649cfc1ad21f99a6.

Fix commit: https://github.com/OpenBMB/ChatDev/commit/4fd4da603801766b14ad8788649cfc1ad21f99a6

Reproduction Steps

1. Run bundle/vuln_variant/reproduction_steps.sh with bash.
2. The script:
   • resolves the vulnerable commit (4fd4da603801766b14ad8788649cfc1ad21f99a6^), fixed commit (4fd4da603801766b14ad8788649cfc1ad21f99a6), and latest origin/main when available;
   • creates isolated source clones under bundle/vuln_variant/ and does not mutate the repro checkout;
   • runs an UploadFile-compatible driver against AttachmentService.save_upload_file() for the parent baseline and two absolute-filename candidates;
   • writes structured results for vulnerable, fixed, and latest targets; and
   • exits 0 only if a fixed/latest bypass is reproduced, otherwise exits 1 after successful evaluation.
3. Expected evidence for this run:
   • bundle/vuln_variant/eval_summary.json shows bypass_confirmed=false, vulnerable_only_alternate_trigger_observed=true, and fixed_blocks_parent_baseline=true.
   • bundle/vuln_variant/result_vulnerable.json shows the absolute filename candidates escape/delete on the vulnerable commit.
   • bundle/vuln_variant/result_fixed.json shows the same candidates do not escape/delete on the fixed commit.

Evidence

Primary logs and outputs:

• Main run log: bundle/logs/vuln_variant_reproduction_steps.log.
• Vulnerable candidate log: bundle/logs/vuln_variant_driver_vulnerable.log.
• Fixed candidate log: bundle/logs/vuln_variant_driver_fixed.log.
• Structured summary: bundle/vuln_variant/eval_summary.json.
• Structured vulnerable evidence: bundle/vuln_variant/result_vulnerable.json.
• Structured fixed evidence: bundle/vuln_variant/result_fixed.json.
• Tested revision records: bundle/logs/vuln_variant_fixed_version.txt and bundle/logs/vuln_variant_latest_version.txt.

Key final-run summary:

{
  "vulnerable_commit": "a6a5cda5560053136897aa44301eacc6c48d8168",
  "fixed_commit": "4fd4da603801766b14ad8788649cfc1ad21f99a6",
  "latest_commit": "4fd4da603801766b14ad8788649cfc1ad21f99a6",
  "bypass_confirmed": false,
  "vulnerable_only_alternate_trigger_observed": true,
  "fixed_blocks_parent_baseline": true
}

For candidate_absolute_filename_symlink, the vulnerable result has escaped_temp_dir_via_write=true and deleted_supplied_path=true. The fixed result has escaped_temp_dir_via_write=false, deleted_supplied_path=false, and a sanitized record name fixed_candidate_absolute_filename_symlink_link.txt.

For candidate_absolute_filename_delete, the vulnerable result has deleted_supplied_path=true. The fixed result has deleted_supplied_path=false and target_preserved_original=true.

The script was run twice consecutively. Both runs completed deterministically and exited 1, which is the expected negative-bypass result for this variant stage.

Recommendations / Next Steps

• Keep _safe_upload_filename() as a shared invariant for every path that accepts multipart upload filenames.
• Add regression tests for absolute multipart filenames in addition to ../, Windows backslashes, blank, ., and .. names. The current fix logic should pass these tests.
• Consider defense-in-depth in save_upload_file() by resolving temp_path and verifying it is inside temp_dir before opening, even after basename sanitization.
• Consider opening temp files with symlink-resistant APIs where practical.
• Separately review unauthenticated workflow execution and absolute yaml_file handling in POST /api/workflow/run; these are not bypasses of this upload filename fix, but the parent RCE chain shows they materially increase impact when combined with any file-write primitive.

Additional Notes

• The variant script uses isolated source clones under bundle/vuln_variant/ and does not leave the project cache/repro checkout in a different state.
• The direct service-sink test is appropriate for fix-coverage analysis because the parent reproduction already proved the remote unauthenticated API path reaches AttachmentService.save_upload_file() unchanged.
• No repository SECURITY.md or explicit threat model document was found in the tested source tree.