Attacker Impact
Keras versions 3.0.0 through 3.8.x are affected by CVE-2025-1550 / GHSA-48g7-3x6r-xfhp. When an application, worker, notebook, or training pipeline loads a crafted .keras model archive from an untrusted source, the affected runtime can execute attacker-controlled Python code in the loading process.
The practical impact depends on deployment context. A repository dependency match is most urgent when the project accepts uploaded models, pulls models from shared object storage, runs user-provided ML workflows, or loads third-party model artifacts inside a privileged runtime.
Root Cause
The issue is in Keras model deserialization for affected 3.x releases before 3.9.0. Loading a model is not just data parsing: Keras reconstructs model objects and configuration. The patched release tightens that loading boundary so crafted model configuration cannot bypass the intended safety controls.
Covered by FixVibe
FixVibe's GitHub repo scans flag Python dependency files that pin or allow Keras versions affected by CVE-2025-1550, linked to the advisory so you can prioritize the upgrade.
Remediation
Upgrade Keras to 3.9.0 or later in the dependency source that controls deployment, regenerate the active lockfile, and rebuild every runtime image, virtual environment, notebook kernel, worker, or API service that can load Keras model archives.
Review model-loading paths so they only load trusted, authenticated, or provenance-checked model artifacts. Treat user uploads, shared object storage, marketplace models, email attachments, and externally supplied model files as untrusted unless a separate trust and validation process exists. Verification should use dependency-tree checks and benign model-loading smoke tests, not exploit reproduction.