Bug
apply_fix() properly validates that source and target paths are inside the configured library boundary (lines 6192-6246), but three other functions that call shutil.move() or shutil.rmtree() on DB-sourced paths skip this validation entirely:
api_undo() (~line 8581) — shutil.move(new_path, old_path) with no boundary check
api_undo_all_drastic() (~line 8528) — same issue in bulk
api_replace_corrupt() (~line 8768) — shutil.rmtree(new_path) + shutil.move(old_path, new_path) with no boundary check
If database data is corrupted or tampered with, these could move/delete files anywhere on the filesystem.
Fix
Apply the same library boundary validation pattern from apply_fix() to all three functions. Check that both source and target paths resolve inside config['library_path'].
Severity
Critical — these functions operate on real user files with no guardrails.
Found via code audit.
Bug
apply_fix()properly validates that source and target paths are inside the configured library boundary (lines 6192-6246), but three other functions that callshutil.move()orshutil.rmtree()on DB-sourced paths skip this validation entirely:api_undo()(~line 8581) —shutil.move(new_path, old_path)with no boundary checkapi_undo_all_drastic()(~line 8528) — same issue in bulkapi_replace_corrupt()(~line 8768) —shutil.rmtree(new_path)+shutil.move(old_path, new_path)with no boundary checkIf database data is corrupted or tampered with, these could move/delete files anywhere on the filesystem.
Fix
Apply the same library boundary validation pattern from
apply_fix()to all three functions. Check that both source and target paths resolve insideconfig['library_path'].Severity
Critical — these functions operate on real user files with no guardrails.
Found via code audit.