Datasets through 5.0.0, fixed in commit f989ef9, contains a path traversal vulnerability in folder-based dataset builders where the file_name metadata field is not properly validated before being joined to the dataset directory. Attackers can supply crafted file_name values with directory traversal sequences to read arbitrary local files, which are then embedded into output when save_to_disk or push_to_hub is called.
The govapkg package version 0.1.0 on PyPI contains malicious code that silently downloads and executes a remote executable. This executable establishes persistence by disguising itself as a system service and connects to a telegra.ph URL that advertises a Telegram channel. The package's behavior is clearly malicious, involving hidden actions within the library usage and persistence mechanisms.
JupyterLab versions from 3.3.0 up to but not including 4.5.10, and from 4.6.0 up to but not including 4.6.2, contain a cross-site scripting (XSS) vulnerability via crafted overrides.json settings files. This vulnerability arises because certain settings are not properly validated before being inserted into style content, allowing malicious code execution when a user imports a crafted settings file or when an attacker plants such a file in a shared location. The embedded code executes with the affected user's privileges and can read or modify notebooks, files, and execute code on the notebook server and connected kernels. The issue is fixed in versions 4.5.10 and 4.6.2.
JupyterLab versions prior to 4.5.10 and 4.6.2 contain a cross-site scripting (XSS) vulnerability in the ImageViewer component. The issue arises because the ImageViewer uses URL.createObjectURL for specially crafted SVG images and revokes the blob URL too early. This allows the image to retain an executable same-origin context when opened in the image viewer and then in a new browser tab. This vulnerability can lead to arbitrary code execution on the JupyterLab server. The vulnerability is fixed in versions 4.5.10 and 4.6.2.
JupyterLab versions from 4.5.0 up to but not including 4.5.10, and from 4.6.0 up to but not including 4.6.2, contain a vulnerability in the PyPI extension manager. The blocklist enforcement uses a weaker normalization method than PyPI's canonical package-name normalization, allowing an authenticated user to bypass the blocklist by requesting an equivalent package name variant. This lets the user install prohibited extensions, defeating integrity restrictions and potentially affecting availability without gaining additional read access. The issue is fixed in versions 4.5.10 and 4.6.2.
JupyterLab's plugin manager has a vulnerability that allows authenticated users to bypass administrator-imposed plugin lock rules via direct API requests. This bypass affects child plugins of multi-plugin extensions and scenarios where administrators issued a 'lock all' command. The flaw can undermine data integrity and circumvent restrictions implemented through locked plugins. Patches addressing this issue are available in JupyterLab versions 4.6.2 and 4.5.10. Users of dependent applications like Notebook v7+ should also update the jupyterlab package. As a workaround, administrators can manually lock all plugins that require restriction using documented plugin identifiers.
A missing await in JupyterLab's PyPIExtensionManager.install() method caused the allowlist/blocklist check to not be enforced for direct callers. This issue affects only custom extensions or downstream integrations that call install() directly with untrusted input and rely on this method to enforce package restrictions. The default JupyterLab HTTP API and UI are not affected as they perform their own awaited checks. The vulnerability is low severity and has been patched in JupyterLab versions 4.6.2 and 4.5.10.
The torch-musa package on PyPI contains malicious code that exfiltrates basic host information such as IP address and username during installation or import. The package overrides the install command in setup.py to execute this malicious behavior. It serves no legitimate purpose beyond this data exfiltration.
Migration Toolkit for Applications (MTA) accelerates large-scale application modernization efforts across hybrid cloud environments on Red Hat OpenShift.
This solution provides insight throughout the adoption process, at both the portfolio and application levels: inventory, assess, analyze, and manage
applications for faster migration to OpenShift via the user interface.
GitPython versions up to 3.1.50 (and before 3.1.52) contain a vulnerability where the Repo.clone_from() method passes the remote URL through os.path.expandvars() on non-Cygwin platforms. This causes environment variables embedded as $NAME or ${NAME} in the URL to be expanded using the server process's environment, potentially leaking secrets such as AWS keys or tokens to attacker-controlled hosts. The vulnerability arises because polish_url(), intended for local path normalization, is incorrectly applied to remote URLs without scheme checks or an opt-out for variable expansion. Additionally, the unsafe-protocol check is performed on the raw URL before expansion, allowing bypass if an attacker controls environment variables. No official patch or fix is currently documented.
GitPython versions prior to 3.1.51 contain multiple vulnerabilities due to insufficient validation of caller-supplied options in several public APIs. Specifically, `Repo.archive()` and `git.ls_remote()` allow arbitrary command execution by forwarding unsafe Git options without proper checks. Additionally, `Repo.iter_commits()` and `Repo.blame()` permit arbitrary file overwrite by placing unvalidated revision arguments before the end-of-options separator, enabling file truncation. These issues arise because the existing unsafe option checks are only applied to network commands and not extended to these other APIs.
GitPython contains a command injection vulnerability due to incomplete blocking of unsafe git options. The fix for CVE-2026-42215 implemented a blocklist for dangerous git options but did not account for git's acceptance of unambiguous long-option prefix abbreviations. This allows attackers to bypass the blocklist by using abbreviated option keys, leading to command injection when GitPython emits these options to git commands. The vulnerability affects all versions carrying the 3.1.47 blocklist fix through versions before 3.1.51. Exploitation requires a host application that passes attacker-controlled keyword argument keys to GitPython's clone, fetch, pull, or push methods. The severity is high, reflecting potential remote code execution impact.
GitPython version 3.1.50 contains a vulnerability where the default unsafe option gate intended to block dangerous git clone options does not recognize joined short-option forms such as '-u<value>'. This allows an attacker controlling clone options to bypass the safety check and execute local commands via Git's --upload-pack/-u option. The issue arises because the option canonicalization treats '-u<value>' as a different option name, allowing execution despite allow_unsafe_options being false. The vulnerability affects the PyPI package GitPython at version 3.1.50.
A vulnerability in pyasn1 versions prior to 0.6.4 allows uncontrolled resource consumption when converting decoded ASN.1 REAL values to Python floats. This occurs because the conversion uses exact big-integer exponentiation, which can cause excessive CPU and memory usage if the exponent is very large. Operations such as printing, logging, comparing, or arithmetic on these decoded REAL values from untrusted input can hang the process, resulting in a denial of service. The issue is fixed in pyasn1 version 0.6.4.
The roles-royce PyPI package version 2.1.1 contains malicious code that executes at import time. It runs a hidden routine that collects sensitive files such as SSH private keys, cloud credentials, wallet keystores, shell histories, and environment files from the user's system. The stolen data, along with environment variables and Kubernetes service account tokens, is compressed, encoded, and exfiltrated to two hardcoded IP addresses. This malicious behavior is disguised as a compatibility check and is unrelated to the package's advertised functionality as a Zodiac Roles transaction builder.
The PyPI package 'defi-kit' version 2.1.1 contains malicious code in its _compat.py module. When imported, it runs a function that stealthily collects sensitive credential files and environment data from the host, including SSH keys, cloud credentials, Kubernetes tokens, and various configuration files. This data is compressed, encoded, and exfiltrated to two hardcoded external IP addresses. The module disguises this behavior under misleading names suggesting compatibility or telemetry functionality.
The PyPI package 'automatic-octo-invention' versions 0.1.0 through 0.1.3 are identified as malicious. This package is part of a campaign that uses names similar to popular services to distribute cryptomining malware. The campaign is known as 2026-07-kimichat and is categorized as malicious software with clear intent to deploy cryptominers.
The PyPI package 'ml-core-airflow-auth' version 0.0.1 contains malicious code that downloads and executes remote executables using multiple fallback methods, including Cloudflare Workers and DNS TXT records. It uses a persistence mechanism via a .pth file to run on every Python start and attempts to exfiltrate basic system data such as IP address and username. The package also overrides the install command to execute malicious code during installation and covers its tracks by removing the downloaded binary after execution.
The telebot-bot-run package on PyPI versions 0.3, 0.4, and 0.5 contains malicious code that executes attacker-controlled scripts on the host system. Upon import, it fetches and executes remote Python code from a mutable Pastebin URL, runs a Telegram bot with hardcoded credentials that allows remote command execution, file exfiltration, directory archiving, and persistent background execution. The package is identified as typosquatting and is designed for remote access and control of infected hosts.
CVE-2026-12484 is a high-severity vulnerability in keras-team/keras version 3.15.0 that allows unsafe deserialization of attacker-controlled PyTorch pickle data via the public method keras.layers.TorchModuleWrapper.from_config. This method calls torch.load without requiring an explicit unsafe opt-in or enforcing safe deserialization, potentially leading to arbitrary code execution if untrusted Keras layer configurations are processed. The vulnerability exists because safe deserialization is only enforced when explicitly guarded by Keras safe mode, which is not the default behavior.