https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 15:18:08 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-248511 EUVD-2026-248511 https://cve.radiocsirt.org/vuln/euvd-2026-248511 https://cve.radiocsirt.org/vuln/fkie_cve-2025-54412 <p>skops is a Python library which helps users share and ship their scikit-learn based models. Versions 0.11.0 and below contain a inconsistency in the OperatorFuncNode which can be exploited to hide the execution of untrusted operator methods. This can then be used in a code reuse attack to invoke seemingly safe functions and escalate to arbitrary code execution with minimal and misleading trusted types. This is fixed in version 0.12.0.</p> <p>skops is a Python library which helps users share and ship their scikit-learn based models. Versions 0.11.0 and below contain a inconsistency in the OperatorFuncNode which can be exploited to hide the execution of untrusted operator methods. This can then be used in a code reuse attack to invoke seemingly safe functions and escalate to arbitrary code execution with minimal and misleading trusted types. This is fixed in version 0.12.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-54412 https://cve.radiocsirt.org/vuln/ghsa-m7f4-hrc6-fwg3 <p><strong>Affected:</strong> PyPI: skops</p> <p>## Summary An inconsistency in `OperatorFuncNode` can be exploited to hide the execution of untrusted `operator.xxx` methods. This can then be used in a code reuse attack to invoke seemingly safe functions and escalate to arbitrary code execution with minimal and misleading trusted types.</p> <p>**Note:** This report focuses on `operator.call` as it appears to be the most interesting target, but the same technique applies to other `operator` methods. Moreover, focusing on a specific example is not necessary, the `operator.call` invocation was a zero-effort choice meant solely to demonstrate the issue. The key point is the **inconsistency** that allows a user to approve a type as trusted, while in reality enabling the execution of `operator.xxx`.</p> <p>## Details</p> <p>The `OperatorFuncNode` allows calling methods belonging to the `operator` module and included in a trusted list of methods. However, what is returned by `get_untrusted_types` and checked during the `load` call is not exactly the same as what is actually called. Instead, it is something partially controlled by the model author. This means that the user checking the untrusted types can be tricked into thinking something benign is being used, while in reality the `operator.xxx` method is executed.</p> <p>Let’s look at the implementation of the `OperatorFuncNode`:</p> <p>```python # from io/_general.py:618-633 class OperatorFuncNode(Node): def __init__( self, state: dict[str, Any], load_context: LoadContext,…</p> <p><strong>Affected:</strong> PyPI: skops</p> <p>## Summary An inconsistency in `OperatorFuncNode` can be exploited to hide the execution of untrusted `operator.xxx` methods. This can then be used in a code reuse attack to invoke seemingly safe functions and escalate to arbitrary code execution with minimal and misleading trusted types.</p> <p>**Note:** This report focuses on `operator.call` as it appears to be the most interesting target, but the same technique applies to other `operator` methods. Moreover, focusing on a specific example is not necessary, the `operator.call` invocation was a zero-effort choice meant solely to demonstrate the issue. The key point is the **inconsistency** that allows a user to approve a type as trusted, while in reality enabling the execution of `operator.xxx`.</p> <p>## Details</p> <p>The `OperatorFuncNode` allows calling methods belonging to the `operator` module and included in a trusted list of methods. However, what is returned by `get_untrusted_types` and checked during the `load` call is not exactly the same as what is actually called. Instead, it is something partially controlled by the model author. This means that the user checking the untrusted types can be tricked into thinking something benign is being used, while in reality the `operator.xxx` method is executed.</p> <p>Let’s look at the implementation of the `OperatorFuncNode`:</p> <p>```python # from io/_general.py:618-633 class OperatorFuncNode(Node): def __init__( self, state: dict[str, Any], load_context: LoadContext,…</p> https://cve.radiocsirt.org/vuln/ghsa-m7f4-hrc6-fwg3 https://cve.radiocsirt.org/vuln/pysec-2026-1927 <p><strong>Affected:</strong> PyPI: skops</p> <p>## Summary An inconsistency in `OperatorFuncNode` can be exploited to hide the execution of untrusted `operator.xxx` methods. This can then be used in a code reuse attack to invoke seemingly safe functions and escalate to arbitrary code execution with minimal and misleading trusted types.</p> <p>**Note:** This report focuses on `operator.call` as it appears to be the most interesting target, but the same technique applies to other `operator` methods. Moreover, focusing on a specific example is not necessary, the `operator.call` invocation was a zero-effort choice meant solely to demonstrate the issue. The key point is the **inconsistency** that allows a user to approve a type as trusted, while in reality enabling the execution of `operator.xxx`.</p> <p>## Details</p> <p>The `OperatorFuncNode` allows calling methods belonging to the `operator` module and included in a trusted list of methods. However, what is returned by `get_untrusted_types` and checked during the `load` call is not exactly the same as what is actually called. Instead, it is something partially controlled by the model author. This means that the user checking the untrusted types can be tricked into thinking something benign is being used, while in reality the `operator.xxx` method is executed.</p> <p>Let’s look at the implementation of the `OperatorFuncNode`:</p> <p>```python # from io/_general.py:618-633 class OperatorFuncNode(Node): def __init__( self, state: dict[str, Any], load_context: LoadContext,…</p> <p><strong>Affected:</strong> PyPI: skops</p> <p>## Summary An inconsistency in `OperatorFuncNode` can be exploited to hide the execution of untrusted `operator.xxx` methods. This can then be used in a code reuse attack to invoke seemingly safe functions and escalate to arbitrary code execution with minimal and misleading trusted types.</p> <p>**Note:** This report focuses on `operator.call` as it appears to be the most interesting target, but the same technique applies to other `operator` methods. Moreover, focusing on a specific example is not necessary, the `operator.call` invocation was a zero-effort choice meant solely to demonstrate the issue. The key point is the **inconsistency** that allows a user to approve a type as trusted, while in reality enabling the execution of `operator.xxx`.</p> <p>## Details</p> <p>The `OperatorFuncNode` allows calling methods belonging to the `operator` module and included in a trusted list of methods. However, what is returned by `get_untrusted_types` and checked during the `load` call is not exactly the same as what is actually called. Instead, it is something partially controlled by the model author. This means that the user checking the untrusted types can be tricked into thinking something benign is being used, while in reality the `operator.xxx` method is executed.</p> <p>Let’s look at the implementation of the `OperatorFuncNode`:</p> <p>```python # from io/_general.py:618-633 class OperatorFuncNode(Node): def __init__( self, state: dict[str, Any], load_context: LoadContext,…</p> https://cve.radiocsirt.org/vuln/pysec-2026-1927