You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Automated candidates via brew advisory-match --formula-list (planned workers) --new-history, sharded by formula (SHA-256 bucket 24). See CONTRIBUTING.md for the review checklist.
Partial daily run: successful buckets only; the older standing PR may overlap.
Updated affected-version and upstream evidence details across existing advisories for Paramiko, SQLAlchemy, GitPython and git-annex.
Added advisories for CVE-2026-112940 affecting Homebrew hf and rapid-mlx, with affected versions, impacts, conditions and workarounds.
Added fdroidserver advisories covering multiple GitPython security issues, with affected versions and supporting references.
Added advisories for rapid-mlx covering issues in pypdf and the MCP Python SDK, including affected versions, impacts and upstream fixes.
Added a vpn-slice advisory for excessive CPU use in dnspython DNS name decompression.
The pull request updates existing fdroidserver and git-annex advisory metadata. It changes one fdroidserver affected range to fixed and adds advisories for reported issues affecting fdroidserver, hf, rapid-mlx and vpn-slice.
Changes: Existing fdroidserver advisory updates
Layer / File(s)
Summary
Paramiko, SQLAlchemy and GitPython metadata advisories/BREW-fdroidserver-CVE-*.json
Existing advisories update affected-resource versions, matching upstream evidence and modified timestamps. Most changes update GitPython from 3.2.0 to 3.2.1; Paramiko and SQLAlchemy records also receive version updates.
Fixed affected range advisories/BREW-fdroidserver-CVE-2026-114145.json
The advisory records Homebrew version 2.4.5_7 as fixed and updates the GitPython resource and evidence to 3.2.1.
Existing git-annex advisory updates
Layer / File(s)
Summary
Hackage version evidence advisories/BREW-git-annex-*.json
The evidence records update from git-annex 10.20261020 to 10.20261026, with matching package keys and modified timestamps.
The advisory records the affected package range, dnspython evidence and fix version, and reported CPU use from crafted DNS messages.
Priority: Normal
Merge Risk: Moderate · up to 0faf3
Some new fdroidserver advisories flag Homebrew builds that bundle GitPython versions outside the upstream affected range, which could produce false vulnerability alerts for older versions. One severity vector may also describe a file-disclosure issue as an integrity issue. Correct the lower bounds, and confirm or correct the CVSS vector, before merging.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title clearly identifies the main change: matched advisory candidates generated for shard 24.
Description check
The description explains that the pull request contains automated advisory candidates generated by the matching command, identifies the shard, and provides review context and artefacts.
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.
set -o pipefail
printf'%s\n''--- boundary fixtures and comments ---'
nl -ba spec/advisory_records_spec.rb | sed -n '430,525p'printf'%s\n''--- override boundary fixtures ---'
nl -ba spec/overrides_spec.rb | sed -n '190,365p'printf'%s\n''--- advisory rederive implementation ---'
nl -ba lib/advisory_rederive.rb | sed -n '1,180p'printf'%s\n''--- reviewed advisory and history-related files ---'
git diff --stat f5f213fd71f52ab1b30a810cf36d42680fb494fe ef85490540c42485094ea475bcc741c88ee53a87 -- advisories/BREW-fdroidserver-CVE-2026-110860.json
git ls-tree -r --name-only ef85490540c42485094ea475bcc741c88ee53a87 | rg -i 'fdroid|formula|history|matched|brew'
Repository: Homebrew/advisory-database
Length of output: 45680
Web query:
Homebrew brew advisory-match introduced boundary formula history upstream affected range resource
Result:
<source_evidence>
<source kind="search">
<title>Homebrew Documentation: Advisory Matching</title>
<location>https://docs.brew.sh/Advisory-Matching</location>
<excerpt>citeturn0search0 [wordlim: 200] Crawled: 2 weeks ago; `brew advisory-match` prepares candidate records for the Homebrew advisory database. ... Before running this mode, protect hand-reviewed Homebrew boundaries with `preserve_homebrew_ranges: true` under the formula and advisory in `overrides.yml`.
Image: Homebrew Documentation logo
# Homebrew Documentation
# Advisory Matching
`brew advisory-match` prepares candidate records for the Homebrew advisory database. It is an authoring tool, not the installed-package scanner provided by `brew vulns`. Candidates still need human review before publication.
## Range accuracy and coverage
With history enabled, a candidate with a comparable current state and no reviewed range must have an affected interval that can be established from formula history. This applies even when the current formula is known to be affected: knowing today’s state does not establish when the affected range began. An `introduced: "0"` boundary asserts that every earlier version is affected; it is not a marker for an unknown introduction.
Automatic matching deliberately favours range accuracy over coverage. Unreadable or uncomparable history and disjoint affected intervals can prevent a new record from being emitted. The command warns and counts these as history-unavailable skips instead of inventing a boundary. This includes a historical subject whose prerelease suffix changes its `SEMVER` range state compared with its release version. A skip does not mean the formula is unaffected, so an ingest run can omit a currently affected formula and is not evidence of complete vulnerability coverage. Reviewers must establish the ranges and matching provenance together from upstream evidence and formula build history, then contribute the record manually.
For a new record, a `pkg_version` shared by affected and unaffected builds is conservatively included in the affected interval, because the advisory cannot distinguish those builds by version. This can happen when a resource changes without a formula revision bump. For the same reason, a fix that shares its `pkg_version` with affected builds is recorded at the next version with only fixed builds, and a range stays unchanged while the current version also has an affected build. A distinct unaffected version inside the interval still requires review. Existing-range reconciliation and reintroduction checks retain their stricter rules for mixed builds, so reconciliation reports a record whose `introduced` version has mixed builds as an unrepresentable interval and leaves it unchanged.
Current-version prerelease ambiguity produces an uncomparable review lead with no `range_state`, reduced confidence and `database_specific.review_reason: "prerelease_boundary"`. Ingest drops these leads and lists their IDs by reason in its run summary. An explicit `range_state` override for the formula and advisory resolves the current-state ambiguity; an `upstream_fixed_in` override alone does not. Without a reviewed state override, existing reviewed records stay unchanged.
A reviewed state override does not establish historical boundaries. When its state disagrees with comparable upstream evidence, or the upstream evidence cannot be checked, a new range needs manual review. Existing reviewed ranges are preserved rather than replaced with guessed introductions; range transitions and changed provenance still require their own checks.
## History options
`--new-history` requires `--output` and reuses existing reviewed ranges where possible; a successful replay does not independently verify those boundaries. `--json` without `--output` has no existing reviewed records to reuse, so history checks still apply to new comparable candidates. `--no-history` explicitly uses unverified zero/current-version boundaries for new ranges and cannot be combined with `--new-history`. It is an unchecked authoring mode, not a way to validate a skipped candidate.
## Reconciling existing ranges
`--reconcile-history --output advisories --overrides data/overrides.yml` explicitly revisits existing `source: matched`, bump-fixed records with one terminal interval. It requires complete formula history and matching provenance, with the same result on the latest supported macOS and Linux for both ARM and Intel. These simulations check declared formula and resource versions; they do not rebuild historical bottles or verify installation steps. It can narrow an affected interval or delete a record proven never affected; it preserves other fields and updates `modified` only for a range change. Generated records, patch fixes and open or multiple intervals are left unchanged. For records missed by current matching, complete registry-resource evidence can supply versionless upstream queries even after a resource has been removed. The fresh results must reproduce the stored upstream family and range basis, and every resource identity must occur in formula history on every platform. Stored subject versions only reproduce the range basis; historical decisions use versions from the formula sources. A missing historical resource holds the record as `resource_not_found`; a stored family absent from the fresh query results is `resource_not_rediscovered`. Mixed, incomplete or non-resource provenance still requires current discovery. These fallback queries cannot create records and respect formula skips and preserved Homebrew ranges. When a prerelease suffix changes a subject’s `SEMVER` range state compared with its release version, `prerelease_boundary` holds the record for review. The command reports skip reasons and the number of matched records it did not revisit; success does not establish complete coverage.
Before running this mode, protect hand-reviewed Homebrew boundaries with `preserve_homebrew_ranges: true` under the formula and advisory in `overrides.yml`. The pin applies across advisory aliases and is separate from `upstream_fixed_in`, which describes the upstream fix. Unavailable history or upstream records, changed subjects, conflicting platform results and advisory-specific patches require review. A failed upstream lookup holds every record for that formula with `upstream_unavailable`; a failed batch query holds its entire formula batch. A confirmed HTTP 404 while following an upstream link is cached as a missing target; a record with no resolved targets keeps its original evidence. A 404 for a supplemental CPANSA CVE lookup uses the CPANSA evidence for that CVE, including on subsequent platform passes. A 404 for an ID returned directly by a query still holds the formula, as do other request failures. Reconciliation continues with the remaining formulae, so a successful command can include these holds. Complete history includes earlier lifetimes of deleted and re-added formulae, skipping revisions where Git proves the formula path was absent. A rename into the current formula name starts that name’s history; the old formula name’s builds are excluded. Historical loading ignores obsolete `devel` blocks and uses the stable build. It also accepts legacy `sha1` and `md5` declarations, `bottle :unneeded` and `plist_options` without fetching or building historical sources. This compatibility applies to all `FormulaVersions` callers, including daily matching; ordinary current-formula loading is unchanged. Any remaining unreadable build still holds the record, even when it appears before or after the affected interval. A historical formula’s `odie` option check becomes a failed load rather than terminating the command. The reconciliation summary counts failed formula revisions and affected formulae separately from revision/platform failures and per-record hold reasons. Reason counts, such as `history_unavailable`, count held records and may overlap. With `--verbose`, each failed load includes its formula, revision, path, platform and original error, once per revision/path/platform for that formula. Proven absent paths are not load failures; failed Git absence checks remain failures. Unattributed patches and `inreplace` alone do not block reconciliation. This mode cannot be combined with `--new-history`, `--no-history`, `--json` or `--index` and does not enable reconciliation in ordinary ingest runs.
For bounded daily or reconciliation runs, `--formula-list=<file>` selects newline-separated core formula names instead of `--all` or named arguments. It requires `--new-history` or `--reconcile-history`, retains bulk queries and uses the Repology index without live per-formula fallbacks. Only listed names still present in core are loaded; removed names are reported and their records remain unchanged. An empty list performs no matching, and the unvisited-record summary is scoped to the list. The advisory database partitions these lists by formula so each execution shard can be saved and retried independently.</excerpt>
</source>
<source kind="search">
<title>advisory-database/CONTRIBUTING.md at main · Homebrew/advisory-database · GitHub</title>
<location>https://github.com/Homebrew/advisory-database/blob/main/CONTRIBUTING.md</location>
<excerpt>citeturn0search1 [wordlim: 200] Crawled: last month; Advisories in this repository come from three places: records generated from `resolves` annotations on `homebrew/core` formula patches, candidate records matched against external OSV feeds by `brew advisory-match`, and records contributed directly by pull request.
# CONTRIBUTING.md
Copy path
[Input: Go to file]
Blame More file actions
Blame More file actions
## Latest commit
## History
History
main
## Breadcrumbs
1. advisory-database
/
# CONTRIBUTING.md
Copy path
Top
## File metadata and controls
* Preview
* Code
* Blame
88 lines (59 loc) · 7.92 KB
# Contributing
Advisories in this repository come from three places: records generated from `resolves` annotations on `homebrew/core` formula patches, candidate records matched against external OSV feeds by `brew advisory-match`, and records contributed directly by pull request. All live under `advisories/` as OSV-schema JSON and are validated against that schema on every push.
The concatenated advisory index is built from the reviewed records on `main` and served at formulae.brew.sh/api/advisories.json.
## Reporting a fixed vulnerability
If a `homebrew/core` formula already ships a patch that fixes a CVE, the simplest route is to annotate the patch. Open a pull request against Homebrew/homebrew-core adding `resolves "CVE-YYYY-NNNNN"` to the relevant `patch do` block; see `libquicktime.rb` for an example. CVE identifiers appearing in the patch URL or applied file paths are picked up automatically without an explicit `resolves`. The daily `Regenerate` workflow will pick it up and write a `BREW-<formula>-<CVE>` record here automatically. Generated records carry `"database_specific": {"source": "generated"}`. The workflow refreshes their upstream-derived fields (`summary`, `severity`, `references`, `ecosystem_specific.patches`) on each run but preserves `published` and `affected[].ranges` from whatever is on disk, so a hand-corrected `fixed` boundary will not be overwritten.
## Contributing an advisory directly
Open a pull request adding a file under `advisories/` when you want to record something the generated path cannot express, most commonly that a formula version is affected and Homebrew has not yet applied a fix.
Before opening the PR, report the issue upstream according to the project's security policy and wait for it to be acknowledged. Versions are the formula version as `brew info` reports it, with an `_N` suffix when the revision is nonzero. Link the upstream CVE, GHSA or advisory in `upstream` and `references`.
## Reviewing matched candidates
Records with `"database_specific": {"source": "matched", ...}` are produced by `brew advisory-match` (in Homebrew/brew), which queries OSV.dev's GIT, language-registry and distro ecosystems plus CPANSA for a formula and emits one candidate per CVE reached. These arrive as automated PRs and need a human to confirm the match before merge.
`database_specific` tells you how the match was made:
* `strategy` is the highest-precision path that reached the CVE: `git` (the formula's forge repo), `registry` (a PyPI/npm/crates/... package derived from `stable.url` or a `resource`), `cpansa` (a CPAN distribution), or `distro` (a Debian/Ubuntu/... source package name mapped via Repology).
* `confidence` follows from strategy and whether a comparable version range was found: `high` for `git`/`registry` with a range, `medium` when no comparable range was found (typically GIT commit-SHA events), `low` for `distro`.
* `upstream_evidence` lists every path that reached the CVE, each with the `{ecosystem, name, subject_version}` that was queried.
`affected[0].ecosystem_specific` tells you what the range check concluded:
* `range_state` is `affected` (the shipped version is inside an upstream affected range), `fixed` (past one), or absent (no comparable range; the reviewer sets the boundary).
* `upstream_fixed_in` is the upstream version the matched range says fixes it.
* `resource` and `resource_purl` are set when the affected subject is a vendored `resource` block rather than the formula's primary source.
* `"fix": "bump"` and a `fixed` event in `ranges` are only present when `range_state` is `"fixed"`.
Before merging, check:
* The `upstream_evidence` keys point at this formula's actual upstream. A `distro`-only hit can reach a CVE for an unrelated package that shares a Repology project (for example a `wget2` CVE surfaced against `wget`); close those.
* The CVE is not a distro-specific patch. Open https://osv.dev/vulnerability/CVE-YYYY-NNNNN and confirm the affected package and description match the upstream project, not a distribution's packaging of it.
* If `range_state` is `"fixed"`, the `fixed` boundary in `ranges` is the `pkg_version` at which Homebrew first shipped the fix. `brew advisory-match` derives this by walking `homebrew-core` history; spot-check it against `git log -p -- Formula/<letter>/<name>.rb` in a `homebrew-core` checkout and correct it in the PR if wrong. The corrected value is preserved on subsequent regenerations.
* If `range_state` is `"affected"` with a `resource`, `brew info <formula> --json=v2 | jq '.formulae[0].resources[] | select(.name == "<resource>") | .version'` confirms the pinned resource version is below `upstream_fixed_in`. Known false-positive sources are stale CPANSA ranges and OSV records where one alias (often a PYSEC id) has an open-ended range while another has a bounded one.
* If `range_state` is absent and `confidence` is `medium` or `low`, the record is a lead rather than a determination: either set the `ranges` boundary yourself from the upstream advisory and `homebrew-core` history, or close if the CVE does not apply.
The Ingest workflow currently discards uncomparable candidates (`range_state` absent) instead of proposing them for review: their raw OSV shape (`{"introduced": "0"}` with no `fixed`) reads as every version being affected. To reject a candidate durably, add its id to `data/rejected-candidates.txt` — matching re-runs from scratch daily, so closing a PR only postpones it — and if the record was already merged, delete its file in the same change.
Do not merge a `matched` record over an existing `source: "generated"` record for the same `(formula, CVE)`; the generated record already states Homebrew ships a patch and takes precedence. `brew advisory-match --output` skips these automatically.
## Scope
Records here describe vulnerabilities in software Homebrew distributes, scoped to the Homebrew formula name and version. They are not a substitute for the upstream project's own advisory; the purpose is to let tools that read `pkg:brew` purls or `Homebrew` OSV queries answer "is this installed formula affected". Casks are out of scope for now.
## Development
The required Ruby version is recorded in `.ruby-version`. Install the development dependencies and run the same Ruby checks as CI with:
bundle install
bundle exec rake
Workflow changes should also pass Homebrew's standard workflow checks:
brew install actionlint shellcheck zizmor
actionlint
zizmor .
## Code of Conduct
This project follows the Homebrew Code of Conduct.
You can’t perform that action at this time.</excerpt>
</source>
<source kind="search">
<title>Homebrew Documentation: Advisory Matching</title>
<location>https://docs.brew.sh/Advisory-Matching</location>
<excerpt>citeturn1search0 [wordlim: 200] Crawled: 2 weeks ago; `brew advisory-match` prepares candidate records for the Homebrew advisory database. ... An `introduced: "0"` boundary asserts that every earlier version is affected; it is not a marker for an unknown introduction. ... For records missed by current matching, complete registry-resource evidence can supply versionless upstream queries even after a resource has been removed. ... The pin applies across advisory aliases and is separate from `upstream_fixed_in`, which describes the upstream fix.
Image: Homebrew Documentation logo
# Homebrew Documentation
# Advisory Matching
`brew advisory-match` prepares candidate records for the Homebrew advisory database. It is an authoring tool, not the installed-package scanner provided by `brew vulns`. Candidates still need human review before publication.
## Range accuracy and coverage
With history enabled, a candidate with a comparable current state and no reviewed range must have an affected interval that can be established from formula history. This applies even when the current formula is known to be affected: knowing today’s state does not establish when the affected range began. An `introduced: "0"` boundary asserts that every earlier version is affected; it is not a marker for an unknown introduction.
Automatic matching deliberately favours range accuracy over coverage. Unreadable or uncomparable history and disjoint affected intervals can prevent a new record from being emitted. The command warns and counts these as history-unavailable skips instead of inventing a boundary. This includes a historical subject whose prerelease suffix changes its `SEMVER` range state compared with its release version. A skip does not mean the formula is unaffected, so an ingest run can omit a currently affected formula and is not evidence of complete vulnerability coverage. Reviewers must establish the ranges and matching provenance together from upstream evidence and formula build history, then contribute the record manually.
For a new record, a `pkg_version` shared by affected and unaffected builds is conservatively included in the affected interval, because the advisory cannot distinguish those builds by version. This can happen when a resource changes without a formula revision bump. For the same reason, a fix that shares its `pkg_version` with affected builds is recorded at the next version with only fixed builds, and a range stays unchanged while the current version also has an affected build. A distinct unaffected version inside the interval still requires review. Existing-range reconciliation and reintroduction checks retain their stricter rules for mixed builds, so reconciliation reports a record whose `introduced` version has mixed builds as an unrepresentable interval and leaves it unchanged.
Current-version prerelease ambiguity produces an uncomparable review lead with no `range_state`, reduced confidence and `database_specific.review_reason: "prerelease_boundary"`. Ingest drops these leads and lists their IDs by reason in its run summary. An explicit `range_state` override for the formula and advisory resolves the current-state ambiguity; an `upstream_fixed_in` override alone does not. Without a reviewed state override, existing reviewed records stay unchanged.
A reviewed state override does not establish historical boundaries. When its state disagrees with comparable upstream evidence, or the upstream evidence cannot be checked, a new range needs manual review. Existing reviewed ranges are preserved rather than replaced with guessed introductions; range transitions and changed provenance still require their own checks.
## History options
`--new-history` requires `--output` and reuses existing reviewed ranges where possible; a successful replay does not independently verify those boundaries. `--json` without `--output` has no existing reviewed records to reuse, so history checks still apply to new comparable candidates. `--no-history` explicitly uses unverified zero/current-version boundaries for new ranges and cannot be combined with `--new-history`. It is an unchecked authoring mode, not a way to validate a skipped candidate.
## Reconciling existing ranges
`--reconcile-history --output advisories --overrides data/overrides.yml` explicitly revisits existing `source: matched`, bump-fixed records with one terminal interval. It requires complete formula history and matching provenance, with the same result on the latest supported macOS and Linux for both ARM and Intel. These simulations check declared formula and resource versions; they do not rebuild historical bottles or verify installation steps. It can narrow an affected interval or delete a record proven never affected; it preserves other fields and updates `modified` only for a range change. Generated records, patch fixes and open or multiple intervals are left unchanged. For records missed by current matching, complete registry-resource evidence can supply versionless upstream queries even after a resource has been removed. The fresh results must reproduce the stored upstream family and range basis, and every resource identity must occur in formula history on every platform. Stored subject versions only reproduce the range basis; historical decisions use versions from the formula sources. A missing historical resource holds the record as `resource_not_found`; a stored family absent from the fresh query results is `resource_not_rediscovered`. Mixed, incomplete or non-resource provenance still requires current discovery. These fallback queries cannot create records and respect formula skips and preserved Homebrew ranges. When a prerelease suffix changes a subject’s `SEMVER` range state compared with its release version, `prerelease_boundary` holds the record for review. The command reports skip reasons and the number of matched records it did not revisit; success does not establish complete coverage.
Before running this mode, protect hand-reviewed Homebrew boundaries with `preserve_homebrew_ranges: true` under the formula and advisory in `overrides.yml`. The pin applies across advisory aliases and is separate from `upstream_fixed_in`, which describes the upstream fix. Unavailable history or upstream records, changed subjects, conflicting platform results and advisory-specific patches require review. A failed upstream lookup holds every record for that formula with `upstream_unavailable`; a failed batch query holds its entire formula batch. A confirmed HTTP 404 while following an upstream link is cached as a missing target; a record with no resolved targets keeps its original evidence. A 404 for a supplemental CPANSA CVE lookup uses the CPANSA evidence for that CVE, including on subsequent platform passes. A 404 for an ID returned directly b…[truncated]</excerpt>
</source>
<source kind="search">
<title>advisory-database/CONTRIBUTING.md at main · Homebrew/advisory-database · GitHub</title>
<location>https://github.com/Homebrew/advisory-database/blob/main/CONTRIBUTING.md</location>
<excerpt>citeturn1search1 [wordlim: 200] Crawled: last month; Advisories in this repository come from three places: records generated from `resolves` annotations on `homebrew/core` formula patches, candidate records matched against external OSV feeds by `brew advisory-match`, and records contributed directly by pull request.
# CONTRIBUTING.md
Copy path
[Input: Go to file]
Blame More file actions
Blame More file actions
## Latest commit
## History
History
main
## Breadcrumbs
1. advisory-database
/
# CONTRIBUTING.md
Copy path
Top
## File metadata and controls
* Preview
* Code
* Blame
88 lines (59 loc) · 7.92 KB
# Contributing
Advisories in this repository come from three places: records generated from `resolves` annotations on `homebrew/core` formula patches, candidate records matched against external OSV feeds by `brew advisory-match`, and records contributed directly by pull request. All live under `advisories/` as OSV-schema JSON and are validated against that schema on every push.
The concatenated advisory index is built from the reviewed records on `main` and served at formulae.brew.sh/api/advisories.json.
## Reporting a fixed vulnerability
If a `homebrew/core` formula already ships a patch that fixes a CVE, the simplest route is to annotate the patch. Open a pull request against Homebrew/homebrew-core adding `resolves "CVE-YYYY-NNNNN"` to the relevant `patch do` block; see `libquicktime.rb` for an example. CVE identifiers appearing in the patch URL or applied file paths are picked up automatically without an explicit `resolves`. The daily `Regenerate` workflow will pick it up and write a `BREW-<formula>-<CVE>` record here automatically. Generated records carry `"database_specific": {"source": "generated"}`. The workflow refreshes their upstream-derived fields (`summary`, `severity`, `references`, `ecosystem_specific.patches`) on each run but preserves `published` and `affected[].ranges` from whatever is on disk, so a hand-corrected `fixed` boundary will not be overwritten.
## Contributing an advisory directly
Open a pull request adding a file under `advisories/` when you want to record something the generated path cannot express, most commonly that a formula version is affected and Homebrew has not yet applied a fix.
Before opening the PR, report the issue upstream according to the project's security policy and wait for it to be acknowledged. Versions are the formula version as `brew info` reports it, with an `_N` suffix when the revision is nonzero. Link the upstream CVE, GHSA or advisory in `upstream` and `references`.
## Reviewing matched candidates
Records with `"database_specific": {"source": "matched", ...}` are produced by `brew advisory-match` (in Homebrew/brew), which queries OSV.dev's GIT, language-registry and distro ecosystems plus CPANSA for a formula and emits one candidate per CVE reached. These arrive as automated PRs and need a human to confirm the match before merge.
`database_specific` tells you how the match was made:
* `strategy` is the highest-precision path that reached the CVE: `git` (the formula's forge repo), `registry` (a PyPI/npm/crates/... package derived from `stable.url` or a `resource`), `cpansa` (a CPAN distribution), or `distro` (a Debian/Ubuntu/... source package name mapped via Repology).
* `confidence` follows from strategy and whether a comparable version range was found: `high` for `git`/`registry` with a range, `medium` when no comparable range was found (typically GIT commit-SHA events), `low` for `distro`.
* `upstream_evidence` lists every path that reached the CVE, each with the `{ecosystem, name, subject_version}` that was queried.
`affected[0].ecosystem_specific` tells you what the range check concluded:
* `range_state` is `affected` (the shipped version is inside an upstream affected range), `fixed` (past one), or absent (no co…[truncated]</excerpt>
</source>
<source kind="search">
<title>Brew 6.0.14 Release - GitClear</title>
<location>https://www.gitclear.com/open_repos/homebrew/brew/release/6.0.14</location>
<excerpt>citeturn1search3 [wordlim: 200] Published: 2 months ago; Crawled: 2 months ago; # Brew: 6.0.14 Release ... * vulns: add advisory matcher and dev-cmd/advisory-match by @andrew in GitHub pull request 23329 in Homebrew/brew (link omitted to avoid creating a cross-reference)
* tap: require `trust` in `Tap#to_hash` by @carlocab in GitHub pull request 23333 in Homebrew/brew (link omitted to avoid creating a cross-reference)
* test/os/mac/keg: require `macho` by @carlocab in GitHub pull request 23334 in Homebrew/brew (link omitted to avoid creating a cross-reference)
* Preserve locale during brew startup by @MikeMcQuaid in GitHub pull request 23332 in Homebrew/brew (link omitted to avoid creating a cross-reference)
* Support Landlock ABI 2 on Linux kernel 6.1 by @MikeMcQuaid in GitHub pull request 23335 in Homebrew/brew (link omitted to avoid creating a cross-reference)
* Prepare complete DSL stanza ordering by @MikeMcQuaid in GitHub pull request 23331 in Homebrew/brew (link omitted to avoid creating a cross-reference)
* cask/audit: require "macho" before use by @chenrui333 in GitHub pull request 23337 in Homebrew/brew (link omitted to avoid creating a cross-reference)
* vulns: add advisory matcher and dev-cmd/advisory-match by @andrew in GitHub pull request 23329 in Homebrew/brew (link omitted to avoid creating a cross-reference)
* Group `on_system_conditional` after `os` by @AlternateRT in GitHub pull request 23339 in Homebrew/brew (link omitted to avoid creating a cross-reference)
</excerpt>
</source>
<omitted_sources count="30">Additional source records were omitted from this bounded result.</omitted_sources>
</source_evidence>
Citations:
- 1: https://www.gitclear.com/open_repos/homebrew/brew/release/6.0.14?utm_source=openai
- 2: https://github.com/Homebrew/advisory-database/blob/main/CONTRIBUTING.md?utm_source=openai
- 3: https://docs.brew.sh/Advisory-Matching?utm_source=openai
- 4: https://docs.brew.sh/Advisory-Matching?utm_source=openai
- 5: https://github.com/Homebrew/advisory-database/blob/main/CONTRIBUTING.md?utm_source=openai
<source_evidence>
<source kind="open_page">
<title>Submodule.move() follows an attacker-committed intermediate symlink outside the worktree · Advisory · gitpython-developers/GitPython · GitHub</title>
<location>https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-gq48-pqfc-9p58</location>
<excerpt>citeturn1view0 [wordlim: 200] Crawled: today; Content type: text/html; Source: open({"ref_id":"turn0search0","lineno":null}); Total lines: 737
L71: * SUPPORT & SERVICES
L72: * 【14†Documentation†docs.github.com】
L73: * 【44†Customer support†support.github.com】
L74: * 【45†Community forum】
L75: * 【46†Trust center】
L76: * 【47†Partners】
L77:
L78: 【48†View all resources】
L79:
L80: * Open Source
L81:
L82: * COMMUNITY
L83: * 【49†GitHub SponsorsFund open source developers】
L84: * PROGRAMS
L85: * 【50†Security Lab†securitylab.github.com】
L86: * 【51†Maintainer Community†maintainers.github.com】
L87: * 【52†GitHub Stars†stars.github.com】
L88: * 【53†Archive Program†archiveprogram.github.com】
L89:
L90: * REPOSITORIES
L91: * 【54†Topics】
L92: * 【55†Trending】
L93: * 【56†Collections】
L94:
L95: * Enterprise
L96:
L97: * ENTERPRISE SOLUTIONS
L98: * 【19†Enterprise platformAI-powered developer platform】
L99: * AVAILABLE ADD-ONS
L100: * 【10†GitHub Advanced SecurityEnterprise-grade security features】
L101: * 【57†Copilot for BusinessEnterprise-grade AI features】
L102: * 【58†Premium SupportEnterprise-grade 24/7 support】
L103:
L104: * 【59†Pricing】
L105:
L106: Search`/`
L107:
L108: 【1†Sign in】
L109:
L110: 【60†Sign up】
L111:
L112: Appearance settings
L113: You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
L114:
L115: 1. 【61†gitpython-developers】
L116: 2. 【62†GitPython】
L117: ## Repository navigation
L118:
L119: * * 【62†Code】
L120: * 【63†Issues1 (1)】
L121: * 【64†Pull requests】
L122: * 【65†Discussions】
L123: * 【66†Actions】
L124: * 【67†Security and quality42 (42)】
L125: * 【68†Insights】
L126:
L127: More items
L128:
L129: # Submodule.move() follows an attacker-committed intermediate symlink outside the worktree
L130:
L131: Moderate
L132:
L133: 【69†Byron】 published GHSA-gq48-pqfc-9p58 Sep 30, 2026
L134:
L135: ## Package
L136:
L137: GitPython (【70†pip】)
L138:
L139: ## Affected versions
L140:
L141: = 3.1.62
L142:
L143: ## Patched versions
L144:
L145: >= 3.2.0
L146:
L147: ## Description
L148: # `Submodule.move()` follows an attacker-committed intermediate symlink outside the worktree
L149: ## Summary
L150:
L151: GitPython's public `Submodule.move()` API verifies that its destination is lexically inside the parent repository, but it does not reject symbolic links in the destination's intermediate components before filesystem operations. On systems that check out Git symlinks, an untrusted repository can therefore redirect a fixed, application-selected move destination outside the parent worktree.
L152: I reproduced this on the latest release, GitPython 3.1.62, and current `main`. In the strict scenario, the repository commits `vendor -> ../outside`, while the consuming application independently passes the fixed literal `vendor/module`. `Submodule.move()` follows `vendor`, moves the initialized submodule checkout to `outside/module`, rewrites `.gitmodules` and the index to the symlinked path, and leaves the index unable to produce a tree.
L153: The same result occurs when the committed symlink contains an absolute path to an external directory. No attacker-controlled API argument, local symlink planting, race, Git hook, unsafe-option flag, or network access during the proof is required.
L154: ## Trust boundary and preconditions
L155:
L156: The attacker controls:
L157:
L158: * an untrusted Git repository that the application clones;
L159: * a mode-`120000` tracked symlink named `vendor`;
L160: * the initialized submodule's content.
L161:
L162: The consuming application controls the call and uses a fixed layout rule:
L163:
L164: submodule.move("vendor/module")
L165: The trigger requires the application to initialize the submodule and later call `Submodule.move()` with a path below the attacker-committed symlink. Ordinary clone or submodule update does not automatically make this call. Windows was not tested. The primitive applies where Git materializes the tracked entry as a real symlink; on Windows that generally requires `core.symlinks=true` with Developer Mode or sufficient privilege. Configurations that materialize it as an ordinary file do not take this path.
L166: ## Product and directly verified revisions
L167:
L168: * Package: `GitPython` (`pip` ecosystem)
L169: * Latest release: 3.1.62, tag commit `db47516dac750c5968b8f6d388b18712c355df50`
L170: * Current `main`: `b62e91be897f687a622e40cd1e59c33dce45f124`
L171: * Relevant `git/objects/submodule/base.py` SHA-256 in both revisions: `a4355d49e0b75c7c7e74d33ac70ff9550f940c977848c99da40eb41e034b189c`
L172: * Upstream state rechecked: 2026-09-10 KST
L173: Only these two revisions were directly tested. I recommend using `= 3.1.62` in initial advisory metadata and letting the maintainers determine the earliest affected version from history.
L174: ## Severity and weakness
L175:
L176: * Recommended severity: Medium, CVSS 3.1 6.1
L177: * Vector: `CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L`
L178: * CWE-59: Improper Link Resolution Before File Access
L179: * CWE-22: Improper Limitation of a Pathname to a Restricted Directory
L180: The demonstrated impact is an integrity boundary violation: repository content selects an existing directory outside the worktree, and GitPython moves an attacker-influenced checkout into a missing or empty child path there with the victim process's permissions. It also removes the original checkout and corrupts the parent repository's index/configuration state.
L181: For a downstream service that remotely accepts repositories and performs this exact layout operation with user involvement retained, `AV:N` gives a conditional application-level score of 7.1. A fully automatic service may warrant a different `UI` assessment. The library report uses `AV:L` because the vulnerable API call is a separate application action and is not part of GitPython's ordinary clone/update flow.
L182: No confidentiality impact, code execution, overwrite of an existing file, or overwrite of a non-empty directory was demonstrated.
L183:
L184: A maintainer who rates placement into a missing or empty external child as partial rather than total integrity loss may prefer `I:L`, which gives 4.4 with the otherwise identical library-level vector: `CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L`.
L185: ## Reproducer
L186:
L187: The following script creates only temporary local repositories and a self-generated canary. It passes `protocol.file.allow=always` separately with `-c` on each fixture Git invocation; that permission is process-scoped and is not persisted to global or repository configuration.
L188: Run it from a fresh source checkout:
L189:
L190: git clone --depth 1 --branch 3.1.62 https://github.com/gitpython-developers/GitPython.git
L191: python3 poc.py /path/to/GitPython
L192: python3 poc.py --absolute-link /path/to/GitPython
L193: `--absolute-link` commits the temporary external directory's absolute path instead of `../outside`.
L194:
L195: #!/usr/bin/env python3
L196: """Local-only reproducer for GitPython Submodule.move() symlink traversal."""
L197:
L198: from __future__ import annotations
L199:
L200: import argparse
L201: import json
L202: import subprocess
L203: import sys
L204: import tempfile
L205: from pathlib import Path
L206: from typing import Optional
L207:
L208:
L209: def run_git(
L210: *args: str, cwd: Optional[Path] = None, check: bool = True
L211: ) -> subprocess.CompletedProcess:
L212: command = [
L213: "git",
L214: "-c",
L215: "user.name=GitPython security fixture",
L216: "-c",
L217: "user.email=fixture@example.invalid",
L218: "-c",
L219: "protocol.file.allow=always",
L220: *args,
L221: ]
L222: return subprocess.run(command, cwd=cwd, check=check, text=True, capture_output=True)
L223:
L224:
L225: def read_core_worktree(parent) -> str:
L226: module_config = Path(parent.git_dir) / "modules" / "logical-name" / "config"
L227: return parent.git.config("--file", str(module_config), "--get", "core.worktree")
L228:
L229:
L230: def read_gitmodules_path(parent) -> str:
L231: modules_file = Path(parent.working_tree_dir) / ".gitmodules"
L232: return parent.git.config(
L233: "--file", str(modules_file), "--get", "submodule.logical-name.path"
L234: )
L235:
L236:
L237: def main() -> int:
L238: parser = argparse.ArgumentParser()
L239: parser.add_argument("source_root", type=Path, help="GitPython source checkout")
L240: parser.add_argument(
L241: "--absolute-link",
L242: action="store_true",
L243: help=(
L244: "Use the temporary external directory's absolute path as the committed "
L245: "symlink target"
L246: ),
L247: )
L248: args = parser.parse_args()
L249:
L250: source_root = args.source_root.resolve()
L251: # The tested GitPython source trees include gitdb and smmap at their roots.
L252: sys.path[:0] = [
L253: str(source_root),
L254: str(source_root / "gitdb"),
L255: str(source_root / "smmap"),
L256: ]
L257: import gitdb # pylint: disable=import-outside-toplevel
L258: import smmap # pylint: disable=import-outside-toplevel
L259: from git import Repo # pylint: disable=import-outside-toplevel
L260: with tempfile.TemporaryDirectory(prefix="gitpython-move-poc-") as temporary:
L261: root = Path(temporary)
L262: module_source = root / "module-source"
L263: attacker = root / "attacker-parent"
L264: victim = root / "victim-parent"
L265: outside = root / "outside"
L266:
L267: run_git("init", "--quiet", str(module_source))
L268: (module_source / "SELF_GENERATED_CANARY.txt").write_text(
L269: "SELF_GENERATED_CANARY\n", encoding="utf-8"
L270: )
L271: run_git("add", "SELF_GENERATED_CANARY.txt", cwd=module_source)
L272: run_git("commit", "--quiet", "-m", "fixture", cwd=module_source)
L273:
L274: outside.mkdir()
L275: run_git("init", "--quiet", str(attacker))
L276: run_git(
L277: "submodule",
L278: "add",
L279: "--quiet",
L280: "--name",
L281: "logical-name",
L282: str(module_source),
L283: "module",
L284: cwd=attacker,
L285: )
L286: link_target = str(outside.resolve()) if args.absolute_link else "../outside"
L287: (attacker / "vendor").symlink_to(link_target, target_is_directory=True)
L288: run_git("add", ".gitmodules", "module", "vendor", cwd=attacker)
L289: run_git("commit", "--quiet", "-m", "attacker-controlled layout", cwd=attacker)
L290:
L291: run_git("clone", "--quiet", str(attacker), str(victim))
L292: run_git("submodule", "update", "--init", "--quiet", cwd=victim)
L293: parent = Repo(victim)
L294: submodule = parent.submodule("logical-name")
L295: before = {
L296: "status": parent.git.status("--porcelain"),
L297: "write_tree": parent.git.write_tree(),
L298: "vendor_index": parent.git.ls_files("--stage", "vendor"),
L299: "index_paths": parent.git.ls_files().splitlines(),
L300: "gitmodules_path": read_gitmodules_path(parent),
L399: `Submodule.move()` then joins the accepted relative path to the worktree and passes it to filesystem operations, including `os.listdir()` and `os.renames()`:
L400:
L401: module_checkout_path = self._to_relative_path(self.repo, module_path)
L402: ...
L403: module_checkout_abspath = join_path_native(str(self.repo.working_tree_dir), module_checkout_path)
L404: ...
L405: os.renames(cur_path, module_checkout_abspath)
L406:
L407: The operating system resolves `vendor/module` through the checked-out `vendor` link at that point.
L661: ## Validation
L662:
L663: The strict clean-clone proof was run with both relative and absolute committed symlink targets:
L664:
L665: Revision | macOS ARM64 unpatched | Linux ARM64 unpatched | macOS patched | Linux patched
L666: --- | --- | --- | --- | ---
L667: 3.1.62 | escape reproduced | escape reproduced | rejected before mutation | rejected before mutation
L668: `main` `b62e91b` | escape reproduced | escape reproduced | rejected before mutation | rejected before mutation
L669: Both platforms were ARM64 on the same physical Mac; Linux ran in a local LinuxKit VM image. All runs used Python 3.14.7. The Linux runs used a local image by immutable SHA-256, with networking disabled, a read-only container root and source mount, and a temporary writable `/tmp`.
L670:
L671: Pinned reproducer SHA-256: `513b6f32fc44cc74bee1ca8e81e8ed3f48ae89bfdc332dd6782886bfd1d6a79c`.
L672: The documented shallow-clone command was also executed from a new temporary directory at 3.1.62. The reproducer resolved `git`, `gitdb`, and `smmap` from that checkout (`git/__init__.py`, `gitdb/gitdb/__init__.py`, and `smmap/smmap/__init__.py`) and reproduced the same external move. In that exact checkout, `git ls-tree HEAD gitdb smmap git/ext` reports ordinary mode-`040000` trees for root `gitdb` and `smmap`, no `.gitmodules` file exists, and `git submodule status --recursive` produces no entries.
L673: No recursive submodule checkout or preinstalled GitPython dependency was used for that bootstrap check. The evidence package includes both the raw local tree transcript and the matching official GitHub tree API entries.
L674: The revised patch also passed 12 focused tests on each revision on each platform (48 test executions total). They cover:
L675: * relative and absolute ordinary moves from an external process working directory;
L676: * relative and absolute no-op ordering;
L677: * no-op compatibility when the stored path includes an existing symlink;
L678: * the unchanged `Submodule.abspath` leaf-link guard;
L679: * relative and absolute intermediate-link rejection before rename;
L680: * empty-directory, non-empty-directory, file, and dangling final-component link behavior.
L681: Ruff 0.16.6 lint and format checks, Python compilation, patch application, and patched-file byte comparison passed for both revisions. GitPython's complete upstream test suite and mypy were not run against the patch; the test claim is limited to the focused matrix described above.
L682: Additional saved controls on both revisions record rejection of `../` and absolute API destinations, preservation of existing files and non-empty directories, the final-component link behavior, and `RootModule.update()` rejecting the tested commit-to-commit symlinked path before its internal move. These controls are separate from the strict 16-run proof.
L683: ## Impact limits and compatibility observations
L684: * An existing destination file and an existing non-empty destination directory are preserved and rejected.
L685: * A missing or empty leaf below an external symlink target can be populated.
L686: * `../` and an absolute API destination outside the worktree are already rejected; the bypass is filesystem resolution of a lexically in-tree path.
L687: * `RootModule.update()` rejects the tested commit-to-commit symlinked path before its internal `move()` call, so ordinary clone/update is not an automatic trigger.
L688: * The proof does not require or demonstrate a local race.
L689: * The directly demonstrated relative target is the practical repository-relative case. The absolute variant proves target-path scope using a temporary path known to the fixture; a remote attacker would instead need a predictable absolute directory on the victim.
L690: * The exact affected history before 3.1.62 has not been established.
L691: ## Duplicate analysis
L692:
L693: This is adjacent to 【71†GHSA-59cr-6r3x-644w】, but the trigger and primitive differ. That advisory covers an attacker-controlled `.gitmodules` path containing lexical traversal reaching the update flow. The `_to_relative_path()` check that `move()` relies on blocks lexical traversal, while this report demonstrates that it does not block operating-system resolution of an attacker-committed intermediate symlink when the application supplies a fixed destination.
L694: The relevant distinctions are:
L695:
L696: * attacker input: committed symlink versus `.gitmodules` traversal text;
L697: * caller input: fixed application literal versus attacker-selected destination;
L698: * entry point: public `Submodule.move()` versus update processing;
L699: * primitive: link resolution after lexical validation versus `..` traversal;
L700: * effect: external checkout move plus index and configuration rewrite.
L701: 【72†GHSA-hmq2-w58f-27jc】 concerns the submodule name selecting `.git/modules/<name>`, and 【73†GHSA-7545-fcxq-7j24】 concerns reference APIs. Neither describes this `Submodule.move()` destination behavior. The ID-to-summary mapping for all three related advisories was rechecked through GitHub's authenticated repository advisory API immediately before submission review.
L702: On 2026-09-10 KST, exact GitHub issue/PR searches for `Submodule.move` with symlink terms and for an intermediate-symlink worktree move returned no public match. Private reports and unpublished fixes remain unknown.
L703: ## Disclosure status
L704:
</excerpt>
</source>
<source kind="open_page">
<title>OSV - Open Source Vulnerabilities</title>
<location>https://osv.dev/vulnerability/CVE-2026-110860</location>
<excerpt>citeturn1view1 [wordlim: 200] Crawled: today; Content type: text/html; Source: open({"ref_id":"turn0search2","lineno":null}); Total lines: 107
L0: [Input]
L1:
L2: * 【0†Vulnerability Database】
L3: * 【1†Blog】
L4: * 【2†FAQ†google.github.io】
L5: * 【3†Docs†google.github.io】
L6: # CVE-2026-110860
L7:
L8: 【4†See a problem?†google.github.io】
L9: Please try reporting it 【5†to the source†cve.org】 first.
L10:
L11: Source
L12: 【5†https://cve.org/CVERecord?id=CVE-2026-110860†cve.org】
L13: Import Source
L14: 【6†https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-110860.json†storage.googleapis.com】
L15: JSON Data
L16: 【7†https://api.osv.dev/v1/vulns/CVE-2026-110860†api.osv.dev】
L17: Aliases
L18:
L19:
L20: * 【8†GHSA-gq48-pqfc-9p58】
L21: Downstream
L22: * 【9†DEBIAN-CVE-2026-110860】
L23: * 【10†ECHO-52da-a715-9855】
L24: * 【11†UBUNTU-CVE-2026-110860】
L25: Published
L26: 2026-10-14T22:52:44Z
L27: Modified
L28: 2026-10-27T02:31:04Z
L29: Severity
L30:
L31:
L32: * 6.9 (Medium) CVSS_V4 - CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N 【12†CVSS Calculator†www.first.org】
L33: Summary
L34: GitPython 3.1.62 before 3.2.0 Symlink Path Traversal via Submodule.move()
L35: Details
L36: GitPython from 3.1.62 before 3.2.0 contains a symlink-following flaw in Submodule.move(), which checks the destination only lexically and does not reject symbolic links in intermediate path components. An untrusted repository can commit a symlink such as vendor pointing outside the worktree, so an application moving an initialized submodule beneath it relocates the checkout externally and corrupts the index and .gitmodules.
L37: Database specific
L38:
L39:
L40: {
L41: "cna_assigner": "VulnCheck",
L42: "cwe_ids": [
L43: "CWE-59"
L44: ],
L45: "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/110xxx/CVE-2026-110860.json"
L46: }
L47:
L48: References
L49: * 【13†https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/110xxx/CVE-2026-110860.json†github.com】
L50: * 【14†https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-gq48-pqfc-9p58†github.com】
L51: * 【15†https://nvd.nist.gov/vuln/detail/CVE-2026-110860†nvd.nist.gov】
L52: * 【16†https://www.vulncheck.com/advisories/gitpython-3.1.62-before-3.2.0-symlink-path-traversal-via-submodule-move†www.vulncheck.com】
L53: ## Affected packages
L54:
L55: ## Git / github.com/gitpython-developers/gitpython
L56: ### Affected ranges
L57:
L58: Type
L59: GIT
L60: Repo
L61: https://github.com/gitpython-developers/gitpython
L62: Events
L63:
L64:
L65: Introduced
L66:
L67: 【17†db47516dac750c5968b8f6d388b18712c355df50†github.com】
L68:
L69: Fixed
L70:
L71: 【18†6a7180a9dfcb276755a8af99dd78155f775a6b14†github.com】
L72: Database specific
L73: Show details
L74:
L75: {
L76: "extracted_events": [
L77: {
L78: "range": [
L79: {
L80: "introduced": "3.1.62"
L81: },
L82: {
L83: "fixed": "3.2.0"
L84: }
L85: ],
L86: "source": "AFFECTED_FIELD",
L87: "strategy": "StandardRange"
L88: },
L89: {
L90: "range": [
L91: {
L92: "introduced": "3.1.62"
L93: },
L94: {
L95: "fixed": "3.2.0"
L96: }
L97: ],
L98: "source": "DESCRIPTION"
L99: }
L100: ]
L101: }
L102: ### Database specific
L103:
L104: source
L105:
L106: "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-110860.json"
</excerpt>
</source>
<source kind="search">
<title>Submodule.move() follows an attacker-committed intermediate symlink outside the worktree · Advisory · gitpython-developers/GitPython · GitHub</title>
<location>https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-gq48-pqfc-9p58</location>
<excerpt>citeturn0search0 [wordlim: 200] Published: 3 weeks ago; Crawled: 2 days ago; Byron published GHSA-gq48-pqfc-9p58 Sep 30, 2026 ... I reproduced this on the latest release, GitPython 3.1.62, and current `main`. ... I recommend using `= 3.1.62` in initial advisory metadata and letting the maintainers determine the earliest affected version from history. ... The demonstrated impact is an integrity boundary violation: repository content selects an existing directory outside the worktree, and GitPython moves an attacker-influenced checkout into a missing or empty child path there with the victim process's permissions.
</excerpt>
</source>
<source kind="search">
<title>OSV - Open Source Vulnerabilities</title>
<location>https://osv.dev/vulnerability/CVE-2026-110860</location>
<excerpt>citeturn0search2 [wordlim: 200] Published: last week; Crawled: last week; https://api.osv.dev/v1/vulns/CVE-2026-110860
* GHSA-gq48-pqfc-9p58 ... GitPython 3.1.62 before 3.2.0 Symlink Path Traversal via Submodule.move() ... * https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-gq48-pqfc-9p58
</excerpt>
</source>
<source kind="search">
<title>GitPython: Submodule.move() follows an attacker-committed intermediate symlink outside the worktree · GHSA-gq48-pqfc-9p58 · GitHub Advisory Database · GitHub</title>
<location>https://abab.bluecat.qzz.io/advisories/GHSA-gq48-pqfc-9p58</location>
<excerpt>citeturn0search1 [wordlim: 200] Published: 3 weeks ago; Crawled: today; ## Affected versions ... The reporter reproduced this on the latest release, GitPython 3.1.62, and current `main`. ... The demonstrated impact is an integrity boundary violation: repository content selects an existing directory outside the worktree, and GitPython moves an attacker-influenced checkout into a missing or empty child path there with the victim process's permissions.
</excerpt>
</source>
<omitted_sources count="18">Additional source records were omitted from this bounded result.</omitted_sources>
</source_evidence>
Citations:
- 1: https://osv.dev/vulnerability/CVE-2026-110860
- 2: https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-gq48-pqfc-9p58
<source_evidence>
<source kind="search">
<title>GitPython · PyPI</title>
<location>https://pypi.org/project/GitPython/</location>
<excerpt>citeturn0search1 [wordlim: 200] Crawled: today; PyPI data ... gitpython-3.2.1-py3-none-any.whl 231.5 kB Oct 14, 2026 Without provenance | Python 3 | none | any | Details ... Uploaded via | `twine/7.0.0 CPython/3.14.7`
## Release history Release notifications | RSS feed
This release
Image
3.2.1 This release
Oct 14, 2026 2 release files No provenance
Image
3.2.0
Sep 30, 2026 2 release files No provenance
Image
3.1.62
Sep 7, 2026 2 release files No provenance
Image
3.1.61
Aug 28, 2026 2 release files No provenance
Image
3.1.60
Aug 25, 2026 2 release files No provenance
Image
3.1.59
Aug 10, 2026 2 release files No provenance
Image
3.1.58
Aug 4, 2026 2 release files No provenance
Image
3.1.57
Jul 26, 2026 2 release files No provenance
Image
3.1.56
Jul 25, 2026 2 release files No provenance
Image
3.1.55
Jul 23, 2026 2 release files No provenance
Image
3.1.54
Jul 22, 2026 2 release files No provenance
Image
3.1.53
Jul 20, 2026 2 release files No provenance
Image
3.1.52
Jul 16, 2026 2 release files No provenance
Image
3.1.51
Jul 12, 2026 2 release files No provenance
</excerpt>
</source>
<source kind="search">
<title>GHSA-gq48-pqfc-9p58 - Path Traversal - SecAlerts</title>
<location>https://secalerts.co/vulnerability/GHSA-gq48-pqfc-9p58</location>
<excerpt>citeturn0search2 [wordlim: 200] Published: today; Crawled: today; - Package: GitPython (pip ecosystem) - Latest release: 3.1.62, tag commit db47516dac750c5968b8f6d388b18712c355df50 - Current main: b62e91be897f687a622e40cd1e59c33dce45f124 - Relevant git/objects/submodule/base.py SHA-256 in both revisions: a4355d49e0b75c7c7e74d33ac70ff9550f940c977848c99da40eb41e034b189c - Upstream state rechecked: 2026-09-10 KST ... * https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-gq48-pqfc-9p58 ... * https://github.com/advisories/GHSA-gq48-pqfc-9p58Advisory
Trust boundary and preconditions
The attacker controls:
- an untrusted Git repository that the application clones; - a mode-120000 tracked symlink named vendor; - the initialized submodule's content.
The consuming application controls the call and uses a fixed layout rule:
python submodule.move("vendor/module")
The trigger requires the application to initialize the submodule and later call Submodule.move() with a path below the attacker-committed symlink. Ordinary clone or submodule update does not automatically make this call. Windows was not tested. The primitive applies where Git materializes the tracked entry as a real symlink; on Windows that generally requires core.symlinks=true with Developer Mode or sufficient privilege. Configurations that materialize it as an ordinary file do not take this path.
Product and directly verified revisions
- Package: GitPython (pip ecosystem) - Latest release: 3.1.62, tag commit db47516dac750c5968b8f6d388b18712c355df50 - Current main: b62e91be897f687a622e40cd1e59c33dce45f124 - Relevant git/objects/submodule/base.py SHA-256 in both revisions: a4355d49e0b75c7c7e74d33ac70ff9550f940c977848c99da40eb41e034b189c - Upstream state rechecked: 2026-09-10 KST
Only these two revisions were directly tested.
Severity and weakness
The demonstrated impact is an integrity boundary violation: repository content selects an existing directory outside the worktree, and GitPython moves an attacker-influenced checkout into a missing or empty child path there with the victim process's permissions. It also removes the original checkout and corrupts the parent repository's index/configuration state.
For a downstream service that remotely accepts repositories and performs this exact layout operation with user involvement retained, AV:N gives a conditional application-level score of 7.1. A fully automatic service may warrant a different UI assessment. The library report uses AV:L because the vulnerable API call is a separate application action and is not part of GitPython's ordinary clone/update flow.
No confidentiality impact, code execution, overwrite of an existing file, or overwrite of a non-empty directory was demonstrated.
## Affected Software
1 affected component Fixes available
pip/gitpython<3.2.0
3.2.0
## Remediation
Recommended actions to resolve this vulnerability, in priority order.
1. Upgrade
Upgrade `pip/GitPython` to a version that resolves this vulnerability.
Fixed in 3.2.0
2. Compensating control
Patch GitPython's Submodule.move() to normalize the destination once and reject symbolic links in every intermediate destination component before any filesystem, index, or configuration mutation; the patched behavior raises ValueError for a destination such as 'vendor/module' when 'vendor' is a symbolic link.
</excerpt>
</source>
<source kind="search">
<title>GitPython · PyPI</title>
<location>https://pypi.org/project/GitPython/3.2.0/</location>
<excerpt>citeturn0search0 [wordlim: 200] Published: 3 weeks ago; Crawled: 3 days ago; PyPI data ... gitpython-3.2.0.tar.gz | 238.1 kB | Sep 30, 2026 | Without provenance | Details ... gitpython-3.2.0-py3-none-any.whl 228.5 kB Sep 30, 2026 Without provenance | Python 3 | none | any | Details
## Project links
* Documentation
* Source code
## Key dates
PyPI data
Data sourced directly from PyPI's database.
* Released: Sep 30, 2026
Newer release available (3.2.1)
## 2 maintainers
PyPI data
Data sourced directly from PyPI's database.
ByronBates mtrier
## Credits
Author: Sebastian Thiel (byronimo@gmail.com)
## License
BSD-3-Clause
## Requires
Python >=3.8
## Provides Extra
`test`
## Tags
`git`
## Classifiers
* Development Status
* 5 - Production/Stable
* Environment
* Console
* Intended Audience
* Developers
* Operating System
* MacOS :: MacOS X
* Microsoft :: Windows
* OS Independent
* POSIX
* Programming Language
* Python
* Python :: 3
* Python :: 3.8
* Python :: 3.9
* Python :: 3.10
* Python :: 3.11
* Python :: 3.12
* Python :: 3.13
* Python :: 3.14
* Python :: 3.15
* Typing
* Typed
## Release files for GitPython 3.2.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
### Source distribution (sdist)
Source distribution for GitPython 3.2.0
File | Size | Uploaded | Provenance |
--- | --- | --- | --- | ---
gitpython-3.2.0.tar.gz | 238.1 kB | Sep 30, 2026 | Without provenance | Details
* * *
### Built distribution (wheel)
Table of built distributions (wheels) for GitPython 3.2.0
File | Interpreter | ABI | Platform |
--- | --- | --- | --- | ---
gitpython-3.2.0-py3-none-any.whl 228.5 kB Sep 30, 2026 Without provenance | Python 3 | none | any | Details
* * *
Total release size: 466.6 kB
## Release files / gitpython-3.2.0.tar.gz
## Release history Release notifications | RSS feed
Image
3.2.1
Oct 14, 2026 2 release files No provenance
This release
Image
3.2.0 This release
Sep 30, 2026 2 release files No provenance
Image
3.1.62
Sep 7, 2026 2 release files No provenance
Image
3.1.61
Aug 28, 2026 2 release files No provenance
Image
3.1.60
Aug 25, 2026 2 release files No provenance
Image
3.1.59
Aug 10, 2026 2 release files No provenance
Image
3.1.58
Aug 4, 2026 2 release files No provenance
Image
3.1.57
Jul 26, 2026 2 release files No provenance
Image
3.1.56
Jul 25, 2026 2 release files No provenance
</excerpt>
</source>
<source kind="search">
<title>python3-GitPython-3.2.0-1.fc46.noarch RPM</title>
<location>https://www.rpmfind.net/linux/RPM/fedora/devel/rawhide/s390x/p/python3-GitPython-3.2.0-1.fc46.noarch.html</location>
<excerpt>citeturn0search3 [wordlim: 200] Published: 3 weeks ago; Crawled: 3 weeks ago; - Fixes GHSA-gq48-pqfc-9p58, GHSA-23mf-xhv8-69c2, GHSA-f9j4-qggq-h239, ... GHSA-284h-m62q-gf8w, GHSA-7833-fr7j-v32q, GHSA-hh9p-6wh2-4mfc,
</excerpt>
</source>
<source kind="search">
<title>GitPython: Submodule.move() follows an attacker-committed intermediate symlink outside the worktree · GHSA-gq48-pqfc-9p58 · GitHub Advisory Database · GitHub</title>
<location>https://abab.bluecat.qzz.io/advisories/GHSA-gq48-pqfc-9p58</location>
<excerpt>citeturn0search4 [wordlim: 200] Published: 3 weeks ago; Crawled: today; * GHSA-gq48-pqfc-9p58 ... * https://abab.bluecat.qzz.io/gitpython-developers/GitPython/releases/tag/3.2.0
</excerpt>
</source>
<omitted_sources count="12">Additional source records were omitted from this bounded result.</omitted_sources>
</source_evidence>
Citations:
- 1: https://secalerts.co/vulnerability/GHSA-gq48-pqfc-9p58?utm_source=openai
- 2: https://pypi.org/project/GitPython/?utm_source=openai
Web query:
Homebrew fdroidserver formula history 0.7.0 GitPython resource version
Use the first fdroidserver build that bundled GitPython 3.1.62.
GHSA-gq48-pqfc-9p58 affects only GitPython 3.1.62 and is fixed in 3.2.0. Homebrew’s 0.7.0 formula history bundled GitPython 2.1.3, so introduced: "0.7.0" includes unaffected builds.
The sibling advisories do not justify this boundary. CVE-2026-110858 starts at 2.1.2, showing that matched GitPython ranges can have advisory-specific lower bounds. The record stores upstream_fixed_in: "3.2.0" but does not record the upstream lower endpoint separately.
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.
set -u
printf'%s\n''--- related advisory/history files ---'
rg -n -F --glob '*.json' -e 'fdroidserver' -e 'CVE-2026-110858' -e 'GHSA-f9j4-qggq-h239' advisories .github 2>/dev/null ||test"$?" -eq 1
printf'%s\n''--- advisory history and range overrides ---'
git log --all --oneline -- advisories/BREW-fdroidserver-CVE-2026-110858.json
git log --all -S'BREW-fdroidserver-CVE-2026-110858' --oneline -- advisories
rg -n -i --glob '*.json' -e 'override' -e 'reviewed' -e 'range_state' advisories | head -120
printf'%s\n''--- available formula evidence ---'
rg --files .| rg 'fdroidserver|homebrew-core|formula|resource'| head -120
printf'%s\n''--- remote historical formula references ---'
git remote -v
git ls-remote https://github.com/Homebrew/homebrew-core.git 'refs/tags/*'2>/dev/null | head -3
Repository: Homebrew/advisory-database
Length of output: 16873
Web query:
GitPython GHSA-f9j4-qggq-h239 affected versions CVE-2026-110858 official advisory
Result:
<source_evidence>
<source kind="open_page">
<title>GitPython Remote.pull() refspec bypasses the --upload-pack unsafe-option guard, enabling arbitrary command execution · Advisory · gitpython-developers/GitPython · GitHub</title>
<location>https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-f9j4-qggq-h239</location>
<excerpt>citeturn1view0 [wordlim: 200] Crawled: today; Content type: text/html; Source: open({"ref_id":"https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-f9j4-qggq-h239","lineno":null}); Total lines: 296
L0: 【0†Skip to content】
L1: ## Navigation Menu
L2:
L3: 【1†Sign in】
L4:
L5: Appearance settings
L6:
L7: * Platform
L8:
L9: * AI CODE CREATION
L10: * 【2†GitHub CopilotWrite better code with AI】
L11: * 【3†GitHub Copilot appDirect agents from issue to merge】
L12: * 【4†MCP RegistryIntegrate external tools】
L13:
L14: * DEVELOPER WORKFLOWS
L15: * 【5†ActionsAutomate any workflow】
L16: * 【6†CodespacesInstant dev environments】
L17: * 【7†IssuesPlan and track work】
L18: * 【8†Code ReviewManage code changes】
L19: * 【9†Code QualityEnforce quality at merge】
L20: * APPLICATION SECURITY
L21: * 【10†GitHub Advanced SecurityFind and fix vulnerabilities】
L22: * 【11†Code securitySecure your code as you build】
L23: * 【12†Secret protectionStop leaks before they start】
L24:
L25: * EXPLORE
L26: * 【13†Why GitHub】
L27: * 【14†Documentation†docs.github.com】
L28: * 【15†Blog†github.blog】
L29: * 【16†Changelog†github.blog】
L30: * 【17†Marketplace】
L31:
L32: 【18†View all features】
L33:
L34: * Solutions
L35: * BY COMPANY SIZE
L36: * 【19†Enterprises】
L37: * 【20†Small and medium teams】
L38: * 【21†Startups】
L39: * 【22†Nonprofits】
L40:
L41: * BY USE CASE
L42: * 【23†App Modernization】
L43: * 【24†DevSecOps】
L44: * 【25†DevOps】
L45: * 【26†CI/CD】
L46: * 【27†View all use cases】
L47:
L48: * BY INDUSTRY
L49: * 【28†Healthcare】
L50: * 【29†Financial services】
L51: * 【30†Manufacturing】
L52: * 【31†Government】
L53: * 【32†See all industries】
L54:
L55: 【33†View all solutions】
L56:
L57: * Resources
L58: * EXPLORE BY TOPIC
L59: * 【34†AI】
L60: * 【35†Software Development】
L61: * 【36†DevOps】
L62: * 【37†Security】
L63: * 【38†View all topics】
L64:
L65: * EXPLORE BY TYPE
L66: * 【39†Customer stories】
L67: * 【40†Events & webinars】
L68: * 【41†Ebooks & reports】
L69: * 【42†Business insights】
L70: * 【43†GitHub Skills†skills.github.com】
L71: * SUPPORT & SERVICES
L72: * 【14†Documentation†docs.github.com】
L73: * 【44†Customer support†support.github.com】
L74: * 【45†Community forum】
L75: * 【46†Trust center】
L76: * 【47†Partners】
L77:
L78: 【48†View all resources】
L79:
L80: * Open Source
L81:
L82: * COMMUNITY
L83: * 【49†GitHub SponsorsFund open source developers】
L84: * PROGRAMS
L85: * 【50†Security Lab†securitylab.github.com】
L86: * 【51†Maintainer Community†maintainers.github.com】
L87: * 【52†GitHub Stars†stars.github.com】
L88: * 【53†Archive Program†archiveprogram.github.com】
L89:
L90: * REPOSITORIES
L91: * 【54†Topics】
L92: * 【55†Trending】
L93: * 【56†Collections】
L94:
L95: * Enterprise
L96:
L97: * ENTERPRISE SOLUTIONS
L98: * 【19†Enterprise platformAI-powered developer platform】
L99: * AVAILABLE ADD-ONS
L100: * 【10†GitHub Advanced SecurityEnterprise-grade security features】
L101: * 【57†Copilot for BusinessEnterprise-grade AI features】
L102: * 【58†Premium SupportEnterprise-grade 24/7 support】
L103:
L104: * 【59†Pricing】
L105:
L106: Search`/`
L107:
L108: 【1†Sign in】
L109:
L110: 【60†Sign up】
L111:
L112: Appearance settings
L113: You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
L114:
L115: 1. 【61†gitpython-developers】
L116: 2. 【62†GitPython】
L117: ## Repository navigation
L118:
L119: * * 【62†Code】
L120: * 【63†Issues1 (1)】
L121: * 【64†Pull requests】
L122: * 【65†Discussions】
L123: * 【66†Actions】
L124: * 【67†Security and quality42 (42)】
L125: * 【68†Insights】
L126:
L127: More items
L128:
L129: # GitPython Remote.pull() refspec bypasses the --upload-pack unsafe-option guard, enabling arbitrary command execution
L130:
L131: Critical
L132:
L133: 【69†Byron】 published GHSA-f9j4-qggq-h239 Sep 30, 2026
L134:
L135: ## Package
L136:
L137: GitPython (【70†pip】)
L138:
L139: ## Affected versions
L140:
L141: >= 3.1.30
L142:
L143: ## Patched versions
L144:
L145: >= 3.2.0
L146:
L147: ## Description
L148: ## Summary
L149: `Remote.pull()` in GitPython forwards its positional `refspec` argument directly to the `git pull` child process while its unsafe-option guard inspects only keyword arguments. An application that passes attacker-influenced data as the `refspec` (for example a user-supplied branch or refspec parameter in a web or CI service) can supply an option-shaped value such as `--upload-pack=<command>`.
L150: The value bypasses the `unsafe_git_pull_options` check, is placed after the `--` separator on the `git pull` command line, and is executed as the upload-pack program for local-path or SSH transports. This yields arbitrary command execution with the privileges of the calling process using the documented default arguments (`allow_unsafe_options=False`).
L151: ## Root Cause
L152: `Remote.pull()` is documented to reject dangerous options unless `allow_unsafe_options=True`, and `--upload-pack` is explicitly listed as such an option. The guard, however, only screens keyword arguments and never the positional `refspec`. The check builds its candidate list with `Git._option_candidates([], kwargs)`, passing an empty list in place of the positionals, so the `refspec` value is never compared against `unsafe_git_pull_options = ["--upload-pack"]`.
L153: The normalized `refspec` is then forwarded verbatim to the `git pull` invocation. The leading `--` separator that neutralizes an option-shaped refspec for `git fetch` and `git push` does not protect `git pull`, because `git pull` re-forwards its trailing positionals to an internal `git fetch` without re-inserting a `--` separator, so the positional becomes an option to that internal fetch.
L154:
L155: `Affected function: git.remote.Remote.pull
L156: Source: git/remote.py (guard at the check_unsafe_options call using _option_candidates([], kwargs); sink at the self.repo.git.pull("--", self, refspec, ...) invocation)
L157: `
L158: ## Impact
L159: An attacker who controls the `refspec` value passed to `Remote.pull()` achieves arbitrary operating-system command execution as the process invoking GitPython, with no additional privileges and no user interaction, on the default code path. Exploitation requires that the pulled remote uses a transport that runs upload-pack on the local side, namely a local filesystem path or SSH; over HTTPS the `--upload-pack` value is inert because the server ignores a client-supplied upload-pack program.
L160: This transport requirement narrows the population of vulnerable deployments but does not add work for the attacker once a vulnerable target is reached. Working checkouts commonly use local-path or SSH origins, so the exposed population is substantial.
L161: ## Proof of Concept
L162:
L163: `Environment: GitPython from the affected source tree; system git 2.43.0.
L164: The pulled origin uses a local filesystem transport (protocol.file.allow=always for git >= 2.38).
L165: `
L166:
L167: Reproduction steps:
L168: 1. Create an origin repository reachable over a local-path transport.
L169: 2. In a consumer repository, register that origin and call `Remote.pull()` with an attacker-controlled refspec.
L170: 3. Observe that the injected command executes.
L171:
L172: import git
L173: repo = git.Repo("consumer") # has an origin using a local-path or ssh transport
L174: origin = repo.remote("origin")
L175: # Attacker-controlled refspec value; default arguments (allow_unsafe_options=False):
L176: origin.pull(refspec="--upload-pack=touch /tmp/pwned; git-upload-pack")
L177:
L178: `cmdline: git pull -v -- origin --upload-pack=touch /tmp/pwned; git-upload-pack
L179: [attack] marker created (RCE) : True
L180: [isolate] upload_pack passed as KWARG blocked : True (only the positional refspec escapes)
L181: [sibling] same value via git fetch : safe (pull-specific behavior)
L182: [control] benign refspec : safe
L183: `
L184: ## Attack Chain
L185: 1. Exposure: An application calls `Remote.pull(refspec=<value>)` on the default path, where `<value>` is derived from attacker-influenced input such as a branch or refspec request parameter.
</excerpt>
</source>
<source kind="open_page">
<title>GitPython from 3.1.30 before 3.2.0 contains a remote code... · CVE-2026-110858 · GitHub Advisory Database · GitHub</title>
<location>https://github.com/advisories/GHSA-mcf4-6385-6rcq</location>
<excerpt>citeturn1view1 [wordlim: 200] Crawled: yesterday; Content type: text/html; Source: open({"ref_id":"turn0search2","lineno":null}); Total lines: 251
L0: 【0†Skip to content】
L1: ## Navigation Menu
L2:
L3: 【1†Sign in】
L4:
L5: Appearance settings
L6:
L7: CVE-2026-110858
L8:
L9: * Platform
L10:
L11: * AI CODE CREATION
L12: * 【2†GitHub CopilotWrite better code with AI】
L13: * 【3†GitHub Copilot appDirect agents from issue to merge】
L14: * 【4†MCP RegistryIntegrate external tools】
L15: * DEVELOPER WORKFLOWS
L16: * 【5†ActionsAutomate any workflow】
L17: * 【6†CodespacesInstant dev environments】
L18: * 【7†IssuesPlan and track work】
L19: * 【8†Code ReviewManage code changes】
L20: * 【9†Code QualityEnforce quality at merge】
L21:
L22: * APPLICATION SECURITY
L23: * 【10†GitHub Advanced SecurityFind and fix vulnerabilities】
L24: * 【11†Code securitySecure your code as you build】
L25: * 【12†Secret protectionStop leaks before they start】
L26: * EXPLORE
L27: * 【13†Why GitHub】
L28: * 【14†Documentation†docs.github.com】
L29: * 【15†Blog†github.blog】
L30: * 【16†Changelog†github.blog】
L31: * 【17†Marketplace】
L32:
L33: 【18†View all features】
L34:
L35: * Solutions
L36:
L37: * BY COMPANY SIZE
L38: * 【19†Enterprises】
L39: * 【20†Small and medium teams】
L40: * 【21†Startups】
L41: * 【22†Nonprofits】
L42:
L43: * BY USE CASE
L44: * 【23†App Modernization】
L45: * 【24†DevSecOps】
L46: * 【25†DevOps】
L47: * 【26†CI/CD】
L48: * 【27†View all use cases】
L49: * BY INDUSTRY
L50: * 【28†Healthcare】
L51: * 【29†Financial services】
L52: * 【30†Manufacturing】
L53: * 【31†Government】
L54: * 【32†See all industries】
L55:
L56: 【33†View all solutions】
L57:
L58: * Resources
L59:
L60: * EXPLORE BY TOPIC
L61: * 【34†AI】
L62: * 【35†Software Development】
L63: * 【36†DevOps】
L64: * 【37†Security】
L65: * 【38†View all topics】
L66: * EXPLORE BY TYPE
L67: * 【39†Customer stories】
L68: * 【40†Events & webinars】
L69: * 【41†Ebooks & reports】
L70: * 【42†Business insights】
L71: * 【43†GitHub Skills†skills.github.com】
L72:
L73: * SUPPORT & SERVICES
L74: * 【14†Documentation†docs.github.com】
L75: * 【44†Customer support†support.github.com】
L76: * 【45†Community forum】
L77: * 【46†Trust center】
L78: * 【47†Partners】
L79:
L80: 【48†View all resources】
L81:
L82: * Open Source
L83:
L84: * COMMUNITY
L85: * 【49†GitHub SponsorsFund open source developers】
L86: * PROGRAMS
L87: * 【50†Security Lab†securitylab.github.com】
L88: * 【51†Maintainer Community†maintainers.github.com】
L89: * 【52†GitHub Stars†stars.github.com】
L90: * 【53†Archive Program†archiveprogram.github.com】
L91:
L92: * REPOSITORIES
L93: * 【54†Topics】
L94: * 【55†Trending】
L95: * 【56†Collections】
L96:
L97: * Enterprise
L98:
L99: * ENTERPRISE SOLUTIONS
L100: * 【19†Enterprise platformAI-powered developer platform】
L101: * AVAILABLE ADD-ONS
L102: * 【10†GitHub Advanced SecurityEnterprise-grade security features】
L103: * 【57†Copilot for BusinessEnterprise-grade AI features】
L104: * 【58†Premium SupportEnterprise-grade 24/7 support】
L105:
L106: * 【59†Pricing】
L107:
L108: Search`/`
L109:
L110: 【1†Sign in】
L111:
L112: 【60†Sign up】
L113:
L114: Appearance settings
L115: You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
L116: ## GitPython from 3.1.30 before 3.2.0 contains a remote code...
L117:
L118: Critical severity Unreviewed Published Oct 15, 2026 to the GitHub Advisory Database • Updated Oct 15, 2026
L119:
L120: ## Package
L121:
L122: No package listed— 【61†Suggest a package】
L123:
L124: ## Affected versions
L125:
L126: Unknown
L127:
L128: ## Patched versions
L129:
L130: Unknown
L131: ## Description
L132:
L133: GitPython from 3.1.30 before 3.2.0 contains a remote code execution vulnerability in Remote.pull() whose unsafe-option guard inspects only keyword arguments, not the positional refspec. Attackers controlling the refspec can supply --upload-pack= to execute OS commands as the calling process over local-path or SSH transports.
L134: ### References
L135:
L136: * 【62†GHSA-f9j4-qggq-h239】
L137: * 【63†https://nvd.nist.gov/vuln/detail/CVE-2026-110858†nvd.nist.gov】
L138: * 【64†https://www.vulncheck.com/advisories/gitpython-3.1.30-before-3.2.0-command-injection-via-remote-pull-refspec†www.vulncheck.com】
L139:
L140: Published by the 【63†National Vulnerability Database†nvd.nist.gov】 Oct 14, 2026
L141:
L142: Published to the GitHub Advisory Database Oct 15, 2026
L143:
L144: Last updated Oct 15, 2026
L145:
L146: ### Severity
L147:
L148: Critical
L149:
L150: 9.2
L151: # CVSS overall score
L152:
L153: This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
L154:
L155: / 10
L156:
L157: #### CVSS v4 base metrics
L158:
L159: ##### Exploitability Metrics
L160:
L161: Attack Vector Network
L162:
L163: Attack Complexity Low
L164:
L165: Attack Requirements Present
L166:
L167: Privileges Required None
L168:
L169: User interaction None
L170:
L171: ##### Vulnerable System Impact Metrics
L172:
L173: Confidentiality High
L174:
L175: Integrity High
L176:
L177: Availability High
L178: ##### Subsequent System Impact Metrics
L179:
L180: Confidentiality None
L181:
L182: Integrity None
L183:
L184: Availability None
L185:
L186: Learn more about base metrics
L187:
L188: # CVSS v4 base metrics
L189: ##### Exploitability Metrics
L190: Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system.
L191: The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
L192: Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization.
L193: This metric is meant to capture security mechanisms utilized by the vulnerable system.
L194: Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
L195: Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
L196: User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
L197: ##### Vulnerable System Impact Metrics
L198:
L199: Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
L200: Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
L201: Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email).
L202: Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
L203: ##### Subsequent System Impact Metrics
L204:
L205: Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
L206: Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
L207: Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email).
L208: Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
L209: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
L210: ### EPSS score
L211:
L212: 0.465%
L213:
L214: # Exploit Prediction Scoring System (EPSS)
L215:
L216: This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by 【65†FIRST†www.first.org】.
L217:
L218: (40th percentile)
L219:
L220: ### Weaknesses
L221:
L222: Weakness CWE-88
L223: #### 【66†Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')】
L224:
L225: The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string. 【67†Learn more on MITRE.†cwe.mitre.org】
L226:
L227: ### CVE ID
L228:
L229: CVE-2026-110858
L230:
L231: ### GHSA ID
L232:
L233: GHSA-mcf4-6385-6rcq
L234: ### Source code
L235:
L236: No known source code
L237:
L238: Dependabot alerts are not supported on this advisory because it does not have a package from a supported ecosystem with an affected and fixed version.
L239:
L240: 【68†Learn more about GitHub language support†docs.github.com】
L241:
L242: Loading Checking history
L243:
L244: ### Uh oh!
L245:
L246: There was an error while loading. Please reload this page.
L247:
L248: See something to contribute? 【61†Suggest improvements for this vulnerability】.
L249:
L250: You can’t perform that action at this time.
</excerpt>
</source>
<source kind="search">
<title>GitPython from 3.1.30 before 3.2.0 contains a remote code... · CVE-2026-110858 · GitHub Advisory Database · GitHub</title>
<location>https://github.com/advisories/GHSA-mcf4-6385-6rcq</location>
<excerpt>citeturn0search2 [wordlim: 200] Published: last week; Crawled: last week; CVE-2026-110858 ... GitPython from 3.1.30 before 3.2.0 contains a remote code execution vulnerability in Remote.pull() whose unsafe-option guard inspects only keyword arguments, not the positional refspec. ... * https://nvd.nist.gov/vuln/detail/CVE-2026-110858 ... Dependabot alerts are not supported on this advisory because it does not have a package from a supported ecosystem with an affected and fixed version.
</excerpt>
</source>
<source kind="search">
<title>GitPython Remote.pull() refspec bypasses the --upload-pack unsafe-option guard, enabling arbitrary command execution | Legacy GitLab Advisory Database</title>
<location>https://advisories.gitlab.com/pypi/gitpython/GHSA-f9j4-qggq-h239/</location>
<excerpt>citeturn0search0 [wordlim: 200] Published: yesterday; Crawled: today; * github.com/gitpython-developers/GitPython/security/advisories/GHSA-f9j4-qggq-h239 ... pypi/GitPython/GHSA-f9j4-qggq-h239.yml
</excerpt>
</source>
<source kind="search">
<title>Security Advisories · gitpython-developers/GitPython · GitHub</title>
<location>https://github.com/gitpython-developers/GitPython/security/advisories</location>
<excerpt>citeturn0search1 [wordlim: 200] Crawled: 3 weeks ago; GHSA-f9j4-qggq-h239 published Sep 30, 2026 by Byron ... * GitPython: arbitrary file read via attacker-controlled branch name in `Head.checkout()` (incomplete fix of CVE-2026-78679, at the method named by CVE-2026-76217)
</excerpt>
</source>
<omitted_sources count="16">Additional source records were omitted from this bounded result.</omitted_sources>
</source_evidence>
Citations:
- 1: https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-f9j4-qggq-h239
- 2: https://github.com/advisories/GHSA-mcf4-6385-6rcq
Script executed:
set -u
printf'%s\n''--- cited fdroidserver formula ---'forpathin Formula/fdroidserver.rb Formula/f/fdroidserver.rb;do
url="https://raw.githubusercontent.com/Homebrew/homebrew-core/54c011114/$path"printf'%s\n'"$url"
curl -L --fail --silent --show-error --max-time 20 "$url"| sed -n '1,180p'||truedoneprintf'%s\n''--- formula commit history candidates ---'forpathin Formula/fdroidserver.rb Formula/f/fdroidserver.rb;do
url="https://api.github.com/repos/Homebrew/homebrew-core/commits?path=$path&per_page=30"printf'%s\n'"$url"
curl -L --fail --silent --show-error --max-time 20 "$url"|
python3 -c 'import json,systry: data=json.load(sys.stdin) for x in data: print(x.get("sha",""), x.get("commit",{}).get("message","").splitlines()[0])except Exception as e: print("API_PARSE_ERROR",e)'||truedoneprintf'%s\n''--- exact override references ---'
rg -n -F --max-count 40 -e 'fdroidserver' -e 'CVE-2026-110858' -e 'GHSA-f9j4-qggq-h239' data/overrides.yml advisories/BREW-fdroidserver-CVE-2026-110858.json 2>/dev/null ||test"$?" -eq 1
printf'%s\n''--- target advisory history only ---'
git log --all --format='%H %s' -- advisories/BREW-fdroidserver-CVE-2026-110858.json
Move the Homebrew lower bound to the first affected formula version.
The upstream affected range is GitPython >= 3.1.30. fdroidserver 2.1.2 bundles GitPython 3.1.29, and 2.1.1 bundles 3.1.27, so neither version provides an affected resource. Set introduced to the first later fdroidserver version that bundles GitPython >= 3.1.30. No override preserves 2.1.2 for this advisory.
The reason will be displayed to describe this comment to others. Learn more.
Minor · Data Integrity & Integration · Quick win
Correct the CVSS impact metrics.
This vector records no confidentiality impact and high integrity impact. The described arbitrary file read and the published CVE vector instead specify VC:H/VI:N. Correct the vector so consumers do not classify the disclosure as an integrity issue. (osv.dev)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Automated candidates via
brew advisory-match --formula-list (planned workers) --new-history, sharded by formula (SHA-256 bucket24). See CONTRIBUTING.md for the review checklist.Partial daily run: successful buckets only; the older standing PR may overlap.
Run and review artifacts: https://github.com/Homebrew/advisory-database/actions/runs/40657111712