CVE-2024-6396

What it actually does

This is a network-exploitable path traversal and arbitrary file write/read issue in Aim. The vulnerable `_backup_run` logic improperly trusts attacker-controlled `run_hash` and `repo.path` values, allowing crafted paths to escape the intended repository or backup directory. A remote unauthenticated attacker can cause the server process to read sensitive files, write or overwrite arbitrary files accessible to the Aim process, corrupt application or system data, and potentially achieve remote code execution if they can overwrite executable code, startup scripts, SSH keys, cron jobs, service files, or application configuration loaded by the server.

Why it matters to the business

Successful exploitation can expose experiment data, credentials, model artifacts, source paths, environment secrets, and other sensitive files stored on or reachable from the Aim server. It can also disrupt operations by corrupting repository data or critical system files. Because the CVSS score is critical, EPSS is high, and exploit maturity is reported as weaponized, internet-exposed Aim instances should be treated as high-priority remediation targets even though this vulnerability is not currently listed in CISA KEV or associated with known ransomware use.

How an attack unfolds

An attacker first identifies an exposed Aim service, then sends crafted backup-related requests that manipulate the `run_hash` and/or `repo.path` parameters. By inserting absolute paths or traversal sequences, the attacker redirects the backup operation outside the expected Aim repository. For data theft, the attacker targets sensitive files and causes the application to package or return data that should not be accessible. For integrity impact, the attacker writes attacker-controlled content to arbitrary locations permitted by the Aim process account. If the service runs with excessive privileges or writable application paths are available, the attacker may overwrite code, configuration, scheduled tasks, authorized keys, or startup files to obtain persistent execution. The attack requires no user interaction and, based on the CVSS vector, no authentication.

How to fix it

Upgrade Aim to a version that contains the vendor fix as soon as one is available from the official Aim project. If an exact fixed version is not known for the deployed package, consult the upstream Aim security advisory, release notes, and package repository before redeployment. As immediate mitigation, remove public internet exposure for Aim services, require strong authentication and network-level access controls, and restrict access to trusted VPNs or private networks only. Run Aim under a dedicated low-privilege operating-system account with minimal filesystem permissions, and ensure it cannot write to system directories, application code directories, SSH directories, cron directories, service manager paths, or secret stores. Place repositories and backup destinations under tightly controlled directories, and block path traversal patterns and absolute paths at any reverse proxy or WAF layer where feasible. Rotate secrets that may have been readable from the Aim host if exploitation is suspected.

How to confirm the fix worked

Confirm the installed Aim version and compare it against the vendor-advised fixed release. Review application configuration to ensure Aim is not exposed directly to the internet and is protected by authentication and network restrictions. Validate filesystem permissions by confirming the Aim process account cannot write outside its intended repository, artifact, log, and backup directories. In a non-production test environment, attempt benign traversal payloads using `run_hash` or `repo.path` values that reference a harmless canary path outside the repository and confirm the request is rejected and no file is created, overwritten, backed up, or returned. Review package lock files, container images, and deployment manifests to ensure all running instances have been updated, not only source repositories.

Typical attack path

1. Discover an exposed Aim server or API endpoint reachable over the network.
2. Fingerprint the Aim version or behavior to determine whether it is likely vulnerable, especially around version 3.19.3.
3. Submit crafted backup/run requests containing malicious `run_hash` or `repo.path` values with path traversal or absolute path payloads.
4. Read or exfiltrate sensitive files by forcing the backup logic to include files outside the intended repository path.
5. Overwrite arbitrary files accessible to the Aim server process to corrupt data, deny service, or stage execution.
6. If possible, overwrite executable application files, configuration, cron/systemd artifacts, SSH keys, or startup scripts to achieve code execution and persistence.
7. Cover tracks by deleting temporary backup artifacts or blending requests into normal experiment-management traffic.

How to detect it

Review Aim application logs, reverse-proxy logs, WAF logs, API gateway logs, container logs, and host audit logs for backup-related requests containing traversal sequences, encoded traversal, absolute paths, or references to sensitive files. Focus on requests involving `run_hash`, `repo.path`, backup, export, or run-copy functionality. Look for unusual HTTP 200/500 responses around backup operations, large or unexpected backup downloads, repeated probing with different path payloads, and requests from unfamiliar IP addresses. On hosts, inspect file modification timelines for unexpected writes by the Aim process outside approved repository and artifact directories. Audit sensitive locations such as `/etc`, `/root/.ssh`, user SSH directories, cron directories, systemd unit paths, application source directories, virtual environments, and temporary directories. Use EDR or Linux audit logs to identify the Aim process opening or writing files outside expected paths. If exploitation is suspected, preserve logs and filesystem metadata before cleanup, compare affected directories against known-good images or backups, and rotate secrets that may have been present on the host.

• _backup_run
• run_hash=
• repo.path=
• ../
• ..%2f
• %2e%2e%2f
• ..%252f
• %2e%2e%252f
• /etc/passwd
• /etc/shadow
• /proc/self/environ
• /root/.ssh/
• /.ssh/authorized_keys
• /etc/cron.d/
• /etc/crontab
• /var/spool/cron/
• /etc/systemd/system/
• /tmp/aim
• aimhubio/aim
• aim server

What your security team should do

• Inventory all Aim deployments, containers, notebooks, ML platforms, and developer-hosted instances, prioritizing any service reachable from untrusted networks.
• Patch or rebuild Aim deployments from a vendor-fixed version; where no confirmed fixed version is available, isolate the service and apply compensating controls immediately.
• Block direct internet access to Aim and require VPN, SSO, reverse-proxy authentication, or allowlisted source networks.
• Run Aim with least privilege and verify the service account cannot read sensitive host paths or write to privileged locations.
• Search historical logs for suspicious backup requests, path traversal sequences, absolute filesystem paths, and attempts to access secrets or system files.
• Inspect hosts for unexpected file modifications in application directories, cron/systemd locations, SSH directories, shell startup files, and temporary backup paths.
• Rotate credentials, tokens, SSH keys, and API secrets stored on affected hosts if exploitation cannot be confidently ruled out.
• Add detection rules for traversal payloads involving `run_hash`, `repo.path`, and backup endpoints, and alert on Aim processes writing outside expected repository paths.