CVE-2024-55459

What it actually does

Keras 3.7.0 is affected by an unsafe archive extraction issue in the `get_file` function. When code uses `get_file` to download and extract a crafted tar archive, malicious archive entries can cause files to be written outside the intended extraction directory. This can allow arbitrary file creation or overwrite within the permissions of the user running the Python process. Impact depends on where the process runs and what that user can write: in developer workstations, notebooks, CI/CD jobs, or ML training environments, this may enable modification of configuration files, source files, cached packages, startup scripts, or other user-writable files.

Why it matters to the business

An attacker who can influence a URL, dataset, model artifact, or tar archive processed by affected Keras code may be able to place or overwrite files on systems running ML workflows. This can disrupt development or training pipelines, poison ML artifacts, tamper with application behavior, or create a foothold for later code execution if the written file is subsequently loaded or executed. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no reported mature public exploitation in the provided data, but it should still be addressed in ML, notebook, and CI/CD environments where external archives are commonly downloaded and extracted.

How an attack unfolds

An attacker prepares a tar archive containing file paths that escape the intended extraction directory, such as parent-directory traversal paths, absolute paths, or archive structures designed to cause writes to sensitive user-writable locations. The attacker then gets a vulnerable application, notebook, script, pipeline, or developer to call Keras `get_file` on that archive with extraction enabled. When Keras downloads and extracts the archive, it writes files to attacker-chosen locations allowed by the operating-system permissions of the running user. The attacker may use this to overwrite configuration files, inject files into project directories, alter Python or ML workflow behavior, or plant files that are executed later by another process.

How to fix it

Upgrade Keras to a version that contains the vendor fix once available from the official Keras release channel. Because no fixed version was provided in the input, avoid relying on Keras 3.7.0 for downloading and extracting untrusted tar archives until the specific fixed release is confirmed. As immediate mitigations, do not pass attacker-controlled or externally supplied archives to `keras.utils.get_file` with extraction enabled; download artifacts from trusted, authenticated sources only; verify cryptographic hashes before use; extract archives with a safe extraction routine that rejects absolute paths, parent-directory traversal, symlinks, hardlinks, and paths resolving outside the destination directory; run ML download and extraction jobs as low-privilege users inside disposable containers or sandboxes; and restrict write permissions to sensitive directories.

How to confirm the fix worked

Confirm installed Keras versions across workstations, notebooks, containers, CI/CD runners, and ML platforms using package inventory tools such as `pip show keras`, `pip freeze`, software composition analysis, or container image scans. Treat Keras 3.7.0 as affected. Review application and notebook code for `keras.utils.get_file`, `keras.utils.file_utils.get_file`, or similar calls that download tar archives with extraction enabled. Validate the fix by confirming the runtime uses a non-affected Keras release once identified by the vendor, and by testing that crafted tar archives containing `../`, absolute paths, symlinks, or hardlinks cannot create files outside the intended extraction directory. Also confirm download locations are pinned to trusted sources and hash verification is enforced where supported.

Typical attack path

1. Identify a target workflow using Keras 3.7.0 and `get_file` to download and extract tar archives.
2. Host or supply a malicious tar archive through a URL, dataset reference, model package, dependency, tutorial, or configuration value consumed by the workflow.
3. Craft archive member names or archive metadata so extraction writes files outside the intended destination directory.
4. Trigger the vulnerable workflow to download and extract the archive.
5. Use the resulting arbitrary file write to modify user-writable files, poison project artifacts, alter configuration, or stage follow-on execution when the written file is later loaded or run.

How to detect it

There are no universal exploitation indicators for this vulnerability because successful exploitation results in attacker-chosen file writes whose names and locations depend on the crafted archive and the permissions of the affected process. To investigate possible prior exploitation, review package inventories for Keras 3.7.0 and correlate with executions of notebooks, scripts, CI/CD jobs, or ML pipelines that used Keras `get_file` to download tar archives from external or untrusted URLs. Examine application logs, notebook outputs, shell histories, CI/CD logs, proxy logs, and artifact repository access logs for unexpected archive downloads followed by file creation outside expected Keras cache, dataset, or extraction directories. On endpoints and containers, review file-system timeline data for unusual writes near the time of Keras archive downloads, especially modifications to project source trees, Python startup or site-package paths, shell startup files, credential/configuration files, scheduled task locations, and CI workspace files. If archive samples are available, inspect tar member names for parent-directory traversal, absolute paths, symlinks, hardlinks, or entries resolving outside the intended extraction root. Also review outbound and inbound network logs for downloads of unfamiliar tar archives referenced by ML code, notebooks, tutorials, or configuration files.

What your security team should do

• Inventory all use of Keras 3.7.0, prioritizing internet-connected notebooks, CI/CD pipelines, ML training jobs, and systems that process externally supplied datasets or model artifacts.
• Identify code paths using `get_file` to download and extract tar archives; disable automatic extraction or replace it with a safe extraction implementation for untrusted inputs.
• Restrict artifact sources to trusted repositories and require checksum or signature verification before extraction.
• Run ML artifact download and extraction workflows in least-privileged, isolated containers with read-only mounts where practical.
• Monitor vendor advisories and upgrade Keras as soon as a confirmed fixed version is available; rebuild affected container images and notebook environments after upgrading.
• Review recent ML pipeline, notebook, and developer activity for unexpected files written outside expected cache or extraction directories.
• Because there is no KEV listing, no ransomware association, low EPSS, and no mature exploit signal in the provided data, prioritize remediation based on exposure to untrusted archives rather than treating it as an active mass-exploitation emergency.