CVE-2025-54412
BaseFortify
Publication date: 2025-07-26
Last updated on: 2025-07-29
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| skops | skops | * |
| skops | skops | 0.11.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-351 | The product does not properly distinguish between different types of elements in a way that leads to insecure behavior. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the skops Python library (versions 0.11.0 and below) in the OperatorFuncNode class. It involves an inconsistency in trusted type validation where the system checks a combination of module and class names to verify trust, but actually calls methods based only on the class name. An attacker can craft a malicious model schema that appears to call a safe method but actually invokes dangerous operator methods like operator.call. This allows the attacker to hide execution of untrusted operator methods and perform a code reuse attack, ultimately leading to arbitrary code execution with minimal user suspicion. [1]
How can this vulnerability impact me? :
This vulnerability can lead to arbitrary code execution during the loading of a skops model. An attacker can embed malicious code inside a seemingly benign model file, which when loaded, can execute commands such as spawning a shell or running arbitrary system commands. This poses a severe risk to confidentiality, integrity, and availability of the affected system, especially in environments where models are shared or loaded from untrusted sources. The attack requires local access and user interaction to confirm loading the model, but no special privileges are needed. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection involves inspecting skops model files for suspicious OperatorFuncNode usage, especially looking for mismatches between the declared trusted types and the actual operator methods invoked. One approach is to analyze the model's schema.json inside the model zip file to check if the __class__ key is set to dangerous operator methods like 'call' while the __module__ key appears benign. Commands to inspect the model file could include: 1) unzip the model file and examine schema.json: `unzip -p my-model.skops schema.json | jq '.'` 2) Search for suspicious operator calls in the model: `unzip -p my-model.skops schema.json | grep '"__class__": "call"'` 3) Use Python scripts to load and verify trusted types carefully, ensuring that the actual operator methods invoked match the trusted types declared. Since the vulnerability exploits a mismatch in trusted type validation, manual or scripted inspection of model files for these inconsistencies is recommended. [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the skops Python library to version 0.12.0 or later, where this vulnerability is fixed. Avoid loading models created with vulnerable versions (0.11.0 and below) from untrusted sources. Additionally, do not confirm or accept loading models unless their origin and contents are fully trusted. If upgrading is not immediately possible, manually inspect model files for suspicious OperatorFuncNode usage as described above and restrict usage accordingly. [1]