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.
jupyterlab-git 0.53.0 (latest, 2026-04-30) uses fnmatch.fnmatchcase() in GitHandler.prepare() (jupyterlabgit/handlers.py:91) to enforce the admin-configured excludedpaths security control. Because fnmatchcase is unconditionally case-sensitive, an authenticated user on a case-insensitive filesystem (macOS APFS, Windows NTFS) can bypass the exclusion by varying the case of the URL path segment — e.g. requesting /git/project/Secrets/... instead of /git/project/secrets/... — gaining read access to git history, file content, and status in directories the administrator explicitly excluded. Vulnerable Code Root Cause fnmatch.fnmatchcase() is unconditionally case-sensitive regardless of the operating system. Contrast with fnmatch.fnmatch() which normalizes via os.path.normcase() on case-insensitive platforms. On macOS APFS and Windows NTFS, /project/Secrets and /project/secrets resolve to the same directory on disk. The exclusion check rejects only the exact-case match, but the…
Recommended action: Upgrade to 0.54.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Amazon Web Services (AWS) Security has identified a stored cross-site scripting (XSS) issue in the jupyterlab-git JupyterLab extension that can lead to remote code execution (RCE). The issue exists in the PlainTextDiff.ts component, where the createHeader() method passes Git filenames directly to innerHTML without sanitization when rendering diffs for renamed files in commit history. This allows an adversary to craft a filename containing arbitrary HTML/JavaScript that executes when another user views the rename diff in the Git History tab. The issue can be leveraged through the rename history view in the JupyterLab Git panel. An adversary creates a file with a crafted filename containing a JavaScript payload (e.g., .py), renames the file in a subsequent commit, and pushes to a shared repository. When a victim clones the repository, navigates to the Git History tab, clicks the rename commit, and then clicks the renamed file to view the diff, the unsanitized filename renders…
Recommended action: Upgrade to 0.54.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On many platforms, a third party can create a Git repository under a name that includes a shell command substitution [^1] string in the syntax $(<command). These directory names are allowed in macOS and a majority of Linux distributions [^2]. If a user starts jupyter-lab in a parent directory of this inappropriately-named Git repository, opens it, and clicks "Git Open Git Repository in Terminal" from the menu bar, then the injected command <command is run in the user's shell without the user's permission. This issue is occurring because when that menu entry is clicked, jupyterlab-git opens the terminal and runs cd <git-repo-path through the shell to set the current directory [^3]. Doing so runs any command substitution strings present in the directory name, which leads to the command injection issue described here. A previous patch provided an incomplete fix [^4]. [^1]: https://www.gnu.org/software/bash/manual/htmlnode/Command-Substitution.html [^2]:…
Recommended action: Upgrade to 0.51.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.