Skip to content

Update gitpython version - #70265

Open
dwoz wants to merge 1 commit into
saltstack:3008.xfrom
dwoz:dwoz/security/gitpython-cve-2026-78676-3008.x
Open

Update gitpython version#70265
dwoz wants to merge 1 commit into
saltstack:3008.xfrom
dwoz:dwoz/security/gitpython-cve-2026-78676-3008.x

Conversation

@dwoz

@dwoz dwoz commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

CVE-2026-78676

Six requirements/static/ci/py3.*/lint.lock files still pinned gitpython==3.1.50, which is in the vulnerable range for CVE-2026-78676 (GHSA-284h-m62q-gf8w): GitPython re-serialization corrupts a dormant multi-line quoted config value into an executable directive (e.g. core.hooksPath), enabling RCE via crafted config files. Lint environments installed from these locks, so this was a live (though limited-blast-radius) exposure. The runtime lock files ({cloud,darwin,docs,freebsd,linux,windows}.lock) and the base pin were already at >=3.1.60 / ==3.1.60 and unaffected.

Bump the six lint locks to ==3.1.60 to match the rest of the lock chain. Also align the two CI-static lower bounds requirements/static/ci/{common,darwin}.txt from >=3.1.50 to >=3.1.59 so any subsequent pip-compile can't drift a lock back into the vulnerable range.

…for CVE-2026-78676

Six ``requirements/static/ci/py3.*/lint.lock`` files still pinned
``gitpython==3.1.50``, which is in the vulnerable range for
CVE-2026-78676 (GHSA-284h-m62q-gf8w): GitPython re-serialization
corrupts a dormant multi-line quoted config value into an executable
directive (e.g. ``core.hooksPath``), enabling RCE via crafted config
files.  Lint environments installed from these locks, so this was a
live (though limited-blast-radius) exposure.  The runtime lock files
(``{cloud,darwin,docs,freebsd,linux,windows}.lock``) and the base
pin were already at ``>=3.1.60`` / ``==3.1.60`` and unaffected.

Bump the six lint locks to ``==3.1.60`` to match the rest of the
lock chain.  Also align the two CI-static lower bounds
``requirements/static/ci/{common,darwin}.txt`` from ``>=3.1.50`` to
``>=3.1.59`` so any subsequent pip-compile can't drift a lock back
into the vulnerable range.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

test:full Run the full test suite

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants