Keras CVE-2025-12058

Exploitation requires a victim to load an attacker-controlled .keras archive via Keras's load_model (or saving.load_model) where the embedded StringLookup layer's 'vocabulary' argument is set to a local filesystem path or a remote URI handled by tf.io.gfile (e.g. file paths, GCS, HDFS, or HTTP/HTTPS endpoints). Critically, the default mitigation safe_mode=True does NOT prevent this, so no non-default configuration is needed on the victim side. The primary limiting factor is the supply-chain/trust step: the attacker must get the target to load an untrusted model file; impact is bounded to arbitrary local file read (incorporated into model state) and SSRF to endpoints reachable from the host - it is not remote code execution. SSRF reach additionally depends on the host having the relevant network access and gfile handlers (GCS/HDFS/HTTP) available.

This is a moderate-severity deserialization-class flaw (CWE-502) in Keras model loading, scored CVSS 4.0 5.9 by the reporter. The supplied CVSS 4.0 vector (AV:A/AC:H/AT:P/PR:L/UI:P) paints a fairly constrained picture - adjacent network, high complexity, a specific attack requirement, low privileges and passive user interaction - which pulls the score down despite the high confidentiality impact (VC:H, SC:H). No EPSS score, KEV listing, or public POC was provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the risk is primarily latent rather than imminent. The most important signal lives in the description rather than the metrics: the mitigation users rely on (safe_mode=True) does NOT block this path, so environments that believed they were protected are not. I disagree with the reporter's AV:A/AC:H framing - malicious .keras files are typically distributed over the network (model hubs, downloads, shared artifacts) and loaded without special conditions, so I assess this closer to AV:N/AC:L with UI:R; the realistic limiter is that a victim must load an attacker-supplied model, not network adjacency. Bottom line: a real but non-emergency priority - patch promptly because a trusted default mitigation is bypassed, but the absence of KEV/POC/EPSS suggests no widespread exploitation yet.

An attacker publishes a trojanized .keras model (e.g. on a public model hub, or sends it directly to an ML engineer) whose StringLookup layer sets its vocabulary to a sensitive local path such as /etc/passwd or to an internal URL. When a victim loads it with keras.models.load_model - even with the default safe_mode=True - Keras reads that file (retrievable via get_vocabulary()) or fetches that endpoint via tf.io.gfile, yielding local file disclosure or attacker-directed internal requests (SSRF). No public exploit code was provided, but the linked GHSA advisory and PR #21751 test cases effectively demonstrate the mechanism.