CVE-2024-8769 is a critical (CVSS 9.1) arbitrary file deletion in aimhubio/aim. The run_hash value is joined into a path in LockManager.release_locks without normalization, so a crafted value can delete any file the tracking server can reach. The record names a commit, not a release, so check for a fixed version.
What's affected
The record names aimhubio/aim at commit bb76afe. The flaw is in LockManager.release_locks, which builds a file path from the user controllable run_hash parameter and deletes the file.
The function is reached through Repo._close_run(), which the tracking server exposes through its instruction API. That makes the weakness reachable over the network by anyone who can talk to the server. The record says an attacker can delete any file on the machine running the tracking server, within what the server's account may delete.
No release number appears in the record, and the reference is a huntr report that we could not read automatically. Look in the Aim release notes for the version that fixed this. A second Aim record in this range, CVE-2024-7760, covers cross-site request forgery against the same server.
How to check if you're exposed
Check which version of the package your environments have installed.
pip show aim
pip list | grep -i aim
Run the commands inside each virtual environment, container image and notebook environment that might use it, because the system Python often differs from the project one. For a lockfile or requirements file, search for aim and read the pinned version.
Find any running tracking server, which is started with the aim server command, and check which accounts and networks can reach it. Check what the server account may delete, such as experiment data, configuration and other users' files.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan can read a dependency manifest and flag known vulnerable versions without installing anything.
What to do now
- List Aim installs and versions and any running tracking server.
- Restrict network access to the server with a VPN, firewall or authenticating proxy.
- Run the server under a dedicated account that can only touch the Aim repository folder.
- Back up the Aim repository so a deletion can be reversed.
- Upgrade to a version the project says fixes the path handling, after confirming in its notes.
- Review the related record CVE-2024-7760 in the same pass.
Why it matters
A file path built from outside input is only safe if you check where it ends up. Here a hash value that should look like a short hex string was accepted as any text, including parent directory parts, so the delete call followed the path out of the data folder.
The class is path traversal. Two fixes work together: validate that identifiers match the expected shape, and resolve the final path and compare it with the allowed folder before touching it. Delete operations deserve extra care since the damage is permanent unless you have backups.
The weakness class is CWE-22: Path Traversal. The CVSS vector in the record is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H, which scores 9.1. This CVE is not listed in the CISA Known Exploited Vulnerabilities catalog at the time of writing.
Quick check
Can this be reached over the network?
The record says it is exposed through the tracking server instruction API, so anyone who can reach the server may be able to trigger it.
What limits the damage?
The server account's file permissions. A narrow account and backups reduce the harm.
Sources
Last reviewed: 19 October 2026.
