Two pinned dependencies carry published security advisories (gitpython, vtk)

[dustenhubbard]

Two pinned dependencies carry published security advisories. Scanning all resolved packages against OSV found vulnerabilities in exactly these two.

gitpython==3.1.50

Affected by nine HIGH advisories, all of them command-injection or argument-injection paths:

Advisory	Fixed in	Path
GHSA-v396-v7q4-x2qj	3.1.51	clone-option gate bypass via joined short options
GHSA-2f96-g7mh-g2hx	3.1.51	long-option prefix abbreviation bypass
GHSA-956x-8gvw-wg5v	3.1.51	unguarded options in Repo.archive(), git.ls_remote()
GHSA-rwj8-pgh3-r573	3.1.52	env-var exfiltration via expandvars() on Repo.clone_from()
GHSA-3rp5-jjmw-4wv2	3.1.53	git-config section-name injection reaching core.sshCommand
GHSA-6p8h-3wgx-97gf	3.1.54	unsafe_git_clone_options denylist omits --template
GHSA-fjr4-x663-mwxc	3.1.54	arbitrary file overwrite via git diff --output
GHSA-r9mr-m37c-5fr3	3.1.54	option-guard bypass via single-character kwarg token smuggling
GHSA-94p4-4cq8-9g67	3.1.55	env-var exfiltration via Repo.create_remote() / Remote.add()

Current release is 3.1.57.

vtk==9.4.2

Affected by CVE-2025-57106, CVE-2025-57107, and CVE-2025-57108: a buffer overflow, a heap buffer overflow, and a heap use-after-free, all three in vtkGLTFDocumentLoader. Fixed in 9.5.1. Current release is 9.5.2.

Reachability

Neither set looks reachable from the code as it stands, so this reads as hygiene rather than an incident:

• The only gitpython usage is PyReconstruct/modules/constants/repo_info.py, which calls git.Repo(repo_dir) and reads head.commit.hexsha and active_branch.name. It never clones, adds a remote, archives, diffs, blames, or writes config, which is where all nine advisories live.
• Nothing parses GLTF. The 3D scene builds meshes from in-memory arrays via vedo.Mesh([vertices, faces], ...), and exportScene only writes .obj. No VTK reader is instantiated.

The argument for bumping anyway is that the pins are what a scanner sees, and nine HIGH advisories on a requirements.txt is worth not carrying.

On upgrading

vedo declares an unbounded vtk dependency, so a 9.5.x bump does not conflict with it. vtk 9.5.2 ships cp311 wheels.

Why Dependabot catches one of these and not the other

Dependabot already reports the gitpython advisories, which is where the 18 alerts on the default branch come from. It reports nothing for vtk, and the reason is worth knowing rather than assuming the alerts are incomplete.

All three vtk CVEs do exist in GitHub's advisory database, as GHSA-5pfc-43r5-qrmg, GHSA-6hj2-fxwr-rvj5, and GHSA-9frg-3876-q98g. All three are unreviewed records with an empty package list: no ecosystem, no package name, no version range. Nothing connects them to the PyPI package vtk, so Dependabot has nothing to match a pin against and stays silent. GHSA-9frg-3876-q98g is rated critical.

A direct OSV query does match them, because OSV carries them as PYSEC-2025-224 through PYSEC-2025-226 with proper PyPI version ranges. That difference is the whole reason these turned up.

One practical note: pip-audit cannot scan this project as configured. It resolves against the default interpreter and PySide6==6.5.2 has no cp312 wheel, so it errors out before scanning anything. Querying OSV from an exported requirements list avoids the build step entirely.