VAITP

A vulnerability in the SageMaker Workflow component of aws/sagemaker-python-sdk allows for the possibility of MD5 hash collisions in all versions. This can lead to workflows being inadvertently replaced due to the reuse of results from different configurations that produce the same MD5 hash. This issue can cause integrity problems within the pipeline, potentially leading to erroneous processing outcomes.

Jinja is an extensible templating engine. Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

Post-Quantum Secure Feldman's Verifiable Secret Sharing provides a Python implementation of Feldman's Verifiable Secret Sharing (VSS) scheme. In versions 0.7.6b0 and prior, the `secure_redundant_execution` function in feldman_vss.py attempts to mitigate fault injection attacks by executing a function multiple times and comparing results. However, several critical weaknesses exist. Python's execution environment cannot guarantee true isolation between redundant executions, the constant-time comparison implementation in Python is subject to timing variations, the randomized execution order and timing provide insufficient protection against sophisticated fault attacks, and the error handling may leak timing information about partial execution results. These limitations make the protection ineffective against targeted fault injection attacks, especially from attackers with physical access to the hardware. A successful fault injection attack could allow an attacker to bypass the redundancy check mechanisms, extract secret polynomial coefficients during share generation or verification, force the acceptance of invalid shares during verification, and/or manipulate the commitment verification process to accept fraudulent commitments. This undermines the core security guarantees of the Verifiable Secret Sharing scheme. As of time of publication, no patched versions of Post-Quantum Secure Feldman's Verifiable Secret Sharing exist, but other mitigations are available. Long-term remediation requires reimplementing the security-critical functions in a lower-level language like Rust. Short-term mitigations include deploying the software in environments with physical security controls, increasing the redundancy count (from 5 to a higher number) by modifying the source code, adding external verification of cryptographic operations when possible, considering using hardware security modules (HSMs) for key operations.

Post-Quantum Secure Feldman's Verifiable Secret Sharing provides a Python implementation of Feldman's Verifiable Secret Sharing (VSS) scheme. In versions 0.7.6b0 and prior, the `feldman_vss` library contains timing side-channel vulnerabilities in its matrix operations, specifically within the `_find_secure_pivot` function and potentially other parts of `_secure_matrix_solve`. These vulnerabilities are due to Python's execution model, which does not guarantee constant-time execution. An attacker with the ability to measure the execution time of these functions (e.g., through repeated calls with carefully crafted inputs) could potentially recover secret information used in the Verifiable Secret Sharing (VSS) scheme. The `_find_secure_pivot` function, used during Gaussian elimination in `_secure_matrix_solve`, attempts to find a non-zero pivot element. However, the conditional statement `if matrix[row][col] != 0 and row_random < min_value:` has execution time that depends on the value of `matrix[row][col]`. This timing difference can be exploited by an attacker. The `constant_time_compare` function in this file also does not provide a constant-time guarantee. The Python implementation of matrix operations in the _find_secure_pivot and _secure_matrix_solve functions cannot guarantee constant-time execution, potentially leaking information about secret polynomial coefficients. An attacker with the ability to make precise timing measurements of these operations could potentially extract secret information through statistical analysis of execution times, though practical exploitation would require significant expertise and controlled execution environments. Successful exploitation of these timing side-channels could allow an attacker to recover secret keys or other sensitive information protected by the VSS scheme. This could lead to a complete compromise of the shared secret. As of time of publication, no patched versions of Post-Quantum Secure Feldman's Verifiable Secret Sharing exist, but other mitigations are available. As acknowledged in the library's documentation, these vulnerabilities cannot be adequately addressed in pure Python. In the short term, consider using this library only in environments where timing measurements by attackers are infeasible. In the medium term, implement your own wrappers around critical operations using constant-time libraries in languages like Rust, Go, or C. In the long term, wait for the planned Rust implementation mentioned in the library documentation that will properly address these issues.

A vulnerability, that could result in Remote Code Execution (RCE), has been found in PlotAI. Lack of validation of LLM-generated output allows attacker to execute arbitrary Python code. Vendor commented out vulnerable line, further usage of the software requires uncommenting it and thus accepting the risk. The vendor does not plan to release a patch to fix this vulnerability.

The Keras Model.load_model function permits arbitrary code execution, even with safe_mode=True, through a manually constructed, malicious .keras archive. By altering the config.json file within the archive, an attacker can specify arbitrary Python modules and functions, along with their arguments, to be loaded and executed during model loading.

Versions of the package ray before 2.43.0 are vulnerable to Insertion of Sensitive Information into Log File where the redis password is being logged in the standard logging. If the redis password is passed as an argument, it will be logged and could potentially leak the password. This is only exploitable if: 1) Logging is enabled; 2) Redis is using password authentication; 3) Those logs are accessible to an attacker, who can reach that redis instance. **Note:** It is recommended that anyone who is running in this configuration should update to the latest version of Ray, then rotate their redis password.

A maliciously crafted QPY file can potential execute arbitrary-code embedded in the payload without privilege escalation when deserialising QPY formats < 13. A python process calling Qiskit 0.18.0 through 1.4.1's `qiskit.qpy.load()` function could potentially execute any arbitrary Python code embedded in the correct place in the binary file as part of specially constructed payload.

Python JSON Logger is a JSON Formatter for Python Logging. Between 30 December 2024 and 4 March 2025 Python JSON Logger was vulnerable to RCE through a missing dependency. This occurred because msgspec-python313-pre was deleted by the owner leaving the name open to being claimed by a third party. If the package was claimed, it would allow them RCE on any Python JSON Logger user who installed the development dependencies on Python 3.13 (e.g. pip install python-json-logger[dev]). This issue has been resolved with 3.3.0.

Spotipy is a lightweight Python library for the Spotify Web API. The `CacheHandler` class creates a cache file to store the auth token. Prior to version 2.25.1, the file created has `rw-r--r--` (644) permissions by default, when it could be locked down to `rw-------` (600) permissions. This leads to overly broad exposure of the spotify auth token. If this token can be read by an attacker (another user on the machine, or a process running as another user), it can be used to perform administrative actions on the Spotify account, depending on the scope granted to the token. Version 2.25.1 tightens the cache file permissions.