Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The Card class of skops, used for model documentation and sharing, allows arbitrary code execution. When a file other than .zip is provided to the Card class during instantiation, the internally invoked Card.getmodel method silently falls back to joblib without warning. Unlike the .skops zip-based format, joblib permits unrestricted code execution, hence bypassing the security measures of skops and enabling the execution of malicious code. Details The Card class supports loading the model linked to the card using the getmodel method. When a .skops model is provided, it uses the load function from skops, which includes security mechanisms. The Card class also supports consistent management of the trusted list, which can be passed during instance creation. As expected, if a .skops model is provided without a trusted list and an untrusted type is encountered during loading, an error is raised. This behavior is consistent with the security principles of skops. The problem arises…
Recommended action: Upgrade to 0.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An inconsistency in MethodNode can be exploited to access unexpected object fields through dot notation. This can be used to achieve arbitrary code execution at load time. While this issue may seem similar to https://github.com/skops-dev/skops/security/advisories/GHSA-m7f4-hrc6-fwg3, it is actually more severe, as it relies on fewer assumptions about trusted types. Details The MethodNode allows access to attributes of existing objects via dot notation. However, there are several critical shortcomings: Although the class and module fields are checked via getuntrustedtypes and during the load phase (as a concatenated string), they are not actually used by MethodNode. Instead, the func and obj entries in the schema.json are used to determine behavior. This means that even an apparently harmless module.class pair can lead to access of arbitrary attributes or methods of loaded objects, without any additional checks. Nothing prevents an attacker from chaining multiple MethodNode…
Recommended action: Upgrade to 0.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. 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. Details The OperatorFuncNode allows calling methods belonging to the operator module and included in a trusted list of methods. However, what is returned by getuntrustedtypes and checked during the load call is not exactly the same as what is actually called. Instead, it…
Recommended action: Upgrade to 0.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.